BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3223
In the current design, memory protection is not available till CpuDxe
is loaded. To resolve this, introduce CpuArchLib to move the
CPU Architectural initialization to DxeCore.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Vitaly Cheptsov <vit9696@protonmail.com>
Signed-off-by: Marvin Häuser <mhaeuser@posteo.de>
The current image DxeCore re-uses the generic UEFI implementations of
DxeServicesTableLib, UefiBootServicesTableLib, and
UefiRuntimeServicesTableLib. As such, the respective pointers are not
available till the library constructors have been called.
Use the DxeCore library instances for the services tables for them to
be available earlier. This for example allows the usage of DXE memory
protection services by externally linked modules before reaching
library construction stage.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Vitaly Cheptsov <vit9696@protonmail.com>
Signed-off-by: Marvin Häuser <mhaeuser@posteo.de>
The current image DxeCore re-uses the generic UEFI implementations of
DxeServicesTableLib, UefiBootServicesTableLib, and
UefiRuntimeServicesTableLib. As it is the owner of those pointers
however, it can expose them without further indirection.
Import library instances of the services table libraries specifically
for DxeCore to expose its internal pointers dirtectly.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Vitaly Cheptsov <vit9696@protonmail.com>
Signed-off-by: Marvin Häuser <mhaeuser@posteo.de>
MaxExtentsPerNode should be same type as eh_max uint16, because maximum
count of extent header entries is 65535
Signed-off-by: Savva Mitrofanov <savvamtr@gmail.com>
We had added support for CSUM_SEED but accidentally forgot to advertise
it in gSupportedIncompatFeat. This made it (erroneously) impossible to
mount CSUM_SEED filesystems.
Detected by attempting to mount a relatively new mkfs.ext4'd filesystem.
Cc: Marvin Häuser <mhaeuser@posteo.de>
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Reviewed-by: Marvin Häuser <mhaeuser@posteo.de>
Improve the extent tree node validation by validating the number of
entries the node advertises against the theoretical max (derived from
the size of on-disk structs and the block size (or i_data, if inline
extents).
Previously, we did not validate the number of entries. This could be
exploited for out-of-bounds reads and crashes.
Cc: Marvin Häuser <mhaeuser@posteo.de>
Fixes: d9ceedca6c8f ("Ext4Pkg: Add Ext4Dxe driver.")
Reported-by: Savva Mitrofanov <savvamtr@gmail.com>
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Reviewed-by: Marvin Häuser <mhaeuser@posteo.de>
There have been reports[1] of failures to boot due to unicode collation
protocols not being available at Ext4Dxe load time. Therefore, attempt
to initialize unicode collation at Start() time, like done previously in
FatPkg/EnhancedFatDxe. By doing so, we move collation initialization
to BDS, where the module responsible for protocol installation should
have already been loaded and ran.
[1]: https://edk2.groups.io/g/devel/message/100312
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Marvin Häuser <mhaeuser@posteo.de>
Fixes: d9ceedca6c8f ("Ext4Pkg: Add Ext4Dxe driver.")
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Marvin Häuser <mhaeuser@posteo.de>
OVMF can't guarantee that the ASSERT() doesn't happen. Misbehaving
EFI applications can trigger this. So log a warning instead and try
to continue.
Reproducer: Fetch windows 11 22H2 iso image, boot it in qemu with OVMF.
Traced to BootServices->Stall() being called with IPL=TPL_HIGH_LEVEL
and Interrupts /enabled/ while windows is booting.
Cc: Michael Brown <mcb30@ipxe.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
