From mboxrd@z Thu Jan 1 00:00:00 1970 From: AKASHI Takahiro Date: Fri, 22 Feb 2019 10:17:45 +0900 Subject: [U-Boot] [RFC 1/1] efi_loader: in situ relocation In-Reply-To: References: <20190216195044.8639-1-xypron.glpk@gmx.de> <20190218005200.GW20286@linaro.org> <04ac4492-b68d-bcf8-79ac-47fecb05dc36@gmx.de> Message-ID: <20190222011744.GO20286@linaro.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de 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