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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Fri, Mar 18, 2016 at 06:00:27PM +0100, Daniel Kiper 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 just 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 (at this stage load addresses from multiboot2
> and/or ELF headers are ignored). 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_load_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. However, I was asked by Konrad Rzeszutek Wilk and 
> Vladimir
> 'phcoder' Serbinenko to investigate that thing. It looks that relevant 
> machinery
> could be added to existing code (including this patch) without huge effort.
> Additionally, ELF relocation could live in parallel with self relocation 
> provided
> by this patch. However, during research I realized that first of all we should
> establish the details how ELF relocatable image should look like and how it 
> should
> be build. At least to build proper test/example files.
> 
> So, this patch just provides support for self relocatable images. If ELF file
> with relocs is loaded then GRUB2 complains loudly and ignores it. Support for
> such files will be added later.
> 
> This patch was tested with Xen image which uses that functionality. However, 
> this Xen
> feature is still under development and new patchset will be released in about 
> 3-4 weeks.

> index e3a39b6..8a9ab0c 100644
> --- a/grub-core/loader/multiboot_elfxx.c
> +++ b/grub-core/loader/multiboot_elfxx.c

..snip..
>  static grub_err_t
> -CONCAT(grub_multiboot_load_elf, XX) (grub_file_t file, const char *filename, 
> void *buffer)
> +CONCAT(grub_multiboot_load_elf, XX) (mbi_load_data_t *mld)
>  {
> +#ifdef MULTIBOOT_LOAD_ELF64
> +  if (highest_load >= 0x100000000)
> +    return grub_error (GRUB_ERR_BAD_OS, "segment cross 4 GiB border");

segment crosses 4GiB border!

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