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

[Alexander Graf]

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.


Alex