Re: [Xen-devel] [GRUB2 PATCH v3 4/4] multiboot2: Add support for relocatable images

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Thu, Mar 10, 2016 at 09:44:31PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Wednesday, March 2, 2016, Daniel Kiper <daniel.kiper@xxxxxxxxxx> wrote:
>
> > Currently multiboot2 protocol loads image exactly at address specified in
> > ELF or multiboot2 header. This solution works quite well on legacy BIOS
> > platforms. It is possible because memory regions are placed at predictable
> > addresses (though I was not able to find any spec which says that it is
> > strong requirement, so, it looks that it is just a goodwill of hardware
> > designers). However, EFI platforms are more volatile. Even if required
> > memory regions live at specific addresses then they are sometimes simply
> > not free (e.g. used by boot/runtime services on Dell PowerEdge R820 and
> > OVMF). This means that you are not able to simply set up final image
> > destination on build time. You have to provide method to relocate image
> > contents to real load address which is usually different than load address
> > specified in ELF and multiboot2 headers.
> >
> > This patch provides all needed machinery to do self relocation in image
> > code.
> > First of all GRUB2 reads min_addr (min. load addr), max_addr (max. load
> > addr),
> > align (required image alignment), preference (it says which memory regions
> > are
> > preferred by image, e.g. none, low, high) from
> > multiboot_header_tag_relocatable
> > header tag contained in binary. Later loader tries to fulfill request (not
> > only
> > that one) and if it succeeds then it informs image about real load address
> > via
> > multiboot_tag_base_addr tag. At this stage GRUB2 role is finished. Starting
> > from now executable must cope with relocations itself using whole static
> > and dynamic knowledge provided by boot loader.
> >
> > This patch does not provide functionality which could do relocations using
> > ELF relocation data.
>
> Can you add a check that image doesn't have any relocation entries? So that
> we fail nicely rather than loading half-working binary?

Make sense. I will do that.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel