[U-Boot] [RFC 1/1] efi_loader: in situ relocation

[Heinrich Schuchardt]

On 2/21/19 11:21 AM, Alexander Graf wrote:
> On 02/20/2019 07:12 PM, Heinrich Schuchardt wrote:
>> On 2/18/19 1:52 AM, AKASHI Takahiro wrote:
>>> Heinrich,
>>>
>>> On Sat, Feb 16, 2019 at 08:50:43PM +0100, Heinrich Schuchardt wrote:
>>>> All code and data sections of PE images are already in the correct
>>>> relative
>>>> location when loaded into memory. There is not need to copy them once
>>>> again.
>>> While I'm not very familiar with how PE image is created (in EDK2),
>> The relevant reference is the Microsoft Portable Executable and
>> Common Object File Format Specification. The latest version as PDF that
>> I found is revision 11, Jan 23rd, 2017. The citations are from that
>> version. Later versions are available as HTML.
>>
>>> what I understand in Alex's code is
>>> * All the code and data are located starting 0x0 (in virtual space)
>> The header provides a field ImageBase. If you load the image at this
>> address there is no need for relocation. I could not find any rule
>> saying ImageBase has to be zero. It has be a multiple of 64 KiB. For
>> Windows non-zero defaults are provided in the spec.
>>
>>> * Sections in PE image may not be sorted in ascending order
>> The spec says: "The physical offset for section data is the same as the
>> RVA". The relative virtual address is defined as "In an image file, the
>> address of an item after it is loaded into memory, with the base address
>> of the image file subtracted from it."
>>
>>> * There may be some gaps (more than one page) between sections,
>>>    probably, due to alignment requirements or BSS
>> Yes, due to alignment there may be some gap filling bytes.
>>
>>> Do you say that those assumptions are no longer correct?
>> The most important sentence concerning relocations in the spec is:
>>
>> "If the image is loaded at its preferred base, ... the base relocations
>> do not have to be applied."
> 
> Yes, but image loading also implies that we actually load the sections
> to particular offsets with particular section alignment. You can have a
> PE binary that aligns its sections in 32 byte granule, but expects the
> sections to get loaded at 4kb alignment. In such a case, I don't see how
> we can get away to not copy the image.
> 

Thanks Alex and Takhiro for reviewing.

Reading the fine print in the spec I now saw that segment alignment is
typically smaller than file alignment.

Strange that even the EFI shell would work with my patch in.

What we should be able to do is to release the buffer used for reading
from file once we have done the relocation, so that after LoadImage we
end up with only one memory area allocated for the image.

Best regards

Heinrich