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

[AKASHI Takahiro <takahiro.akashi@linaro.org>]

On Thu, Feb 21, 2019 at 07:55:46PM +0100, Heinrich Schuchardt wrote:
> 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.

Finally, you've got my old patch ("efi_loader: set image_base and image_size
to correct values":
  https://lists.denx.de/pipermail/u-boot/2018-August/337708.html

-Takahiro Akashi

> Best regards
> 
> Heinrich