[U-Boot] efi_loader: detaching runtime

[Heinrich Schuchardt]

On 6/21/19 3:49 AM, AKASHI, Takahiro wrote:
> On Thu, Jun 20, 2019 at 11:59:12PM +0200, Heinrich Schuchardt wrote:
>> Hello Alex,
>>
>> currently we have two code sections in U-Boot:
>>
>> * __efi_runtime/__efi_runtime_data (mapped to EFI_RUNTIME_SERVICES_CODE)
>> * all other code (mapped to EFI_LOADER_DATA by add_u_boot_and_runtime())
>>
>> All code and data that is not marked as __efi_runtime or
>> __efi_runtime_data lives in a memory area that the EFI application may
>> reuse after ExitBootServices().
>>
>> Code that is marked as __efi_runtime is relocated at SetVirtualMemoryMap().
>>
>> I wonder in which section the relocation code should live.
>>
>> It cannot be __efi_runtime or it will mess up itself while relocating.
>
> What's the matter?
> I think that you can build relocation code as PIC
> if you pass all the necessary global addresses as parameters.

The following routines are to consider: efi_runtime_relocate() and
efi_runtime_detach(). efi_runtime_detach() calls
efi_update_table_header_crc32() which in turn calls crc32(). crc32() is
rather complicated code that I would not like to touch.

We could change the sequence of the calls and call efi_runtime_detach()
before efi_runtime_relocate() and then pass the location of the runtime
table in as a parameter to follow your suggestion. (The runtime table
address is needed, because the pointers are not to be relocated.)

Best regards

Heinrich

>
> -Takahiro Akashi
>
>> It cannot be in EFI_LOADER_DATA or it may be overwritten after
>> ExitBootServices().
>>
>> If this reasoning is right wouldn't we need a third code section living
>> in EFI_RUNTIME_SERVICES_CODE but which is excluded from the relocation
>> during SetVirtualMemoryMap()?
>>
>> Another option of cause would be to put the whole U-Boot code into
>> EFI_RUNTIME_SERVICES_CODE which will incur a loss of less than 1 MiB for
>> the operating system.
>>
>> Best regards
>>
>> Heinrich
>