grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v9 02/11] Unify GUID types


From: Pedro Miguel Justo
Subject: Re: [PATCH v9 02/11] Unify GUID types
Date: Mon, 14 Aug 2023 22:19:35 +0000


> On Aug 14, 2023, at 21:38, Frank Scheiner <frank.scheiner@web.de> wrote:
> 
> Hi Steffen, Ard,
> 
>> On 14.08.23 21:59, Oliver Steffen wrote:
>> Quoting Vladimir 'phcoder' Serbinenko (2023-08-13 09:46:45)
>>> Full analysis: gpt_partentry can be marked as aligned8. But following are
>>> problem:
>>> * protocols_per_handle may return unaligned guids
>>> * configuration_tables array may be unaligned. On efi32 every entry is 20
>>> bytes, so guids can't be 8-byte aligned
>>> * The worst offender is device path as it's packed, unpredictable and 
>>> contains
>>> uuids.
>>> * Efiemu gets guid as argument and probably should be able to handle 
>>> unaligned
>>> case. So far it's x86 only and we have no mmx and co so it's not a problem
>>> right now unless we enable ubsan.
>>> All in all we do need packed guid type unless those are resolved. I attach
>>> patches for testing. If they work, I'll rearrange them a bit
>> 
>> Looking at https://uefi.org/specs/UEFI/2.10/02_Overview.html#data-types,
>> the problem is the alignment, not the packing.
>> 
>> As far as EFI is concerned, GUIDs are always 128bit in size. This means
>> there shall be no padding between the struct members. To be on the safe
>> side one could add the "packed" attribute to the struct, but the
>> original grub_efi_guid struct was not marked like that and it worked.
>> Whenever we had over GUIDs to EFI, they have to be aligned to 64bit.
> 
> 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.
> 
> [1]:
> https://github.com/torvalds/linux/blob/master/include/linux/efi.h#L60-L78
> 
> [2]:
> https://github.com/torvalds/linux/commit/494c704f9af0a0cddf593b381ea44320888733e6
> 
> I know I mentioned [1] earlier, but it sounds like it might have slipped
> through and it might be a good idea to have both GRUB and Linux in sync
> in this regard.
> 

So what is GRUB's current allocation granule, if it is not the same as Linux?

> Cheers,
> Frank

reply via email to

[Prev in Thread] Current Thread [Next in Thread]