On Tue, 15 Aug 2023 at 05:42, Vladimir 'phcoder' Serbinenko
<[email protected]> wrote:
>>
>> .
>>
>> Ard thinks that a 64 bit alignment for EFI GUIDs is a mistake - see [1]
>> and [2]. Hence Linux uses `__aligned(__alignof__(u32))` for "efi_guid_t"
>> since 2019.
>
>
> My patch presents a reliability paradigm: accept all inputs, produce outputs
> that are always aligned to 8-byte. It can make sense even though I agree that
> requiring 8-byte alignment for UUID is weird. Yet it's difficult to know if
> some obscure firmware does rely on it in some one in a thousand edge case
+1
The Linux side change ensures that the OS does not present misaligned
GUIDs to the firmware.
The problem with 8-byte alignment is that it deviates from EDK2, and
could result in struct layout changes due to padding. Given that EDK2
uses 32-bit alignment only, some of the struct types it defines might
suddenly need the __packed attribute on 32-bit builds if the alignment
of the GUID type is increased to 64 bits.
E.g.,
struct {
void *
guid
}
will have no padding in 32-bit EDK2 based firmware builds, even if the
spec claims that GUIDs are 64-bit aligned.
So the lowest risk change for Linux was to increase to 32-bit
alignment, as it fixes any potential issues with misaligned
load-multiple instructions on ARM, and other architectures don't care
that much about alignment anyway.
_______________________________________________
Grub-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/grub-devel
