From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel Kiper <daniel.kiper@oracle.com>
Cc: jgross@suse.com, grub-devel@gnu.org, eric.snowberg@oracle.com,
arvidjaar@gmail.com, andrew.cooper3@citrix.com,
stefano.stabellini@eu.citrix.com, cardoe@cardoe.com,
pgnet.dev@gmail.com, roy.franz@linaro.org, ning.sun@intel.com,
david.vrabel@citrix.com, jbeulich@suse.com, phcoder@gmail.com,
xen-devel@lists.xenproject.org, qiaowei.ren@intel.com,
richard.l.maliszewski@intel.com, gang.wei@intel.com,
fu.wei@linaro.org, seth.goldberg@oracle.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.35107071257$1458924984$gmane$org@char.us.oracle.com> (raw)
In-Reply-To: <1458320427-4653-6-git-send-email-daniel.kiper@oracle.com>
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@lists.xen.org
http://lists.xen.org/xen-devel
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] <1458320427-4653-1-git-send-email-daniel.kiper@oracle.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] ` <1458320427-4653-6-git-send-email-daniel.kiper@oracle.com>
2016-03-25 16:54 ` Konrad Rzeszutek Wilk [this message]
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='20160325165419.GB20741__4627.35107071257$1458924984$gmane$org@char.us.oracle.com' \
--to=konrad.wilk@oracle.com \
--cc=andrew.cooper3@citrix.com \
--cc=arvidjaar@gmail.com \
--cc=cardoe@cardoe.com \
--cc=daniel.kiper@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=eric.snowberg@oracle.com \
--cc=fu.wei@linaro.org \
--cc=gang.wei@intel.com \
--cc=grub-devel@gnu.org \
--cc=jbeulich@suse.com \
--cc=jgross@suse.com \
--cc=ning.sun@intel.com \
--cc=pgnet.dev@gmail.com \
--cc=phcoder@gmail.com \
--cc=qiaowei.ren@intel.com \
--cc=richard.l.maliszewski@intel.com \
--cc=roy.franz@linaro.org \
--cc=seth.goldberg@oracle.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).