Re: [Xen-devel] [GRUB2 PATCH v3 4/4] multiboot2: Add support for relocatable images
On Fri, Mar 11, 2016 at 05:13:19PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> > > > + if (relocatable)
> > > > +{
> > > > + if (base_addr > min_addr)
> > > > + grub_multiboot_payload_eip += base_addr - min_addr;
> > > > + else
> > > > + grub_multiboot_payload_eip -= min_addr - base_addr;
> > > > +}
> > > > +
> > > >
> > > Why is it relative to min_addr? Sounds like it should be just an offset
> >
> > Ugh... IIRC, it has meaning but I forgot what. I will check it.
> > However, this means that I must put comment here.
> >
>
> Is it possible that you have confused link address and minimal loading
> address?
Yep, you are right. Fortunately it is quite easy to fix and probably do not
require any changes in Xen image.
> How is entry usually specified in ELF?
IIRC, there is no such thing per se. However, I think that
we should calculate link base address using following formula:
link_base_addr = ~0;
for (i = 0; i < ehdr->e_phnum; i++)
link_base_addr = min(link_base_addr, phdr(i)->p_paddr);
> How do you suggest it should be done in mb headers?
I think that we can use multiboot_header_tag_address.load_addr
as link_base_addr.
Daniel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [GRUB2 PATCH v3 4/4] multiboot2: Add support for relocatable images
On Thu, Mar 10, 2016 at 09:44:31PM +0100, Vladimir 'phcoder' Serbinenko wrote: > On Wednesday, March 2, 2016, 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 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@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [GRUB2 PATCH v3 4/4] multiboot2: Add support for relocatable images
>
>
> > > + if (relocatable)
> > > +{
> > > + if (base_addr > min_addr)
> > > + grub_multiboot_payload_eip += base_addr - min_addr;
> > > + else
> > > + grub_multiboot_payload_eip -= min_addr - base_addr;
> > > +}
> > > +
> > >
> > Why is it relative to min_addr? Sounds like it should be just an offset
>
> Ugh... IIRC, it has meaning but I forgot what. I will check it.
> However, this means that I must put comment here.
>
Is it possible that you have confused link address and minimal loading
address? How is entry usually specified in ELF? How do you suggest it
should be done in mb headers?
>
> > from base addr. What do ET_DYN files use?
>
> I will take a look.
>
> Daniel
>
--
Regards
Vladimir 'phcoder' Serbinenko
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [GRUB2 PATCH v3 4/4] multiboot2: Add support for relocatable images
On Thu, Mar 10, 2016 at 09:41:26PM +0100, Vladimir 'phcoder' Serbinenko wrote: > On Wednesday, March 2, 2016, 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 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. 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. > > > > As I saw multiboot2 protocol is able to consume ET_EXEC and ET_DYN ELF > > files. > > Potentially we can use ET_DYN file type. It can be build with gcc/ld -pie > > option. > > However, it contains a lot of unneeded stuff (e.g. INTERP, DYNAMIC, > > GNU_EH_FRAME > > program headers) and it could be quite difficult to drop them (Hmmm... Is > > it > > possible to build it properly with custom ld script?). > > How big are they? Are they a real problem? ET_DYN file is ~2.5 times bigger then normal ET_EXEC (I has checked multiboot2.elf from GRUB2). There is a chance that we can ignore most of stuff in ET_DYN, however, it does not look nice. IMO, image should have only what is needed by loader. > > So, I have checked ET_EXEC > > file type. Sadly in this case linker by default resolves all local symbol > > relocations > > and removes relocation related sections. Fortunately it is possible to > > leave them > > as is with simple -q/--emit-relocs ld option. However, output file is > > quite fragile > > and any operation on it should be done with great care (e.g. strip should > > be called > > with --strip-unneeded option). So, this solution is not perfect too. It > > means that > > maybe we should look for better solution. However, I think that we should > > not use > > any custom tools and focus on functionalities provided by compiler and > > binutils. > > In this context ld scripts looks quite promising but maybe you have better > > solutions. > > So, what do you think about that? > > > Another possibility is to use intermediary .o files like we do for modules > and like Linux does for modules AFAIR. Correct but I think that it would be better to have normal ET_EXEC or ET_DYN file. > > 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. > > > > Signed-off-by: Daniel Kiper > > > --- > > v3 - suggestions/fixes: > >- reduce number of casts > > (suggested by Konrad Rzeszutek Wilk), > >- remove unneeded space at the end of line > > (suggested by Konrad Rzeszutek Wilk), > >- improve commit message > > (suggested by Konrad Rzeszutek Wilk). > > --- > > grub-core/loader/i386/multiboot_mbi.c |6 ++- > > grub-core/loader/multiboot.c | 12 -- > > grub-core/loader/multiboot_elfxx.c| 28 ++ > > grub-core/loader/multiboot_mbi2.c | 65 > > ++--- > > include/grub/multiboot.h |4 +- > > include/mu
Re: [Xen-devel] [GRUB2 PATCH v3 4/4] multiboot2: Add support for relocatable images
On Wednesday, March 2, 2016, 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 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?
> 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.
>
> As I saw multiboot2 protocol is able to consume ET_EXEC and ET_DYN ELF
> files.
> Potentially we can use ET_DYN file type. It can be build with gcc/ld -pie
> option.
> However, it contains a lot of unneeded stuff (e.g. INTERP, DYNAMIC,
> GNU_EH_FRAME
> program headers) and it could be quite difficult to drop them (Hmmm... Is
> it
> possible to build it properly with custom ld script?). So, I have checked
> ET_EXEC
> file type. Sadly in this case linker by default resolves all local symbol
> relocations
> and removes relocation related sections. Fortunately it is possible to
> leave them
> as is with simple -q/--emit-relocs ld option. However, output file is
> quite fragile
> and any operation on it should be done with great care (e.g. strip should
> be called
> with --strip-unneeded option). So, this solution is not perfect too. It
> means that
> maybe we should look for better solution. However, I think that we should
> not use
> any custom tools and focus on functionalities provided by compiler and
> binutils.
> In this context ld scripts looks quite promising but maybe you have better
> solutions.
> So, what do you think about that?
>
> 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.
>
> Signed-off-by: Daniel Kiper >
> ---
> v3 - suggestions/fixes:
>- reduce number of casts
> (suggested by Konrad Rzeszutek Wilk),
>- remove unneeded space at the end of line
> (suggested by Konrad Rzeszutek Wilk),
>- improve commit message
> (suggested by Konrad Rzeszutek Wilk).
> ---
> grub-core/loader/i386/multiboot_mbi.c |6 ++-
> grub-core/loader/multiboot.c | 12 --
> grub-core/loader/multiboot_elfxx.c| 28 ++
> grub-core/loader/multiboot_mbi2.c | 65
> ++---
> include/grub/multiboot.h |4 +-
> include/multiboot2.h | 24
> 6 files changed, 120 insertions(+), 19 deletions(-)
>
> diff --git a/grub-core/loader/i386/multiboot_mbi.c
> b/grub-core/loader/i386/multiboot_mbi.c
> index f60b702..4fc83ed 100644
> --- a/grub-core/loader/i386/multiboot_mbi.c
> +++ b/grub-core/loader/i386/multiboot_mbi.c
> @@ -72,7 +72,8 @@ load_kernel (grub_file_t file, const char *filename,
>grub_err_t err;
>if (grub_multiboot_quirks & GRUB_MULTIBOOT_QUIRK_BAD_KLUDGE)
> {
> - err = grub_multiboot_load_elf (file, filename, buffer);
> + err = grub_multiboot_load_elf (file, filename, buffer, 0, 0, 0, 0,
Re: [Xen-devel] [GRUB2 PATCH v3 4/4] multiboot2: Add support for relocatable images
On Friday, March 4, 2016, Juergen Gross wrote:
> On 02/03/16 17:51, 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 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. 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.
> >
> > As I saw multiboot2 protocol is able to consume ET_EXEC and ET_DYN ELF
> files.
> > Potentially we can use ET_DYN file type. It can be build with gcc/ld
> -pie option.
> > However, it contains a lot of unneeded stuff (e.g. INTERP, DYNAMIC,
> GNU_EH_FRAME
> > program headers) and it could be quite difficult to drop them (Hmmm...
> Is it
> > possible to build it properly with custom ld script?). So, I have
> checked ET_EXEC
> > file type. Sadly in this case linker by default resolves all local
> symbol relocations
> > and removes relocation related sections. Fortunately it is possible to
> leave them
> > as is with simple -q/--emit-relocs ld option. However, output file is
> quite fragile
> > and any operation on it should be done with great care (e.g. strip
> should be called
> > with --strip-unneeded option). So, this solution is not perfect too. It
> means that
> > maybe we should look for better solution. However, I think that we
> should not use
> > any custom tools and focus on functionalities provided by compiler and
> binutils.
> > In this context ld scripts looks quite promising but maybe you have
> better solutions.
> > So, what do you think about that?
> >
> > 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.
> >
> > Signed-off-by: Daniel Kiper >
> > ---
> > v3 - suggestions/fixes:
> >- reduce number of casts
> > (suggested by Konrad Rzeszutek Wilk),
> >- remove unneeded space at the end of line
> > (suggested by Konrad Rzeszutek Wilk),
> >- improve commit message
> > (suggested by Konrad Rzeszutek Wilk).
> > ---
> > grub-core/loader/i386/multiboot_mbi.c |6 ++-
> > grub-core/loader/multiboot.c | 12 --
> > grub-core/loader/multiboot_elfxx.c| 28 ++
> > grub-core/loader/multiboot_mbi2.c | 65
> ++---
> > include/grub/multiboot.h |4 +-
> > include/multiboot2.h | 24
> > 6 files changed, 120 insertions(+), 19 deletions(-)
> >
> > diff --git a/grub-core/loader/i386/multiboot_mbi.c
> b/grub-core/loader/i386/multiboot_mbi.c
> > index f60b702..4fc83ed 100644
> > --- a/grub-core/loader/i386/multiboot_mbi.c
> > +++ b/grub-core/loader/i386/multiboot_mbi.c
> > @@ -72,7 +72,8 @@ load_kernel (grub_file_t file, const char *filename,
> >grub_err_t err;
> >if (grub_multiboot_quirks & GRUB_MULTIBOOT_QUIRK_BAD_KLUDGE)
> > {
> > - err = grub_multiboot_load_elf (file, filename, buffer);
> > +
Re: [Xen-devel] [GRUB2 PATCH v3 4/4] multiboot2: Add support for relocatable images
On Wednesday, March 2, 2016, 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 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. 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.
>
> As I saw multiboot2 protocol is able to consume ET_EXEC and ET_DYN ELF
> files.
> Potentially we can use ET_DYN file type. It can be build with gcc/ld -pie
> option.
> However, it contains a lot of unneeded stuff (e.g. INTERP, DYNAMIC,
> GNU_EH_FRAME
> program headers) and it could be quite difficult to drop them (Hmmm... Is
> it
> possible to build it properly with custom ld script?).
How big are they? Are they a real problem?
> So, I have checked ET_EXEC
> file type. Sadly in this case linker by default resolves all local symbol
> relocations
> and removes relocation related sections. Fortunately it is possible to
> leave them
> as is with simple -q/--emit-relocs ld option. However, output file is
> quite fragile
> and any operation on it should be done with great care (e.g. strip should
> be called
> with --strip-unneeded option). So, this solution is not perfect too. It
> means that
> maybe we should look for better solution. However, I think that we should
> not use
> any custom tools and focus on functionalities provided by compiler and
> binutils.
> In this context ld scripts looks quite promising but maybe you have better
> solutions.
> So, what do you think about that?
>
Another possibility is to use intermediary .o files like we do for modules
and like Linux does for modules AFAIR.
>
> 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.
>
> Signed-off-by: Daniel Kiper >
> ---
> v3 - suggestions/fixes:
>- reduce number of casts
> (suggested by Konrad Rzeszutek Wilk),
>- remove unneeded space at the end of line
> (suggested by Konrad Rzeszutek Wilk),
>- improve commit message
> (suggested by Konrad Rzeszutek Wilk).
> ---
> grub-core/loader/i386/multiboot_mbi.c |6 ++-
> grub-core/loader/multiboot.c | 12 --
> grub-core/loader/multiboot_elfxx.c| 28 ++
> grub-core/loader/multiboot_mbi2.c | 65
> ++---
> include/grub/multiboot.h |4 +-
> include/multiboot2.h | 24
> 6 files changed, 120 insertions(+), 19 deletions(-)
>
> diff --git a/grub-core/loader/i386/multiboot_mbi.c
> b/grub-core/loader/i386/multiboot_mbi.c
> index f60b702..4fc83ed 100644
> --- a/grub-core/loader/i386/multiboot_mbi.c
> +++ b/grub-core/loader/i386/multiboot_mbi.c
> @@ -72,7 +72,8 @@ load_kernel (grub_file_t file, const char *filename,
>grub_err_t err;
>if (grub_multiboot_quirks & GRUB_MULTIBOOT_QUIRK_BAD_KLUDGE)
> {
> - err = grub_multiboot_load_elf (file, filename, buffer);
> + err = grub_multiboot_load_elf (file, f
Re: [Xen-devel] [GRUB2 PATCH v3 4/4] multiboot2: Add support for relocatable images
On 02/03/16 17:51, 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 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. 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.
>
> As I saw multiboot2 protocol is able to consume ET_EXEC and ET_DYN ELF files.
> Potentially we can use ET_DYN file type. It can be build with gcc/ld -pie
> option.
> However, it contains a lot of unneeded stuff (e.g. INTERP, DYNAMIC,
> GNU_EH_FRAME
> program headers) and it could be quite difficult to drop them (Hmmm... Is it
> possible to build it properly with custom ld script?). So, I have checked
> ET_EXEC
> file type. Sadly in this case linker by default resolves all local symbol
> relocations
> and removes relocation related sections. Fortunately it is possible to leave
> them
> as is with simple -q/--emit-relocs ld option. However, output file is quite
> fragile
> and any operation on it should be done with great care (e.g. strip should be
> called
> with --strip-unneeded option). So, this solution is not perfect too. It means
> that
> maybe we should look for better solution. However, I think that we should not
> use
> any custom tools and focus on functionalities provided by compiler and
> binutils.
> In this context ld scripts looks quite promising but maybe you have better
> solutions.
> So, what do you think about that?
>
> 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.
>
> Signed-off-by: Daniel Kiper
> ---
> v3 - suggestions/fixes:
>- reduce number of casts
> (suggested by Konrad Rzeszutek Wilk),
>- remove unneeded space at the end of line
> (suggested by Konrad Rzeszutek Wilk),
>- improve commit message
> (suggested by Konrad Rzeszutek Wilk).
> ---
> grub-core/loader/i386/multiboot_mbi.c |6 ++-
> grub-core/loader/multiboot.c | 12 --
> grub-core/loader/multiboot_elfxx.c| 28 ++
> grub-core/loader/multiboot_mbi2.c | 65
> ++---
> include/grub/multiboot.h |4 +-
> include/multiboot2.h | 24
> 6 files changed, 120 insertions(+), 19 deletions(-)
>
> diff --git a/grub-core/loader/i386/multiboot_mbi.c
> b/grub-core/loader/i386/multiboot_mbi.c
> index f60b702..4fc83ed 100644
> --- a/grub-core/loader/i386/multiboot_mbi.c
> +++ b/grub-core/loader/i386/multiboot_mbi.c
> @@ -72,7 +72,8 @@ load_kernel (grub_file_t file, const char *filename,
>grub_err_t err;
>if (grub_multiboot_quirks & GRUB_MULTIBOOT_QUIRK_BAD_KLUDGE)
> {
> - err = grub_multiboot_load_elf (file, filename, buffer);
> + err = grub_multiboot_load_elf (file, filename, buffer, 0, 0, 0, 0,
> + GRUB_RELOCATOR_PREFERENCE_NONE, NULL, 0);
Uuh, really? You are adding 7 parameters for the reloc
[Xen-devel] [GRUB2 PATCH v3 4/4] multiboot2: Add support for relocatable images
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. 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.
As I saw multiboot2 protocol is able to consume ET_EXEC and ET_DYN ELF files.
Potentially we can use ET_DYN file type. It can be build with gcc/ld -pie
option.
However, it contains a lot of unneeded stuff (e.g. INTERP, DYNAMIC, GNU_EH_FRAME
program headers) and it could be quite difficult to drop them (Hmmm... Is it
possible to build it properly with custom ld script?). So, I have checked
ET_EXEC
file type. Sadly in this case linker by default resolves all local symbol
relocations
and removes relocation related sections. Fortunately it is possible to leave
them
as is with simple -q/--emit-relocs ld option. However, output file is quite
fragile
and any operation on it should be done with great care (e.g. strip should be
called
with --strip-unneeded option). So, this solution is not perfect too. It means
that
maybe we should look for better solution. However, I think that we should not
use
any custom tools and focus on functionalities provided by compiler and binutils.
In this context ld scripts looks quite promising but maybe you have better
solutions.
So, what do you think about that?
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.
Signed-off-by: Daniel Kiper
---
v3 - suggestions/fixes:
- reduce number of casts
(suggested by Konrad Rzeszutek Wilk),
- remove unneeded space at the end of line
(suggested by Konrad Rzeszutek Wilk),
- improve commit message
(suggested by Konrad Rzeszutek Wilk).
---
grub-core/loader/i386/multiboot_mbi.c |6 ++-
grub-core/loader/multiboot.c | 12 --
grub-core/loader/multiboot_elfxx.c| 28 ++
grub-core/loader/multiboot_mbi2.c | 65 ++---
include/grub/multiboot.h |4 +-
include/multiboot2.h | 24
6 files changed, 120 insertions(+), 19 deletions(-)
diff --git a/grub-core/loader/i386/multiboot_mbi.c
b/grub-core/loader/i386/multiboot_mbi.c
index f60b702..4fc83ed 100644
--- a/grub-core/loader/i386/multiboot_mbi.c
+++ b/grub-core/loader/i386/multiboot_mbi.c
@@ -72,7 +72,8 @@ load_kernel (grub_file_t file, const char *filename,
grub_err_t err;
if (grub_multiboot_quirks & GRUB_MULTIBOOT_QUIRK_BAD_KLUDGE)
{
- err = grub_multiboot_load_elf (file, filename, buffer);
+ err = grub_multiboot_load_elf (file, filename, buffer, 0, 0, 0, 0,
+GRUB_RELOCATOR_PREFERENCE_NONE, NULL, 0);
if (err == GRUB_ERR_NONE) {
return GRUB_ERR_NONE;
}
@@ -121,7 +122,8 @@ load_kernel (grub_file_t file, const char *filename,
return GRUB_ERR_NONE;
}
- return grub_multiboot_load_elf (file, filename, buffer);
+ return grub_multiboot_load_elf (file, filename, buf
