[U-Boot] [PATCH v2 2/9] efi_loader: fix efi_find_free_memory()

[Alexander Graf]

On 13.11.18 22:21, Heinrich Schuchardt wrote:
> On 11/13/18 9:56 PM, Alexander Graf wrote:
>>
>>
>> On 12.11.18 18:55, Heinrich Schuchardt wrote:
>>> In efi_find_free_memory() the sandbox uses its virtual address space.
>>> Add the missing mapping.
>>>
>>> Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
>>
>> The real bug here is much worse. According to 2.3.4 "x64 Platforms" of
>> the UEFI spec:
>>
>> ===
>> Paging mode is enabled and any memory space defined by the UEFI memory
>> map is identity mapped (virtual address equals physical address),
>> although the attributes of certain regions may not have all read, write,
>> and execute attributes or be unmarked for purposes of platform
>> protection. The mappings to other regions are undefined and may vary
>> from implementation to implementation.
>> ===
>>
>> This means we can't have virtual != physical. We need to go with all
>> physical (pointers) instead. Anything else violates the spec.
>>
>>
>> Alex
> 
> The sandbox runs inside of Linux. In user space we will never have
> access to physical memory addresses (see the mmap() man page).

All APIs refer to "physical address" as pointers they use. So
AllocatePages() for example returns an EFI_PHYSICAL_ADDRESS. That means
in the sandbox case, a Linux poionter is our EFI physical address.

On top of that, the UEFI spec says that an application may expect that
virtual == physical.

So in other words, we can not assume that anything may use sandbox
addresses anywhere in the EFI layer.


Today we have the following mapping:

	physical -> pointer
	virtual  -> sandbox address

What your patch is trying to fix is that some payload (not sure what,
probably just an internal user?) is passing max_addr as virtual
(sandbox) address. But the UEFI spec doesn't explicitly state whether
max_addr is a virtual (sandbox) or a physical (pointer) address. It
simply assumes they're equal during boot time.

So any conversion is wrong :).

> 
> My understanding is that for sandbox testing to run smoothly all
> addresses seen on the sandbox in the user interface are neither physical
> nor virtual addresses in the CPU sense but exist in a 3rd address space
> only known to the sandbox.
> 
> Without implementing a virtual machine we will never implement
> SetVirtualAddressMap() on the sandbox. And with a virtual machine we
> would loose all the advantages of the sandbox.
> 
> With the current setup we should be able to run the EFI shell and even
> SCT on the sandbox as long as SetVirtualAddressMap() is not reached. But
> we will never boot an operating system on the sandbox.

Yes, but before SetVirtualAddressMap the spec mandates that phys == virt
and that means phys == virt == pointer.


Alex