On Tue, 15 Aug 2023 at 05:42, Vladimir 'phcoder' Serbinenko <phco...@gmail.com> 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 Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel