[U-Boot] [PATCH] efi_loader: don't allocate unusable RAM

[Alexander Graf]

On 31.07.18 22:20, Stephen Warren wrote:
> On 07/31/2018 02:15 PM, Alexander Graf wrote:
>>
>>
>>> Am 31.07.2018 um 22:04 schrieb Stephen Warren <swarren at wwwdotorg.org>:
>>>
>>> On 07/31/2018 02:03 PM, Alexander Graf wrote:
>>>>> Am 31.07.2018 um 21:44 schrieb Stephen Warren <swarren at wwwdotorg.org>:
>>>>>
>>>>> From: Stephen Warren <swarren at nvidia.com>
>>>>>
>>>>> Some boards define a maximum usable RAM top that's more restrictive
>>>>> than
>>>>> the ranges defined by U-Boot's memory bank definitions[1]. In this
>>>>> case,
>>>>> the unusable RAM isn't mapped in the page tables, and so the EFI
>>>>> code must
>>>>> not attempt to allocate RAM from outside the usable regions. Fix
>>>>> efi_find_free_memory() to detect when max_addr is unconstrained or
>>>>> out of
>>>>> range, and substitue a valid value.
>>>>>
>>>>> [1] For example, when some peripherals can't access RAM above 4GiB,
>>>>> it's
>>>>> simplest to force U-Boot's ram_top to a smaller value to avoid dealing
>>>>> with this issue more explicitly. However, the RAM bank definitions
>>>>> still
>>>>> describe the unusable RAM so that the booted OS has access to it,
>>>>> since
>>>>> the OS can typically deal with such restrictions in a more complex
>>>>> manner.
>>>> That's what we have the efi bounce buffers for. Can't we just enable
>>>> those for tegra?
>>>
>>> No, because that wouldn't help all the non-EFI code, or cause the RAM
>>> to be mapped in the page tables due to the non-EFI code not needing it.
>>
>> The non-efi code can still rely on ram_top just fine, no? I was more
>> thinking of enabling the bounce buffer config option as alternative to
>> your patch.
> 
> A lot more besides enabling that option would have to be done. The issue
> here is that EFI is attempting to use RAM that's not in the page tables
> and hence crashes. Enabling bounce buffers alone isn't going to help
> that; we'd also have to rejig the U-Boot MMU code to set up page table
> entries for the entire of the RAM banks rather than just the usable RAM,
> and then we've have to develop some new way of preventing U-Boot from
> mapping RAM that's part of the RAM banks but shouldn't be mapped because
> e.g. it's part of the secure carveout that can't be mapped in the MMU in
> order to ensure that the CPU never pre-fetches that RAM to avoid taking
> security faults on the fetch. The fact that ram_top is lower than the
> HW-defined RAM limit exists for reasons other than just preventing use
> of RAM that some peripheral HW can't access, so bounce buffers will only
> solve one of the causes, not everything.

I see. The main problem I just see is exactly the rationale you
described above: The EFI memory map will be used by the booted OS to
indicate which regions are usable. If they really aren't, then we need
to properly annotate that in the EFI memory map as well, because
otherwise Linux may end up writing to carved out secure regions of RAM.


Alex