2009-02-27 23:04:46 +00:00
|
|
|
/*
|
|
|
|
|
* GRUB -- GRand Unified Bootloader
|
|
|
|
|
* Copyright (C) 1999,2000,2001,2002,2003,2004,2005,2007,2008,2009 Free Software Foundation, Inc.
|
|
|
|
|
*
|
|
|
|
|
* GRUB is free software: you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
|
* the Free Software Foundation, either version 3 of the License, or
|
|
|
|
|
* (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* GRUB is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with GRUB. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#if defined(MULTIBOOT_LOAD_ELF32)
|
|
|
|
|
# define XX 32
|
2010-04-03 12:14:48 +00:00
|
|
|
# define E_MACHINE MULTIBOOT_ELF32_MACHINE
|
2009-02-27 23:04:46 +00:00
|
|
|
# define ELFCLASSXX ELFCLASS32
|
|
|
|
|
# define Elf_Ehdr Elf32_Ehdr
|
|
|
|
|
# define Elf_Phdr Elf32_Phdr
|
2011-09-28 14:43:00 +00:00
|
|
|
# define Elf_Shdr Elf32_Shdr
|
2009-02-27 23:04:46 +00:00
|
|
|
#elif defined(MULTIBOOT_LOAD_ELF64)
|
|
|
|
|
# define XX 64
|
2010-04-03 12:14:48 +00:00
|
|
|
# define E_MACHINE MULTIBOOT_ELF64_MACHINE
|
2009-02-27 23:04:46 +00:00
|
|
|
# define ELFCLASSXX ELFCLASS64
|
|
|
|
|
# define Elf_Ehdr Elf64_Ehdr
|
|
|
|
|
# define Elf_Phdr Elf64_Phdr
|
2011-09-28 14:43:00 +00:00
|
|
|
# define Elf_Shdr Elf64_Shdr
|
2009-02-27 23:04:46 +00:00
|
|
|
#else
|
|
|
|
|
#error "I'm confused"
|
|
|
|
|
#endif
|
|
|
|
|
|
2009-11-25 22:39:59 +00:00
|
|
|
#include <grub/i386/relocator.h>
|
|
|
|
|
|
2009-02-27 23:04:46 +00:00
|
|
|
#define CONCAT(a,b) CONCAT_(a, b)
|
|
|
|
|
#define CONCAT_(a,b) a ## b
|
|
|
|
|
|
2012-02-10 15:48:48 +00:00
|
|
|
#pragma GCC diagnostic ignored "-Wcast-align"
|
|
|
|
|
|
2009-02-27 23:04:46 +00:00
|
|
|
/* Check if BUFFER contains ELF32 (or ELF64). */
|
|
|
|
|
static int
|
|
|
|
|
CONCAT(grub_multiboot_is_elf, XX) (void *buffer)
|
|
|
|
|
{
|
|
|
|
|
Elf_Ehdr *ehdr = (Elf_Ehdr *) buffer;
|
|
|
|
|
|
|
|
|
|
return ehdr->e_ident[EI_CLASS] == ELFCLASSXX;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static grub_err_t
|
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 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 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
CONCAT(grub_multiboot_load_elf, XX) (mbi_load_data_t *mld)
|
2009-02-27 23:04:46 +00:00
|
|
|
{
|
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 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 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
Elf_Ehdr *ehdr = (Elf_Ehdr *) mld->buffer;
|
2009-02-27 23:04:46 +00:00
|
|
|
char *phdr_base;
|
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 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 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
grub_err_t err;
|
|
|
|
|
grub_relocator_chunk_t ch;
|
2018-06-12 18:04:09 +00:00
|
|
|
grub_uint32_t load_offset = 0, load_size;
|
2009-02-27 23:04:46 +00:00
|
|
|
int i;
|
2018-06-12 18:04:09 +00:00
|
|
|
void *source = NULL;
|
2009-02-27 23:04:46 +00:00
|
|
|
|
|
|
|
|
if (ehdr->e_ident[EI_MAG0] != ELFMAG0
|
|
|
|
|
|| ehdr->e_ident[EI_MAG1] != ELFMAG1
|
|
|
|
|
|| ehdr->e_ident[EI_MAG2] != ELFMAG2
|
|
|
|
|
|| ehdr->e_ident[EI_MAG3] != ELFMAG3
|
2012-02-08 18:26:01 +00:00
|
|
|
|| ehdr->e_ident[EI_DATA] != ELFDATA2LSB)
|
2012-02-26 16:28:05 +00:00
|
|
|
return grub_error(GRUB_ERR_UNKNOWN_OS, N_("invalid arch-independent ELF magic"));
|
2012-02-08 18:26:01 +00:00
|
|
|
|
|
|
|
|
if (ehdr->e_ident[EI_CLASS] != ELFCLASSXX || ehdr->e_machine != E_MACHINE
|
|
|
|
|
|| ehdr->e_version != EV_CURRENT)
|
2012-02-26 16:28:05 +00:00
|
|
|
return grub_error (GRUB_ERR_UNKNOWN_OS, N_("invalid arch-dependent ELF magic"));
|
2009-06-10 21:04:23 +00:00
|
|
|
|
2009-03-11 21:27:01 +00:00
|
|
|
if (ehdr->e_type != ET_EXEC && ehdr->e_type != ET_DYN)
|
2012-02-08 18:26:01 +00:00
|
|
|
return grub_error (GRUB_ERR_UNKNOWN_OS, N_("this ELF file is not of the right type"));
|
2009-06-10 21:04:23 +00:00
|
|
|
|
2009-02-27 23:04:46 +00:00
|
|
|
/* FIXME: Should we support program headers at strange locations? */
|
2016-01-09 16:58:51 +00:00
|
|
|
if (ehdr->e_phoff + (grub_uint32_t) ehdr->e_phnum * ehdr->e_phentsize > MULTIBOOT_SEARCH)
|
2009-02-27 23:04:46 +00:00
|
|
|
return grub_error (GRUB_ERR_BAD_OS, "program header at a too high offset");
|
|
|
|
|
|
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 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 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
phdr_base = (char *) mld->buffer + ehdr->e_phoff;
|
2009-02-27 23:04:46 +00:00
|
|
|
#define phdr(i) ((Elf_Phdr *) (phdr_base + (i) * ehdr->e_phentsize))
|
|
|
|
|
|
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 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 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
mld->link_base_addr = ~0;
|
|
|
|
|
|
|
|
|
|
/* Calculate lowest and highest load address. */
|
|
|
|
|
for (i = 0; i < ehdr->e_phnum; i++)
|
|
|
|
|
if (phdr(i)->p_type == PT_LOAD)
|
|
|
|
|
{
|
|
|
|
|
mld->link_base_addr = grub_min (mld->link_base_addr, phdr(i)->p_paddr);
|
|
|
|
|
highest_load = grub_max (highest_load, phdr(i)->p_paddr + phdr(i)->p_memsz);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#ifdef MULTIBOOT_LOAD_ELF64
|
|
|
|
|
if (highest_load >= 0x100000000)
|
|
|
|
|
return grub_error (GRUB_ERR_BAD_OS, "segment crosses 4 GiB border");
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
if (mld->relocatable)
|
|
|
|
|
{
|
2018-06-12 18:04:09 +00:00
|
|
|
load_size = highest_load - mld->link_base_addr;
|
|
|
|
|
|
|
|
|
|
grub_dprintf ("multiboot_loader", "align=0x%lx, preference=0x%x, "
|
|
|
|
|
"load_size=0x%x, avoid_efi_boot_services=%d\n",
|
|
|
|
|
(long) mld->align, mld->preference, load_size,
|
|
|
|
|
mld->avoid_efi_boot_services);
|
|
|
|
|
|
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 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 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
if (load_size > mld->max_addr || mld->min_addr > mld->max_addr - load_size)
|
|
|
|
|
return grub_error (GRUB_ERR_BAD_OS, "invalid min/max address and/or load size");
|
|
|
|
|
|
2020-07-08 01:44:38 +00:00
|
|
|
err = grub_relocator_alloc_chunk_align_safe (GRUB_MULTIBOOT (relocator), &ch,
|
|
|
|
|
mld->min_addr, mld->max_addr,
|
|
|
|
|
load_size, mld->align ? mld->align : 1,
|
|
|
|
|
mld->preference, mld->avoid_efi_boot_services);
|
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 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 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
|
2018-06-12 18:04:09 +00:00
|
|
|
if (err)
|
|
|
|
|
{
|
|
|
|
|
grub_dprintf ("multiboot_loader", "Cannot allocate memory for OS image\n");
|
|
|
|
|
return err;
|
|
|
|
|
}
|
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 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 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
|
2018-06-12 18:04:09 +00:00
|
|
|
mld->load_base_addr = get_physical_target_address (ch);
|
|
|
|
|
source = get_virtual_current_address (ch);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
mld->load_base_addr = mld->link_base_addr;
|
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 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 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
|
2018-06-12 18:04:09 +00:00
|
|
|
grub_dprintf ("multiboot_loader", "relocatable=%d, link_base_addr=0x%x, "
|
2018-06-29 12:15:11 +00:00
|
|
|
"load_base_addr=0x%x\n", mld->relocatable,
|
2018-06-12 18:04:09 +00:00
|
|
|
mld->link_base_addr, mld->load_base_addr);
|
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 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 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
|
2009-02-27 23:04:46 +00:00
|
|
|
/* Load every loadable segment in memory. */
|
|
|
|
|
for (i = 0; i < ehdr->e_phnum; i++)
|
|
|
|
|
{
|
2010-08-24 17:33:08 +00:00
|
|
|
if (phdr(i)->p_type == PT_LOAD)
|
2009-02-27 23:04:46 +00:00
|
|
|
{
|
2013-10-28 14:23:46 +00:00
|
|
|
|
2009-03-21 23:02:12 +00:00
|
|
|
grub_dprintf ("multiboot_loader", "segment %d: paddr=0x%lx, memsz=0x%lx, vaddr=0x%lx\n",
|
|
|
|
|
i, (long) phdr(i)->p_paddr, (long) phdr(i)->p_memsz, (long) phdr(i)->p_vaddr);
|
2009-02-27 23:04:46 +00:00
|
|
|
|
2018-06-12 18:04:09 +00:00
|
|
|
if (mld->relocatable)
|
|
|
|
|
{
|
|
|
|
|
load_offset = phdr(i)->p_paddr - mld->link_base_addr;
|
|
|
|
|
grub_dprintf ("multiboot_loader", "segment %d: load_offset=0x%x\n", i, load_offset);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
err = grub_relocator_alloc_chunk_addr (GRUB_MULTIBOOT (relocator), &ch,
|
|
|
|
|
phdr(i)->p_paddr, phdr(i)->p_memsz);
|
|
|
|
|
|
|
|
|
|
if (err)
|
|
|
|
|
{
|
|
|
|
|
grub_dprintf ("multiboot_loader", "Cannot allocate memory for OS image\n");
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
source = get_virtual_current_address (ch);
|
|
|
|
|
}
|
2010-01-10 14:06:17 +00:00
|
|
|
|
2010-08-24 17:33:08 +00:00
|
|
|
if (phdr(i)->p_filesz != 0)
|
|
|
|
|
{
|
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 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 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
if (grub_file_seek (mld->file, (grub_off_t) phdr(i)->p_offset)
|
2010-08-24 17:33:08 +00:00
|
|
|
== (grub_off_t) -1)
|
2012-02-08 18:26:01 +00:00
|
|
|
return grub_errno;
|
2010-08-24 17:33:08 +00:00
|
|
|
|
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 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 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
if (grub_file_read (mld->file, (grub_uint8_t *) source + load_offset, phdr(i)->p_filesz)
|
2010-08-24 17:33:08 +00:00
|
|
|
!= (grub_ssize_t) phdr(i)->p_filesz)
|
2012-02-08 18:26:01 +00:00
|
|
|
{
|
|
|
|
|
if (!grub_errno)
|
|
|
|
|
grub_error (GRUB_ERR_FILE_READ_ERROR, N_("premature end of file %s"),
|
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 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 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
mld->filename);
|
2012-02-08 18:26:01 +00:00
|
|
|
return grub_errno;
|
|
|
|
|
}
|
2010-08-24 17:33:08 +00:00
|
|
|
}
|
2009-02-27 23:04:46 +00:00
|
|
|
|
|
|
|
|
if (phdr(i)->p_filesz < phdr(i)->p_memsz)
|
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 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 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
grub_memset ((grub_uint8_t *) source + load_offset + phdr(i)->p_filesz, 0,
|
2009-02-27 23:04:46 +00:00
|
|
|
phdr(i)->p_memsz - phdr(i)->p_filesz);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2009-03-21 23:02:12 +00:00
|
|
|
for (i = 0; i < ehdr->e_phnum; i++)
|
2009-06-10 21:04:23 +00:00
|
|
|
if (phdr(i)->p_vaddr <= ehdr->e_entry
|
2009-03-21 23:02:12 +00:00
|
|
|
&& phdr(i)->p_vaddr + phdr(i)->p_memsz > ehdr->e_entry)
|
|
|
|
|
{
|
2017-08-14 10:51:26 +00:00
|
|
|
GRUB_MULTIBOOT (payload_eip) = (ehdr->e_entry - phdr(i)->p_vaddr)
|
2010-01-10 14:06:17 +00:00
|
|
|
+ phdr(i)->p_paddr;
|
2013-07-16 16:37:44 +00:00
|
|
|
#ifdef MULTIBOOT_LOAD_ELF64
|
|
|
|
|
# ifdef __mips
|
|
|
|
|
/* We still in 32-bit mode. */
|
|
|
|
|
if ((ehdr->e_entry - phdr(i)->p_vaddr)
|
|
|
|
|
+ phdr(i)->p_paddr < 0xffffffff80000000ULL)
|
|
|
|
|
return grub_error (GRUB_ERR_BAD_OS, "invalid entry point for ELF64");
|
|
|
|
|
# else
|
|
|
|
|
/* We still in 32-bit mode. */
|
|
|
|
|
if ((ehdr->e_entry - phdr(i)->p_vaddr)
|
|
|
|
|
+ phdr(i)->p_paddr > 0xffffffff)
|
|
|
|
|
return grub_error (GRUB_ERR_BAD_OS, "invalid entry point for ELF64");
|
|
|
|
|
# endif
|
|
|
|
|
#endif
|
2009-03-21 23:02:12 +00:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (i == ehdr->e_phnum)
|
|
|
|
|
return grub_error (GRUB_ERR_BAD_OS, "entry point isn't in a segment");
|
2009-02-27 23:04:46 +00:00
|
|
|
|
2010-08-29 13:45:21 +00:00
|
|
|
#if defined (__i386__) || defined (__x86_64__)
|
|
|
|
|
|
|
|
|
|
#elif defined (__mips)
|
2017-08-14 10:51:26 +00:00
|
|
|
GRUB_MULTIBOOT (payload_eip) |= 0x80000000;
|
2010-08-29 13:45:21 +00:00
|
|
|
#else
|
|
|
|
|
#error Please complete this
|
|
|
|
|
#endif
|
|
|
|
|
|
2010-01-14 18:14:24 +00:00
|
|
|
if (ehdr->e_shnum)
|
|
|
|
|
{
|
|
|
|
|
grub_uint8_t *shdr, *shdrptr;
|
|
|
|
|
|
2020-06-15 16:26:01 +00:00
|
|
|
shdr = grub_calloc (ehdr->e_shnum, ehdr->e_shentsize);
|
2010-01-14 18:14:24 +00:00
|
|
|
if (!shdr)
|
|
|
|
|
return grub_errno;
|
|
|
|
|
|
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 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 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
if (grub_file_seek (mld->file, ehdr->e_shoff) == (grub_off_t) -1)
|
2015-06-20 20:38:18 +00:00
|
|
|
{
|
|
|
|
|
grub_free (shdr);
|
|
|
|
|
return grub_errno;
|
|
|
|
|
}
|
2010-01-14 18:14:24 +00:00
|
|
|
|
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 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 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
if (grub_file_read (mld->file, shdr, (grub_uint32_t) ehdr->e_shnum * ehdr->e_shentsize)
|
2010-01-14 18:14:24 +00:00
|
|
|
!= (grub_ssize_t) ehdr->e_shnum * ehdr->e_shentsize)
|
2012-02-08 18:26:01 +00:00
|
|
|
{
|
|
|
|
|
if (!grub_errno)
|
|
|
|
|
grub_error (GRUB_ERR_FILE_READ_ERROR, N_("premature end of file %s"),
|
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 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 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
mld->filename);
|
2012-02-08 18:26:01 +00:00
|
|
|
return grub_errno;
|
|
|
|
|
}
|
2010-01-14 18:14:24 +00:00
|
|
|
|
|
|
|
|
for (shdrptr = shdr, i = 0; i < ehdr->e_shnum;
|
|
|
|
|
shdrptr += ehdr->e_shentsize, i++)
|
|
|
|
|
{
|
|
|
|
|
Elf_Shdr *sh = (Elf_Shdr *) shdrptr;
|
|
|
|
|
void *src;
|
|
|
|
|
grub_addr_t target;
|
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 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 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
|
|
|
|
|
if (mld->mbi_ver >= 2 && (sh->sh_type == SHT_REL || sh->sh_type == SHT_RELA))
|
|
|
|
|
return grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET, "ELF files with relocs are not supported yet");
|
2010-01-14 18:14:24 +00:00
|
|
|
|
|
|
|
|
/* This section is a loaded section,
|
|
|
|
|
so we don't care. */
|
|
|
|
|
if (sh->sh_addr != 0)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
/* This section is empty, so we don't care. */
|
|
|
|
|
if (sh->sh_size == 0)
|
|
|
|
|
continue;
|
|
|
|
|
|
2017-08-14 10:51:26 +00:00
|
|
|
err = grub_relocator_alloc_chunk_align (GRUB_MULTIBOOT (relocator), &ch, 0,
|
2020-07-08 01:44:38 +00:00
|
|
|
UP_TO_TOP32 (sh->sh_size),
|
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 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 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
sh->sh_size, sh->sh_addralign,
|
|
|
|
|
GRUB_RELOCATOR_PREFERENCE_NONE,
|
|
|
|
|
mld->avoid_efi_boot_services);
|
|
|
|
|
if (err)
|
|
|
|
|
{
|
|
|
|
|
grub_dprintf ("multiboot_loader", "Error loading shdr %d\n", i);
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
src = get_virtual_current_address (ch);
|
|
|
|
|
target = get_physical_target_address (ch);
|
|
|
|
|
|
|
|
|
|
if (grub_file_seek (mld->file, sh->sh_offset) == (grub_off_t) -1)
|
2012-02-08 18:26:01 +00:00
|
|
|
return grub_errno;
|
2010-01-14 18:14:24 +00:00
|
|
|
|
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 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 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
if (grub_file_read (mld->file, src, sh->sh_size)
|
2010-01-14 18:14:24 +00:00
|
|
|
!= (grub_ssize_t) sh->sh_size)
|
2012-02-08 18:26:01 +00:00
|
|
|
{
|
|
|
|
|
if (!grub_errno)
|
|
|
|
|
grub_error (GRUB_ERR_FILE_READ_ERROR, N_("premature end of file %s"),
|
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 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 2-3 weeks.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-07-17 19:02:09 +00:00
|
|
|
mld->filename);
|
2012-02-08 18:26:01 +00:00
|
|
|
return grub_errno;
|
|
|
|
|
}
|
2010-01-14 18:14:24 +00:00
|
|
|
sh->sh_addr = target;
|
|
|
|
|
}
|
2017-08-14 10:51:26 +00:00
|
|
|
GRUB_MULTIBOOT (add_elfsyms) (ehdr->e_shnum, ehdr->e_shentsize,
|
|
|
|
|
ehdr->e_shstrndx, shdr);
|
2010-01-14 18:14:24 +00:00
|
|
|
}
|
|
|
|
|
|
2009-02-27 23:04:46 +00:00
|
|
|
#undef phdr
|
|
|
|
|
|
|
|
|
|
return grub_errno;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#undef XX
|
|
|
|
|
#undef E_MACHINE
|
|
|
|
|
#undef ELFCLASSXX
|
|
|
|
|
#undef Elf_Ehdr
|
|
|
|
|
#undef Elf_Phdr
|
2011-09-28 14:43:00 +00:00
|
|
|
#undef Elf_Shdr
|