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>
As the ASM_FUNC() macro performs a section switch, the preceding
.balign directive applies the alignment constraint to the current
location in the previous section. As the linker may not merge the
sections in-order, ArmReplaceLiveTranslationEntry() may be left
unaligned.
Replace the explicit invocation of .balign with the ASM_FUNC_ALIGN()
macro, which guarantees the alignment constraint is applied correctly.
To make sure related issues are reliably caught in the future, align the
end of the function before checking the total occupied size. This
ensures crossing a 0x200 boundary will cause a compilation error.
Signed-off-by: Marvin Häuser <mhaeuser@posteo.de>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
With the current ASM_FUNC() macro, there is no good way to declare an
alignment constraint for a function. As ASM_FUNC() switches sections,
declaring the constraint before the macro invocation applies it to the
current location in the previous section. Declaring the constraint after
the macro invocation lets the function label point to the location prior
to alignment. Depending on toolchain behaviour, this may cause the label
to point to alignment padding preceding the actual function definition.
To address these issues, introduce the ASM_FUNC_ALIGN() macro, which
declares the alignment constraint right before the function label.
Signed-off-by: Marvin Häuser <mhaeuser@posteo.de>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
