From: Konrad Rzeszutek Wilk <email@example.com>
To: Daniel Kiper <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
email@example.com, firstname.lastname@example.org, email@example.com,
Subject: Re: [GRUB2 PATCH v5 4/4] multiboot2: Add support for relocatable images
Date: Fri, 25 Mar 2016 12:54:19 -0400 [thread overview]
Message-ID: <20160325165419.GB20741__4627.firstname.lastname@example.org> (raw)
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
> 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
prev parent reply other threads:[~2016-03-25 16:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <email@example.com>
2016-03-18 17:00 ` [GRUB2 PATCH v5 1/4] i386/relocator: Add grub_relocator64_efi relocator Daniel Kiper
2016-03-25 16:28 ` Konrad Rzeszutek Wilk
[not found] ` <20160325162846.GA20741@char.us.oracle.com>
2016-03-25 20:43 ` Daniel Kiper
2016-03-18 17:00 ` [GRUB2 PATCH v5 2/4] multiboot2: Add tags used to pass ImageHandle to loaded image Daniel Kiper
2016-03-18 17:00 ` [GRUB2 PATCH v5 3/4 - FOR REVIEW ONLY] multiboot2: Do not pass memory maps to image if EFI boot services are enabled Daniel Kiper
2016-03-18 17:00 ` [GRUB2 PATCH v5 3/4 - FOR COMMIT] " Daniel Kiper
2016-03-18 17:00 ` [GRUB2 PATCH v5 4/4] multiboot2: Add support for relocatable images Daniel Kiper
[not found] ` <firstname.lastname@example.org>
2016-03-25 16:54 ` Konrad Rzeszutek Wilk [this message]
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).