[PATCH] efi: arm-stub: Correct FDT and initrd allocation rules for arm64

[Ard Biesheuvel]

On 9 February 2017 at 19:04, Jeffrey Hugo <jhugo at codeaurora.org> wrote:
> On 2/9/2017 11:26 AM, Ard Biesheuvel wrote:
>>
>> BTW the memory map isn't necessarily sorted per the UEFI spec, so it
>> iterates in what is essentially random order, not low to high.
>
>
> True, I'm used to EDK2, which from what I've seen, keeps it ordered. However
> that's somewhat immaterial to my point that its possible for initrd to be
> far enough from kernel to break booting.txt
>
>>
>>>> It looks to see
>>>> if a slot can hold the allocation, and the slot does not exceed the
>>>> specified max.  If so, efi_high_alloc retains a reference to the slot.
>>>> Then
>>>> efi_high_alloc continues iterating though the map, until the end.
>>>> efi_high_alloc only stores a reference to the most recently valid slot,
>>>> which would be the highest slot in the map.
>>>>
>>>
>>> It is documented as
>>>
>>> /*
>>>  * Allocate at the highest possible address that is not above 'max'.
>>>  */
>>>
>>> and what you describe is pretty much that, no?
>>>
>>>> My system can have 256GB (or more) of RAM.  It is possible, however
>>>> remote,
>>>> that the initrd and kernel can be more than 64GB away from each other.
>>>>
>>>> Lets assume KASLR puts the kernel at 250GB.  Lets assume, for whatever
>>>> reason, we can't fit the initrd above 150GB (there was just enough room
>>>> to
>>>> jam kernel there somwhow, but firmware is consuming the rest, maybe it
>>>> put
>>>> rootfs there via NFIT).
>>>
>>>
>>> So before even booting the kernel, you already have 100 GB of memory
>>> occupied?
>
>
> That is possible, yes.  Likely?  Probably not.  Would our system fail if
> initrd and kernel are father than the prescribed restriction?  No, since the
> system can address all of RAM, we'd probably be fine.
>
>>> As I replied before, you are correct that in this case, you
>>> will not be able to put the initrd within 32 GB of the kernel. But do
>>> note that this 32 GB figure is derived from the linear region size of
>>> a 16k pages kernel with 2 levels of translation, which is a niche
>>> configuration by itself. On a system that has 256 GB of RAM, it is
>>> highly unlikely that you will be using a kernel that can only map 32
>>> GB of it.
>>>
>>> The reason for choosing the 32 GB figure is that it relieves the boot
>>> loader from having to go and figure out what kind of kernel is going
>>> to be executed. Page size can be read from the Image header but the VA
>>> size cannot. So 32 GB was a reasonable number imo.
>
>
> Ok, so the restriction is completely arbitrary and has no real purpose. Ie
> nothing in the kernel will break, so long as you assume the system is not
> configured with more RAM than can be addressed, which doesn't feel
> reasonable to do.
>
> I realize I'm being nitpicky, from my perspective, any issues related to
> efistub are particularly difficult to debug, so if this scenario we've been
> going around about ever popped up, it wouldn't even give you a print that
> happened when you back trace the output trying to figure out why the boot
> failed.
>
> However, it really looks like even if the scenario occurred, there is zero
> realistic expectation anything would break, and its just a violation of some
> document that makes assumptions and should be treated more as guidance to
> try to follow, rather than hard rules.
>

Actually, there is no reason for the stub to adhere 100% to the boot
protocol, and we already violate it deliberately by randomizing the
physical offset with a 64 KB granularity under KASLR, whereas the boot
protocol stipulates that it should be a 2 MB aligned base +
TEXT_OFFSET.

So in this case, I think it is reasonable to take VA_BITS into account
rather than use a hardcoded 32 GB. That will eliminate the problem
completely when you use a 48-bit VA kernel, and will make it highly
unlikely to ever occur on more common 39 and 42 bit VA configurations.

-- 
Ard.