2010-01-16 15:25:43 +00:00
|
|
|
/*
|
|
|
|
* GRUB -- GRand Unified Bootloader
|
2013-10-28 14:53:39 +00:00
|
|
|
* Copyright (C) 1999,2000,2001,2002,2003,2004,2005,2007,2008,2009,2010,2011,2012,2013 Free Software Foundation, Inc.
|
2010-01-16 15:25:43 +00:00
|
|
|
*
|
|
|
|
* 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/>.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <grub/memory.h>
|
|
|
|
#ifdef GRUB_MACHINE_PCBIOS
|
|
|
|
#include <grub/machine/biosnum.h>
|
2010-09-15 09:42:18 +00:00
|
|
|
#include <grub/machine/apm.h>
|
2010-09-04 15:10:10 +00:00
|
|
|
#include <grub/machine/memory.h>
|
2010-01-16 15:25:43 +00:00
|
|
|
#endif
|
2017-08-14 10:51:26 +00:00
|
|
|
#include <grub/multiboot2.h>
|
2010-01-16 15:25:43 +00:00
|
|
|
#include <grub/cpu/multiboot.h>
|
2010-03-10 10:40:20 +00:00
|
|
|
#include <grub/cpu/relocator.h>
|
2010-01-16 15:25:43 +00:00
|
|
|
#include <grub/disk.h>
|
|
|
|
#include <grub/device.h>
|
|
|
|
#include <grub/partition.h>
|
|
|
|
#include <grub/mm.h>
|
|
|
|
#include <grub/misc.h>
|
|
|
|
#include <grub/env.h>
|
|
|
|
#include <grub/video.h>
|
2010-09-21 06:37:50 +00:00
|
|
|
#include <grub/acpi.h>
|
2012-02-12 14:25:25 +00:00
|
|
|
#include <grub/i18n.h>
|
2013-10-28 14:53:39 +00:00
|
|
|
#include <grub/net.h>
|
2013-11-09 16:32:37 +00:00
|
|
|
#include <grub/lib/cmdline.h>
|
2010-01-16 15:25:43 +00:00
|
|
|
|
2010-09-22 15:13:21 +00:00
|
|
|
#if defined (GRUB_MACHINE_EFI)
|
|
|
|
#include <grub/efi/efi.h>
|
|
|
|
#endif
|
|
|
|
|
2010-05-01 12:06:53 +00:00
|
|
|
#if defined (GRUB_MACHINE_PCBIOS) || defined (GRUB_MACHINE_COREBOOT) || defined (GRUB_MACHINE_MULTIBOOT) || defined (GRUB_MACHINE_QEMU)
|
2010-01-16 15:25:43 +00:00
|
|
|
#include <grub/i386/pc/vbe.h>
|
|
|
|
#define HAS_VGA_TEXT 1
|
|
|
|
#else
|
|
|
|
#define HAS_VGA_TEXT 0
|
|
|
|
#endif
|
|
|
|
|
|
|
|
struct module
|
|
|
|
{
|
|
|
|
struct module *next;
|
|
|
|
grub_addr_t start;
|
|
|
|
grub_size_t size;
|
|
|
|
char *cmdline;
|
|
|
|
int cmdline_size;
|
|
|
|
};
|
|
|
|
|
2011-03-23 11:05:13 +00:00
|
|
|
static struct module *modules, *modules_last;
|
2010-01-16 15:25:43 +00:00
|
|
|
static grub_size_t cmdline_size;
|
|
|
|
static grub_size_t total_modcmd;
|
|
|
|
static unsigned modcnt;
|
|
|
|
static char *cmdline = NULL;
|
|
|
|
static int bootdev_set;
|
|
|
|
static grub_uint32_t biosdev, slice, part;
|
2010-05-02 17:39:46 +00:00
|
|
|
static grub_size_t elf_sec_num, elf_sec_entsize;
|
|
|
|
static unsigned elf_sec_shstrndx;
|
|
|
|
static void *elf_sections;
|
2013-12-13 11:56:14 +00:00
|
|
|
static int keep_bs = 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
|
|
|
static grub_uint32_t load_base_addr;
|
2010-05-02 17:39:46 +00:00
|
|
|
|
|
|
|
void
|
2017-08-14 10:51:26 +00:00
|
|
|
grub_multiboot2_add_elfsyms (grub_size_t num, grub_size_t entsize,
|
2010-05-02 17:39:46 +00:00
|
|
|
unsigned shndx, void *data)
|
|
|
|
{
|
|
|
|
elf_sec_num = num;
|
|
|
|
elf_sec_shstrndx = shndx;
|
|
|
|
elf_sec_entsize = entsize;
|
|
|
|
elf_sections = data;
|
|
|
|
}
|
2010-01-16 15:25:43 +00:00
|
|
|
|
2015-01-26 08:43:52 +00:00
|
|
|
static struct multiboot_header *
|
|
|
|
find_header (grub_properly_aligned_t *buffer, grub_ssize_t len)
|
|
|
|
{
|
|
|
|
struct multiboot_header *header;
|
|
|
|
/* Look for the multiboot header in the buffer. The header should
|
|
|
|
be at least 12 bytes and aligned on a 4-byte boundary. */
|
|
|
|
for (header = (struct multiboot_header *) buffer;
|
|
|
|
((char *) header <= (char *) buffer + len - 12);
|
|
|
|
header = (struct multiboot_header *) ((grub_uint32_t *) header + MULTIBOOT_HEADER_ALIGN / 4))
|
|
|
|
{
|
2017-08-14 10:51:26 +00:00
|
|
|
if (header->magic == MULTIBOOT2_HEADER_MAGIC
|
2015-01-26 08:43:52 +00:00
|
|
|
&& !(header->magic + header->architecture
|
|
|
|
+ header->header_length + header->checksum)
|
2017-08-14 10:51:26 +00:00
|
|
|
&& header->architecture == MULTIBOOT2_ARCHITECTURE_CURRENT)
|
2015-01-26 08:43:52 +00:00
|
|
|
return header;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2010-03-10 10:40:20 +00:00
|
|
|
grub_err_t
|
2017-08-14 10:51:26 +00:00
|
|
|
grub_multiboot2_load (grub_file_t file, const char *filename)
|
2010-03-10 10:40:20 +00:00
|
|
|
{
|
|
|
|
grub_ssize_t len;
|
|
|
|
struct multiboot_header *header;
|
|
|
|
grub_err_t err;
|
|
|
|
struct multiboot_header_tag *tag;
|
|
|
|
struct multiboot_header_tag_address *addr_tag = NULL;
|
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
|
|
|
struct multiboot_header_tag_relocatable *rel_tag;
|
2015-07-17 17:43:42 +00:00
|
|
|
int entry_specified = 0, efi_entry_specified = 0;
|
|
|
|
grub_addr_t entry = 0, efi_entry = 0;
|
2010-03-10 10:40:20 +00:00
|
|
|
grub_uint32_t console_required = 0;
|
|
|
|
struct multiboot_header_tag_framebuffer *fbtag = NULL;
|
2017-08-14 10:51:26 +00:00
|
|
|
int accepted_consoles = GRUB_MULTIBOOT2_CONSOLE_EGA_TEXT;
|
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
|
|
|
mbi_load_data_t mld;
|
2010-03-10 10:40:20 +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
|
|
|
mld.mbi_ver = 2;
|
|
|
|
mld.relocatable = 0;
|
|
|
|
|
|
|
|
mld.buffer = grub_malloc (MULTIBOOT_SEARCH);
|
|
|
|
if (!mld.buffer)
|
2010-03-10 10:40:20 +00:00
|
|
|
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
|
|
|
len = grub_file_read (file, mld.buffer, MULTIBOOT_SEARCH);
|
2010-03-10 10:40:20 +00:00
|
|
|
if (len < 32)
|
|
|
|
{
|
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_free (mld.buffer);
|
2012-02-12 14:25:25 +00:00
|
|
|
return grub_error (GRUB_ERR_BAD_OS, N_("premature end of file %s"), filename);
|
2010-03-10 10:40:20 +00:00
|
|
|
}
|
|
|
|
|
2011-12-13 15:22:44 +00:00
|
|
|
COMPILE_TIME_ASSERT (MULTIBOOT_HEADER_ALIGN % 4 == 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
|
|
|
header = find_header (mld.buffer, len);
|
2010-03-10 10:40:20 +00:00
|
|
|
|
|
|
|
if (header == 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
|
|
|
grub_free (mld.buffer);
|
2010-03-10 10:40:20 +00:00
|
|
|
return grub_error (GRUB_ERR_BAD_ARGUMENT, "no multiboot header found");
|
|
|
|
}
|
|
|
|
|
2011-12-13 15:22:44 +00:00
|
|
|
COMPILE_TIME_ASSERT (MULTIBOOT_TAG_ALIGN % 4 == 0);
|
|
|
|
|
2013-12-13 11:56:14 +00:00
|
|
|
keep_bs = 0;
|
|
|
|
|
2010-03-10 10:40:20 +00:00
|
|
|
for (tag = (struct multiboot_header_tag *) (header + 1);
|
|
|
|
tag->type != MULTIBOOT_TAG_TYPE_END;
|
2011-12-13 15:22:44 +00:00
|
|
|
tag = (struct multiboot_header_tag *) ((grub_uint32_t *) tag + ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN) / 4))
|
2010-03-10 10:40:20 +00:00
|
|
|
switch (tag->type)
|
|
|
|
{
|
|
|
|
case MULTIBOOT_HEADER_TAG_INFORMATION_REQUEST:
|
|
|
|
{
|
|
|
|
unsigned i;
|
|
|
|
struct multiboot_header_tag_information_request *request_tag
|
|
|
|
= (struct multiboot_header_tag_information_request *) tag;
|
|
|
|
if (request_tag->flags & MULTIBOOT_HEADER_TAG_OPTIONAL)
|
|
|
|
break;
|
2015-01-30 17:59:24 +00:00
|
|
|
for (i = 0; i < (request_tag->size - sizeof (*request_tag))
|
2010-03-10 10:40:20 +00:00
|
|
|
/ sizeof (request_tag->requests[0]); i++)
|
|
|
|
switch (request_tag->requests[i])
|
|
|
|
{
|
|
|
|
case MULTIBOOT_TAG_TYPE_END:
|
|
|
|
case MULTIBOOT_TAG_TYPE_CMDLINE:
|
|
|
|
case MULTIBOOT_TAG_TYPE_BOOT_LOADER_NAME:
|
|
|
|
case MULTIBOOT_TAG_TYPE_MODULE:
|
|
|
|
case MULTIBOOT_TAG_TYPE_BASIC_MEMINFO:
|
|
|
|
case MULTIBOOT_TAG_TYPE_BOOTDEV:
|
|
|
|
case MULTIBOOT_TAG_TYPE_MMAP:
|
|
|
|
case MULTIBOOT_TAG_TYPE_FRAMEBUFFER:
|
2010-03-28 11:46:42 +00:00
|
|
|
case MULTIBOOT_TAG_TYPE_VBE:
|
2010-03-10 10:40:20 +00:00
|
|
|
case MULTIBOOT_TAG_TYPE_ELF_SECTIONS:
|
|
|
|
case MULTIBOOT_TAG_TYPE_APM:
|
2010-09-21 00:19:29 +00:00
|
|
|
case MULTIBOOT_TAG_TYPE_EFI32:
|
|
|
|
case MULTIBOOT_TAG_TYPE_EFI64:
|
2010-09-21 06:37:50 +00:00
|
|
|
case MULTIBOOT_TAG_TYPE_ACPI_OLD:
|
|
|
|
case MULTIBOOT_TAG_TYPE_ACPI_NEW:
|
2013-10-28 14:53:39 +00:00
|
|
|
case MULTIBOOT_TAG_TYPE_NETWORK:
|
2013-10-28 14:40:34 +00:00
|
|
|
case MULTIBOOT_TAG_TYPE_EFI_MMAP:
|
2013-12-13 11:56:14 +00:00
|
|
|
case MULTIBOOT_TAG_TYPE_EFI_BS:
|
2014-11-19 23:09:54 +00:00
|
|
|
case MULTIBOOT_TAG_TYPE_EFI32_IH:
|
|
|
|
case MULTIBOOT_TAG_TYPE_EFI64_IH:
|
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
|
|
|
case MULTIBOOT_TAG_TYPE_LOAD_BASE_ADDR:
|
2010-09-15 22:54:21 +00:00
|
|
|
break;
|
|
|
|
|
2010-03-10 10:40:20 +00:00
|
|
|
default:
|
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_free (mld.buffer);
|
2010-03-10 10:40:20 +00:00
|
|
|
return grub_error (GRUB_ERR_UNKNOWN_OS,
|
|
|
|
"unsupported information tag: 0x%x",
|
|
|
|
request_tag->requests[i]);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
case MULTIBOOT_HEADER_TAG_ADDRESS:
|
|
|
|
addr_tag = (struct multiboot_header_tag_address *) tag;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS:
|
|
|
|
entry_specified = 1;
|
|
|
|
entry = ((struct multiboot_header_tag_entry_address *) tag)->entry_addr;
|
|
|
|
break;
|
|
|
|
|
2015-07-17 17:43:42 +00:00
|
|
|
case MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS_EFI64:
|
|
|
|
#if defined (GRUB_MACHINE_EFI) && defined (__x86_64__)
|
|
|
|
efi_entry_specified = 1;
|
|
|
|
efi_entry = ((struct multiboot_header_tag_entry_address *) tag)->entry_addr;
|
|
|
|
#endif
|
|
|
|
break;
|
|
|
|
|
2010-03-10 10:40:20 +00:00
|
|
|
case MULTIBOOT_HEADER_TAG_CONSOLE_FLAGS:
|
|
|
|
if (!(((struct multiboot_header_tag_console_flags *) tag)->console_flags
|
|
|
|
& MULTIBOOT_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED))
|
2017-08-14 10:51:26 +00:00
|
|
|
accepted_consoles &= ~GRUB_MULTIBOOT2_CONSOLE_EGA_TEXT;
|
2010-03-10 10:40:20 +00:00
|
|
|
if (((struct multiboot_header_tag_console_flags *) tag)->console_flags
|
|
|
|
& MULTIBOOT_CONSOLE_FLAGS_CONSOLE_REQUIRED)
|
|
|
|
console_required = 1;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case MULTIBOOT_HEADER_TAG_FRAMEBUFFER:
|
|
|
|
fbtag = (struct multiboot_header_tag_framebuffer *) tag;
|
2017-08-14 10:51:26 +00:00
|
|
|
accepted_consoles |= GRUB_MULTIBOOT2_CONSOLE_FRAMEBUFFER;
|
2010-03-10 10:40:20 +00:00
|
|
|
break;
|
|
|
|
|
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
|
|
|
case MULTIBOOT_HEADER_TAG_RELOCATABLE:
|
|
|
|
mld.relocatable = 1;
|
|
|
|
rel_tag = (struct multiboot_header_tag_relocatable *) tag;
|
|
|
|
mld.min_addr = rel_tag->min_addr;
|
|
|
|
mld.max_addr = rel_tag->max_addr;
|
|
|
|
mld.align = rel_tag->align;
|
|
|
|
switch (rel_tag->preference)
|
|
|
|
{
|
|
|
|
case MULTIBOOT_LOAD_PREFERENCE_LOW:
|
|
|
|
mld.preference = GRUB_RELOCATOR_PREFERENCE_LOW;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case MULTIBOOT_LOAD_PREFERENCE_HIGH:
|
|
|
|
mld.preference = GRUB_RELOCATOR_PREFERENCE_HIGH;
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
mld.preference = GRUB_RELOCATOR_PREFERENCE_NONE;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
2010-03-10 10:40:20 +00:00
|
|
|
/* GRUB always page-aligns modules. */
|
|
|
|
case MULTIBOOT_HEADER_TAG_MODULE_ALIGN:
|
|
|
|
break;
|
|
|
|
|
2013-12-13 11:56:14 +00:00
|
|
|
case MULTIBOOT_HEADER_TAG_EFI_BS:
|
2015-07-17 17:43:42 +00:00
|
|
|
#ifdef GRUB_MACHINE_EFI
|
2013-12-13 11:56:14 +00:00
|
|
|
keep_bs = 1;
|
2015-07-17 17:43:42 +00:00
|
|
|
#endif
|
2013-12-13 11:56:14 +00:00
|
|
|
break;
|
|
|
|
|
2010-03-10 10:40:20 +00:00
|
|
|
default:
|
|
|
|
if (! (tag->flags & MULTIBOOT_HEADER_TAG_OPTIONAL))
|
|
|
|
{
|
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_free (mld.buffer);
|
2010-03-10 10:40:20 +00:00
|
|
|
return grub_error (GRUB_ERR_UNKNOWN_OS,
|
|
|
|
"unsupported tag: 0x%x", tag->type);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2015-07-17 17:43:42 +00:00
|
|
|
if (addr_tag && !entry_specified && !(keep_bs && efi_entry_specified))
|
2010-03-10 10:40:20 +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
|
|
|
grub_free (mld.buffer);
|
2010-03-10 10:40:20 +00:00
|
|
|
return grub_error (GRUB_ERR_UNKNOWN_OS,
|
|
|
|
"load address tag without entry address tag");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (addr_tag)
|
|
|
|
{
|
2013-12-17 14:14:50 +00:00
|
|
|
grub_uint64_t load_addr = (addr_tag->load_addr + 1)
|
|
|
|
? addr_tag->load_addr : (addr_tag->header_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
|
|
|
- ((char *) header - (char *) mld.buffer));
|
|
|
|
int offset = ((char *) header - (char *) mld.buffer -
|
2013-12-17 14:14:50 +00:00
|
|
|
(addr_tag->header_addr - load_addr));
|
2010-03-10 10:40:20 +00:00
|
|
|
int load_size = ((addr_tag->load_end_addr == 0) ? file->size - offset :
|
|
|
|
addr_tag->load_end_addr - addr_tag->load_addr);
|
|
|
|
grub_size_t code_size;
|
2010-04-01 20:17:26 +00:00
|
|
|
void *source;
|
2010-04-21 17:13:45 +00:00
|
|
|
grub_relocator_chunk_t ch;
|
2010-03-10 10:40:20 +00:00
|
|
|
|
|
|
|
if (addr_tag->bss_end_addr)
|
2013-12-17 14:14:50 +00:00
|
|
|
code_size = (addr_tag->bss_end_addr - load_addr);
|
2010-03-10 10:40:20 +00:00
|
|
|
else
|
|
|
|
code_size = load_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
|
|
|
if (mld.relocatable)
|
|
|
|
{
|
|
|
|
if (code_size > mld.max_addr || mld.min_addr > mld.max_addr - code_size)
|
|
|
|
{
|
|
|
|
grub_free (mld.buffer);
|
|
|
|
return grub_error (GRUB_ERR_BAD_OS, "invalid min/max address and/or load size");
|
|
|
|
}
|
|
|
|
|
2017-08-14 10:51:26 +00:00
|
|
|
err = grub_relocator_alloc_chunk_align (grub_multiboot2_relocator, &ch,
|
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.min_addr, mld.max_addr - code_size,
|
|
|
|
code_size, mld.align ? mld.align : 1,
|
|
|
|
mld.preference, keep_bs);
|
|
|
|
}
|
|
|
|
else
|
2017-08-14 10:51:26 +00:00
|
|
|
err = grub_relocator_alloc_chunk_addr (grub_multiboot2_relocator,
|
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
|
|
|
&ch, load_addr, code_size);
|
2010-04-01 20:17:26 +00:00
|
|
|
if (err)
|
2010-03-10 10:40:20 +00:00
|
|
|
{
|
2010-04-01 20:17:26 +00:00
|
|
|
grub_dprintf ("multiboot_loader", "Error loading aout kludge\n");
|
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_free (mld.buffer);
|
2010-04-01 20:17:26 +00:00
|
|
|
return err;
|
2010-03-10 10:40:20 +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
|
|
|
mld.link_base_addr = load_addr;
|
|
|
|
mld.load_base_addr = get_physical_target_address (ch);
|
2010-04-21 17:13:45 +00:00
|
|
|
source = get_virtual_current_address (ch);
|
2010-03-10 10:40:20 +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
|
|
|
grub_dprintf ("multiboot_loader", "link_base_addr=0x%x, load_base_addr=0x%x, "
|
|
|
|
"load_size=0x%lx, relocatable=%d\n", mld.link_base_addr,
|
|
|
|
mld.load_base_addr, (long) code_size, mld.relocatable);
|
|
|
|
|
|
|
|
if (mld.relocatable)
|
|
|
|
grub_dprintf ("multiboot_loader", "align=0x%lx, preference=0x%x, avoid_efi_boot_services=%d\n",
|
|
|
|
(long) mld.align, mld.preference, keep_bs);
|
|
|
|
|
2010-03-10 10:40:20 +00:00
|
|
|
if ((grub_file_seek (file, offset)) == (grub_off_t) -1)
|
|
|
|
{
|
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_free (mld.buffer);
|
2010-03-10 10:40:20 +00:00
|
|
|
return grub_errno;
|
|
|
|
}
|
|
|
|
|
2010-04-01 20:17:26 +00:00
|
|
|
grub_file_read (file, source, load_size);
|
2010-03-10 10:40:20 +00:00
|
|
|
if (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
|
|
|
grub_free (mld.buffer);
|
2010-03-10 10:40:20 +00:00
|
|
|
return grub_errno;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (addr_tag->bss_end_addr)
|
2013-04-27 19:16:55 +00:00
|
|
|
grub_memset ((grub_uint8_t *) source + load_size, 0,
|
2013-12-17 14:14:50 +00:00
|
|
|
addr_tag->bss_end_addr - load_addr - load_size);
|
2010-03-10 10:40:20 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
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.file = file;
|
|
|
|
mld.filename = filename;
|
|
|
|
mld.avoid_efi_boot_services = keep_bs;
|
2017-08-14 10:51:26 +00:00
|
|
|
err = grub_multiboot2_load_elf (&mld);
|
2010-03-10 10:40:20 +00:00
|
|
|
if (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
|
|
|
grub_free (mld.buffer);
|
2010-03-10 10:40:20 +00:00
|
|
|
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
|
|
|
load_base_addr = mld.load_base_addr;
|
|
|
|
|
2015-07-17 17:43:42 +00:00
|
|
|
if (keep_bs && efi_entry_specified)
|
2017-08-14 10:51:26 +00:00
|
|
|
grub_multiboot2_payload_eip = efi_entry;
|
2015-07-17 17:43:42 +00:00
|
|
|
else if (entry_specified)
|
2017-08-14 10:51:26 +00:00
|
|
|
grub_multiboot2_payload_eip = entry;
|
2010-03-10 10:40:20 +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 (mld.relocatable)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Both branches are mathematically equivalent. However, it looks
|
|
|
|
* that real life (C?) is more complicated. I am trying to avoid
|
|
|
|
* wrap around here if mld.load_base_addr < mld.link_base_addr.
|
|
|
|
* If you look at C operator precedence then everything should work.
|
|
|
|
* However, I am not 100% sure that a given compiler will not
|
|
|
|
* optimize/break this stuff. So, maybe we should use signed
|
|
|
|
* 64-bit int here.
|
|
|
|
*/
|
|
|
|
if (mld.load_base_addr >= mld.link_base_addr)
|
2017-08-14 10:51:26 +00:00
|
|
|
grub_multiboot2_payload_eip += 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
|
|
|
else
|
2017-08-14 10:51:26 +00:00
|
|
|
grub_multiboot2_payload_eip -= 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
|
|
|
}
|
|
|
|
|
2010-03-10 10:40:20 +00:00
|
|
|
if (fbtag)
|
2017-08-14 10:51:26 +00:00
|
|
|
err = grub_multiboot2_set_console (GRUB_MULTIBOOT2_CONSOLE_FRAMEBUFFER,
|
|
|
|
accepted_consoles,
|
|
|
|
fbtag->width, fbtag->height,
|
|
|
|
fbtag->depth, console_required);
|
2010-03-10 10:40:20 +00:00
|
|
|
else
|
2017-08-14 10:51:26 +00:00
|
|
|
err = grub_multiboot2_set_console (GRUB_MULTIBOOT2_CONSOLE_EGA_TEXT,
|
|
|
|
accepted_consoles,
|
|
|
|
0, 0, 0, console_required);
|
2010-03-10 10:40:20 +00:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2010-09-21 06:37:50 +00:00
|
|
|
static grub_size_t
|
|
|
|
acpiv2_size (void)
|
|
|
|
{
|
2010-09-22 12:51:49 +00:00
|
|
|
#if GRUB_MACHINE_HAS_ACPI
|
2010-09-21 06:37:50 +00:00
|
|
|
struct grub_acpi_rsdp_v20 *p = grub_acpi_get_rsdpv2 ();
|
|
|
|
|
|
|
|
if (!p)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return ALIGN_UP (sizeof (struct multiboot_tag_old_acpi)
|
|
|
|
+ p->length, MULTIBOOT_TAG_ALIGN);
|
2010-09-22 12:51:49 +00:00
|
|
|
#else
|
|
|
|
return 0;
|
|
|
|
#endif
|
2010-09-21 06:37:50 +00:00
|
|
|
}
|
|
|
|
|
2013-10-28 14:37:00 +00:00
|
|
|
#ifdef GRUB_MACHINE_EFI
|
|
|
|
|
|
|
|
static grub_efi_uintn_t efi_mmap_size = 0;
|
|
|
|
|
|
|
|
/* Find the optimal number of pages for the memory map. Is it better to
|
|
|
|
move this code to efi/mm.c? */
|
|
|
|
static void
|
|
|
|
find_efi_mmap_size (void)
|
|
|
|
{
|
|
|
|
efi_mmap_size = (1 << 12);
|
|
|
|
while (1)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
grub_efi_memory_descriptor_t *mmap;
|
|
|
|
grub_efi_uintn_t desc_size;
|
|
|
|
grub_efi_uintn_t cur_mmap_size = efi_mmap_size;
|
|
|
|
|
|
|
|
mmap = grub_malloc (cur_mmap_size);
|
|
|
|
if (! mmap)
|
|
|
|
return;
|
|
|
|
|
|
|
|
ret = grub_efi_get_memory_map (&cur_mmap_size, mmap, 0, &desc_size, 0);
|
|
|
|
grub_free (mmap);
|
|
|
|
|
|
|
|
if (ret < 0)
|
|
|
|
return;
|
|
|
|
else if (ret > 0)
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (efi_mmap_size < cur_mmap_size)
|
|
|
|
efi_mmap_size = cur_mmap_size;
|
|
|
|
efi_mmap_size += (1 << 12);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Increase the size a bit for safety, because GRUB allocates more on
|
|
|
|
later, and EFI itself may allocate more. */
|
|
|
|
efi_mmap_size += (3 << 12);
|
|
|
|
|
|
|
|
efi_mmap_size = ALIGN_UP (efi_mmap_size, 4096);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2013-10-28 14:53:39 +00:00
|
|
|
static grub_size_t
|
|
|
|
net_size (void)
|
|
|
|
{
|
|
|
|
struct grub_net_network_level_interface *net;
|
|
|
|
grub_size_t ret = 0;
|
|
|
|
|
|
|
|
FOR_NET_NETWORK_LEVEL_INTERFACES(net)
|
|
|
|
if (net->dhcp_ack)
|
|
|
|
ret += ALIGN_UP (sizeof (struct multiboot_tag_network) + net->dhcp_acklen,
|
|
|
|
MULTIBOOT_TAG_ALIGN);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2010-04-01 20:17:26 +00:00
|
|
|
static grub_size_t
|
2017-08-14 10:51:26 +00:00
|
|
|
grub_multiboot2_get_mbi_size (void)
|
2010-01-16 15:25:43 +00:00
|
|
|
{
|
2013-10-28 14:37:00 +00:00
|
|
|
#ifdef GRUB_MACHINE_EFI
|
2015-07-17 22:09:31 +00:00
|
|
|
if (!keep_bs && !efi_mmap_size)
|
2013-10-28 14:37:00 +00:00
|
|
|
find_efi_mmap_size ();
|
|
|
|
#endif
|
2010-03-07 13:59:15 +00:00
|
|
|
return 2 * sizeof (grub_uint32_t) + sizeof (struct multiboot_tag)
|
2013-12-13 11:56:14 +00:00
|
|
|
+ sizeof (struct multiboot_tag)
|
2010-01-16 15:25:43 +00:00
|
|
|
+ (sizeof (struct multiboot_tag_string)
|
2010-03-07 13:59:15 +00:00
|
|
|
+ ALIGN_UP (cmdline_size, MULTIBOOT_TAG_ALIGN))
|
|
|
|
+ (sizeof (struct multiboot_tag_string)
|
|
|
|
+ ALIGN_UP (sizeof (PACKAGE_STRING), MULTIBOOT_TAG_ALIGN))
|
2010-01-16 15:25:43 +00:00
|
|
|
+ (modcnt * sizeof (struct multiboot_tag_module) + total_modcmd)
|
2010-09-20 15:01:28 +00:00
|
|
|
+ ALIGN_UP (sizeof (struct multiboot_tag_basic_meminfo),
|
|
|
|
MULTIBOOT_TAG_ALIGN)
|
2010-03-07 13:59:15 +00:00
|
|
|
+ ALIGN_UP (sizeof (struct multiboot_tag_bootdev), MULTIBOOT_TAG_ALIGN)
|
2010-09-15 22:54:21 +00:00
|
|
|
+ ALIGN_UP (sizeof (struct multiboot_tag_elf_sections), MULTIBOOT_TAG_ALIGN)
|
|
|
|
+ ALIGN_UP (elf_sec_entsize * elf_sec_num, MULTIBOOT_TAG_ALIGN)
|
2010-09-20 15:01:28 +00:00
|
|
|
+ ALIGN_UP ((sizeof (struct multiboot_tag_mmap)
|
2017-08-14 10:51:26 +00:00
|
|
|
+ grub_multiboot2_get_mmap_count ()
|
2010-09-15 22:54:21 +00:00
|
|
|
* sizeof (struct multiboot_mmap_entry)), MULTIBOOT_TAG_ALIGN)
|
|
|
|
+ ALIGN_UP (sizeof (struct multiboot_tag_framebuffer), MULTIBOOT_TAG_ALIGN)
|
2010-09-21 06:37:50 +00:00
|
|
|
+ ALIGN_UP (sizeof (struct multiboot_tag_old_acpi)
|
|
|
|
+ sizeof (struct grub_acpi_rsdp_v10), MULTIBOOT_TAG_ALIGN)
|
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
|
|
|
+ ALIGN_UP (sizeof (struct multiboot_tag_load_base_addr), MULTIBOOT_TAG_ALIGN)
|
2010-09-21 06:37:50 +00:00
|
|
|
+ acpiv2_size ()
|
2013-10-28 14:53:39 +00:00
|
|
|
+ net_size ()
|
2013-10-28 14:37:00 +00:00
|
|
|
#ifdef GRUB_MACHINE_EFI
|
2014-11-19 23:09:54 +00:00
|
|
|
+ ALIGN_UP (sizeof (struct multiboot_tag_efi32), MULTIBOOT_TAG_ALIGN)
|
|
|
|
+ ALIGN_UP (sizeof (struct multiboot_tag_efi32_ih), MULTIBOOT_TAG_ALIGN)
|
|
|
|
+ ALIGN_UP (sizeof (struct multiboot_tag_efi64), MULTIBOOT_TAG_ALIGN)
|
|
|
|
+ ALIGN_UP (sizeof (struct multiboot_tag_efi64_ih), MULTIBOOT_TAG_ALIGN)
|
2013-10-28 14:37:00 +00:00
|
|
|
+ ALIGN_UP (sizeof (struct multiboot_tag_efi_mmap)
|
|
|
|
+ efi_mmap_size, MULTIBOOT_TAG_ALIGN)
|
|
|
|
#endif
|
2010-09-15 09:42:18 +00:00
|
|
|
+ sizeof (struct multiboot_tag_vbe) + MULTIBOOT_TAG_ALIGN - 1
|
|
|
|
+ sizeof (struct multiboot_tag_apm) + MULTIBOOT_TAG_ALIGN - 1;
|
2010-01-16 15:25:43 +00:00
|
|
|
}
|
|
|
|
|
2013-01-15 12:02:35 +00:00
|
|
|
/* Helper for grub_fill_multiboot_mmap. */
|
|
|
|
static int
|
|
|
|
grub_fill_multiboot_mmap_iter (grub_uint64_t addr, grub_uint64_t size,
|
|
|
|
grub_memory_type_t type, void *data)
|
2010-03-07 12:01:43 +00:00
|
|
|
{
|
2013-01-15 12:02:35 +00:00
|
|
|
struct multiboot_mmap_entry **mmap_entry = data;
|
2010-03-07 12:01:43 +00:00
|
|
|
|
2013-01-15 12:02:35 +00:00
|
|
|
(*mmap_entry)->addr = addr;
|
|
|
|
(*mmap_entry)->len = size;
|
2013-10-14 14:33:44 +00:00
|
|
|
(*mmap_entry)->type = type;
|
2016-02-23 06:12:14 +00:00
|
|
|
(*mmap_entry)->zero = 0;
|
2013-01-15 12:02:35 +00:00
|
|
|
(*mmap_entry)++;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Fill previously allocated Multiboot mmap. */
|
|
|
|
static void
|
|
|
|
grub_fill_multiboot_mmap (struct multiboot_tag_mmap *tag)
|
|
|
|
{
|
|
|
|
struct multiboot_mmap_entry *mmap_entry = tag->entries;
|
2010-03-07 12:01:43 +00:00
|
|
|
|
2010-03-07 13:59:15 +00:00
|
|
|
tag->type = MULTIBOOT_TAG_TYPE_MMAP;
|
|
|
|
tag->size = sizeof (struct multiboot_tag_mmap)
|
2017-08-14 10:51:26 +00:00
|
|
|
+ sizeof (struct multiboot_mmap_entry) * grub_multiboot2_get_mmap_count ();
|
2010-03-07 13:59:15 +00:00
|
|
|
tag->entry_size = sizeof (struct multiboot_mmap_entry);
|
|
|
|
tag->entry_version = 0;
|
|
|
|
|
2013-01-15 12:02:35 +00:00
|
|
|
grub_mmap_iterate (grub_fill_multiboot_mmap_iter, &mmap_entry);
|
2010-03-07 12:01:43 +00:00
|
|
|
}
|
|
|
|
|
2010-09-15 22:54:21 +00:00
|
|
|
#if defined (GRUB_MACHINE_PCBIOS)
|
|
|
|
static void
|
|
|
|
fill_vbe_tag (struct multiboot_tag_vbe *tag)
|
|
|
|
{
|
|
|
|
grub_vbe_status_t status;
|
|
|
|
void *scratch = (void *) GRUB_MEMORY_MACHINE_SCRATCH_ADDR;
|
|
|
|
|
|
|
|
tag->type = MULTIBOOT_TAG_TYPE_VBE;
|
|
|
|
tag->size = 0;
|
|
|
|
|
|
|
|
status = grub_vbe_bios_get_controller_info (scratch);
|
|
|
|
if (status != GRUB_VBE_STATUS_OK)
|
|
|
|
return;
|
|
|
|
|
|
|
|
grub_memcpy (&tag->vbe_control_info, scratch,
|
|
|
|
sizeof (struct grub_vbe_info_block));
|
|
|
|
|
|
|
|
status = grub_vbe_bios_get_mode (scratch);
|
|
|
|
tag->vbe_mode = *(grub_uint32_t *) scratch;
|
|
|
|
if (status != GRUB_VBE_STATUS_OK)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* get_mode_info isn't available for mode 3. */
|
|
|
|
if (tag->vbe_mode == 3)
|
|
|
|
{
|
|
|
|
struct grub_vbe_mode_info_block *mode_info = (void *) &tag->vbe_mode_info;
|
|
|
|
grub_memset (mode_info, 0,
|
|
|
|
sizeof (struct grub_vbe_mode_info_block));
|
|
|
|
mode_info->memory_model = GRUB_VBE_MEMORY_MODEL_TEXT;
|
|
|
|
mode_info->x_resolution = 80;
|
|
|
|
mode_info->y_resolution = 25;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
status = grub_vbe_bios_get_mode_info (tag->vbe_mode, scratch);
|
|
|
|
if (status != GRUB_VBE_STATUS_OK)
|
|
|
|
return;
|
|
|
|
grub_memcpy (&tag->vbe_mode_info, scratch,
|
|
|
|
sizeof (struct grub_vbe_mode_info_block));
|
|
|
|
}
|
|
|
|
grub_vbe_bios_get_pm_interface (&tag->vbe_interface_seg,
|
|
|
|
&tag->vbe_interface_off,
|
|
|
|
&tag->vbe_interface_len);
|
|
|
|
|
|
|
|
tag->size = sizeof (*tag);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2010-01-16 15:25:43 +00:00
|
|
|
static grub_err_t
|
2011-12-13 15:22:44 +00:00
|
|
|
retrieve_video_parameters (grub_properly_aligned_t **ptrorig)
|
2010-01-16 15:25:43 +00:00
|
|
|
{
|
|
|
|
grub_err_t err;
|
|
|
|
struct grub_video_mode_info mode_info;
|
|
|
|
void *framebuffer;
|
|
|
|
grub_video_driver_id_t driv_id;
|
|
|
|
struct grub_video_palette_data palette[256];
|
|
|
|
struct multiboot_tag_framebuffer *tag
|
|
|
|
= (struct multiboot_tag_framebuffer *) *ptrorig;
|
|
|
|
|
2017-08-14 10:51:26 +00:00
|
|
|
err = grub_multiboot2_set_video_mode ();
|
2010-01-16 15:25:43 +00:00
|
|
|
if (err)
|
|
|
|
{
|
|
|
|
grub_print_error ();
|
|
|
|
grub_errno = GRUB_ERR_NONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
grub_video_get_palette (0, ARRAY_SIZE (palette), palette);
|
|
|
|
|
|
|
|
driv_id = grub_video_get_driver_id ();
|
|
|
|
#if HAS_VGA_TEXT
|
|
|
|
if (driv_id == GRUB_VIDEO_DRIVER_NONE)
|
|
|
|
{
|
2010-03-28 11:46:42 +00:00
|
|
|
struct grub_vbe_mode_info_block vbe_mode_info;
|
|
|
|
grub_uint32_t vbe_mode;
|
|
|
|
|
2010-03-30 09:18:29 +00:00
|
|
|
#if defined (GRUB_MACHINE_PCBIOS)
|
|
|
|
{
|
|
|
|
grub_vbe_status_t status;
|
|
|
|
void *scratch = (void *) GRUB_MEMORY_MACHINE_SCRATCH_ADDR;
|
|
|
|
status = grub_vbe_bios_get_mode (scratch);
|
|
|
|
vbe_mode = *(grub_uint32_t *) scratch;
|
|
|
|
if (status != GRUB_VBE_STATUS_OK)
|
|
|
|
return GRUB_ERR_NONE;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
vbe_mode = 3;
|
|
|
|
#endif
|
2010-03-28 11:46:42 +00:00
|
|
|
|
|
|
|
/* get_mode_info isn't available for mode 3. */
|
|
|
|
if (vbe_mode == 3)
|
|
|
|
{
|
|
|
|
grub_memset (&vbe_mode_info, 0,
|
|
|
|
sizeof (struct grub_vbe_mode_info_block));
|
|
|
|
vbe_mode_info.memory_model = GRUB_VBE_MEMORY_MODEL_TEXT;
|
|
|
|
vbe_mode_info.x_resolution = 80;
|
|
|
|
vbe_mode_info.y_resolution = 25;
|
|
|
|
}
|
2010-03-30 09:18:29 +00:00
|
|
|
#if defined (GRUB_MACHINE_PCBIOS)
|
2010-03-28 11:46:42 +00:00
|
|
|
else
|
|
|
|
{
|
2010-03-30 09:18:29 +00:00
|
|
|
grub_vbe_status_t status;
|
|
|
|
void *scratch = (void *) GRUB_MEMORY_MACHINE_SCRATCH_ADDR;
|
2010-03-28 11:46:42 +00:00
|
|
|
status = grub_vbe_bios_get_mode_info (vbe_mode, scratch);
|
|
|
|
if (status != GRUB_VBE_STATUS_OK)
|
|
|
|
return GRUB_ERR_NONE;
|
|
|
|
grub_memcpy (&vbe_mode_info, scratch,
|
|
|
|
sizeof (struct grub_vbe_mode_info_block));
|
|
|
|
}
|
2010-03-30 09:18:29 +00:00
|
|
|
#endif
|
2010-03-28 11:46:42 +00:00
|
|
|
|
|
|
|
if (vbe_mode_info.memory_model == GRUB_VBE_MEMORY_MODEL_TEXT)
|
2010-01-16 15:25:43 +00:00
|
|
|
{
|
|
|
|
tag = (struct multiboot_tag_framebuffer *) *ptrorig;
|
|
|
|
tag->common.type = MULTIBOOT_TAG_TYPE_FRAMEBUFFER;
|
|
|
|
tag->common.size = 0;
|
|
|
|
|
|
|
|
tag->common.framebuffer_addr = 0xb8000;
|
|
|
|
|
2010-03-28 11:46:42 +00:00
|
|
|
tag->common.framebuffer_pitch = 2 * vbe_mode_info.x_resolution;
|
|
|
|
tag->common.framebuffer_width = vbe_mode_info.x_resolution;
|
|
|
|
tag->common.framebuffer_height = vbe_mode_info.y_resolution;
|
2010-01-16 15:25:43 +00:00
|
|
|
|
|
|
|
tag->common.framebuffer_bpp = 16;
|
|
|
|
|
|
|
|
tag->common.framebuffer_type = MULTIBOOT_FRAMEBUFFER_TYPE_EGA_TEXT;
|
|
|
|
tag->common.size = sizeof (tag->common);
|
2010-03-07 13:59:15 +00:00
|
|
|
tag->common.reserved = 0;
|
2011-12-13 15:22:44 +00:00
|
|
|
*ptrorig += ALIGN_UP (tag->common.size, MULTIBOOT_TAG_ALIGN)
|
|
|
|
/ sizeof (grub_properly_aligned_t);
|
2010-01-16 15:25:43 +00:00
|
|
|
}
|
|
|
|
return GRUB_ERR_NONE;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
if (driv_id == GRUB_VIDEO_DRIVER_NONE)
|
|
|
|
return GRUB_ERR_NONE;
|
|
|
|
#endif
|
|
|
|
|
2010-09-15 22:54:21 +00:00
|
|
|
#if GRUB_MACHINE_HAS_VBE
|
|
|
|
{
|
|
|
|
struct multiboot_tag_vbe *tag_vbe = (struct multiboot_tag_vbe *) *ptrorig;
|
|
|
|
|
|
|
|
fill_vbe_tag (tag_vbe);
|
|
|
|
|
2011-12-13 15:22:44 +00:00
|
|
|
*ptrorig += ALIGN_UP (tag_vbe->size, MULTIBOOT_TAG_ALIGN)
|
|
|
|
/ sizeof (grub_properly_aligned_t);
|
2010-09-15 22:54:21 +00:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2010-01-16 15:25:43 +00:00
|
|
|
err = grub_video_get_info_and_fini (&mode_info, &framebuffer);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
tag = (struct multiboot_tag_framebuffer *) *ptrorig;
|
|
|
|
tag->common.type = MULTIBOOT_TAG_TYPE_FRAMEBUFFER;
|
|
|
|
tag->common.size = 0;
|
|
|
|
|
|
|
|
tag->common.framebuffer_addr = (grub_addr_t) framebuffer;
|
|
|
|
tag->common.framebuffer_pitch = mode_info.pitch;
|
|
|
|
|
|
|
|
tag->common.framebuffer_width = mode_info.width;
|
|
|
|
tag->common.framebuffer_height = mode_info.height;
|
|
|
|
|
|
|
|
tag->common.framebuffer_bpp = mode_info.bpp;
|
2010-03-07 13:59:15 +00:00
|
|
|
|
|
|
|
tag->common.reserved = 0;
|
2010-01-16 15:25:43 +00:00
|
|
|
|
|
|
|
if (mode_info.mode_type & GRUB_VIDEO_MODE_TYPE_INDEX_COLOR)
|
|
|
|
{
|
|
|
|
unsigned i;
|
|
|
|
tag->common.framebuffer_type = MULTIBOOT_FRAMEBUFFER_TYPE_INDEXED;
|
|
|
|
tag->framebuffer_palette_num_colors = mode_info.number_of_colors;
|
|
|
|
if (tag->framebuffer_palette_num_colors > ARRAY_SIZE (palette))
|
|
|
|
tag->framebuffer_palette_num_colors = ARRAY_SIZE (palette);
|
|
|
|
tag->common.size = sizeof (struct multiboot_tag_framebuffer_common)
|
|
|
|
+ sizeof (multiboot_uint16_t) + tag->framebuffer_palette_num_colors
|
|
|
|
* sizeof (struct multiboot_color);
|
|
|
|
for (i = 0; i < tag->framebuffer_palette_num_colors; i++)
|
|
|
|
{
|
|
|
|
tag->framebuffer_palette[i].red = palette[i].r;
|
|
|
|
tag->framebuffer_palette[i].green = palette[i].g;
|
|
|
|
tag->framebuffer_palette[i].blue = palette[i].b;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
tag->common.framebuffer_type = MULTIBOOT_FRAMEBUFFER_TYPE_RGB;
|
2010-06-23 08:22:03 +00:00
|
|
|
tag->framebuffer_red_field_position = mode_info.red_field_pos;
|
|
|
|
tag->framebuffer_red_mask_size = mode_info.red_mask_size;
|
2010-01-16 15:25:43 +00:00
|
|
|
tag->framebuffer_green_field_position = mode_info.green_field_pos;
|
|
|
|
tag->framebuffer_green_mask_size = mode_info.green_mask_size;
|
|
|
|
tag->framebuffer_blue_field_position = mode_info.blue_field_pos;
|
|
|
|
tag->framebuffer_blue_mask_size = mode_info.blue_mask_size;
|
|
|
|
|
|
|
|
tag->common.size = sizeof (struct multiboot_tag_framebuffer_common) + 6;
|
|
|
|
}
|
2011-12-13 15:22:44 +00:00
|
|
|
*ptrorig += ALIGN_UP (tag->common.size, MULTIBOOT_TAG_ALIGN)
|
|
|
|
/ sizeof (grub_properly_aligned_t);
|
2010-01-16 15:25:43 +00:00
|
|
|
|
|
|
|
return GRUB_ERR_NONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
grub_err_t
|
2017-08-14 10:51:26 +00:00
|
|
|
grub_multiboot2_make_mbi (grub_uint32_t *target)
|
2010-01-16 15:25:43 +00:00
|
|
|
{
|
2011-12-13 15:22:44 +00:00
|
|
|
grub_properly_aligned_t *ptrorig;
|
|
|
|
grub_properly_aligned_t *mbistart;
|
2010-01-16 15:25:43 +00:00
|
|
|
grub_err_t err;
|
2010-04-01 20:17:26 +00:00
|
|
|
grub_size_t bufsize;
|
2010-04-21 17:13:45 +00:00
|
|
|
grub_relocator_chunk_t ch;
|
2010-04-01 20:17:26 +00:00
|
|
|
|
2017-08-14 10:51:26 +00:00
|
|
|
bufsize = grub_multiboot2_get_mbi_size ();
|
2010-04-01 20:17:26 +00:00
|
|
|
|
2011-12-13 15:22:44 +00:00
|
|
|
COMPILE_TIME_ASSERT (MULTIBOOT_TAG_ALIGN % sizeof (grub_properly_aligned_t) == 0);
|
|
|
|
|
2017-08-14 10:51:26 +00:00
|
|
|
err = grub_relocator_alloc_chunk_align (grub_multiboot2_relocator, &ch,
|
2010-04-01 20:17:26 +00:00
|
|
|
0, 0xffffffff - bufsize,
|
2010-09-20 15:01:28 +00:00
|
|
|
bufsize, MULTIBOOT_TAG_ALIGN,
|
2013-12-13 11:56:14 +00:00
|
|
|
GRUB_RELOCATOR_PREFERENCE_NONE, 1);
|
2010-04-01 20:17:26 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
2010-01-16 15:25:43 +00:00
|
|
|
|
2010-04-21 17:13:45 +00:00
|
|
|
ptrorig = get_virtual_current_address (ch);
|
2010-08-25 00:15:21 +00:00
|
|
|
#if defined (__i386__) || defined (__x86_64__)
|
2010-04-21 17:13:45 +00:00
|
|
|
*target = get_physical_target_address (ch);
|
2010-08-25 00:15:21 +00:00
|
|
|
#elif defined (__mips)
|
|
|
|
*target = get_physical_target_address (ch) | 0x80000000;
|
|
|
|
#else
|
|
|
|
#error Please complete this
|
|
|
|
#endif
|
2010-01-16 15:25:43 +00:00
|
|
|
|
2010-04-01 20:17:26 +00:00
|
|
|
mbistart = ptrorig;
|
2011-12-13 15:22:44 +00:00
|
|
|
COMPILE_TIME_ASSERT ((2 * sizeof (grub_uint32_t))
|
|
|
|
% sizeof (grub_properly_aligned_t) == 0);
|
|
|
|
COMPILE_TIME_ASSERT (MULTIBOOT_TAG_ALIGN
|
|
|
|
% sizeof (grub_properly_aligned_t) == 0);
|
|
|
|
ptrorig += (2 * sizeof (grub_uint32_t)) / sizeof (grub_properly_aligned_t);
|
2010-01-16 16:18:02 +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
|
|
|
{
|
|
|
|
struct multiboot_tag_load_base_addr *tag = (struct multiboot_tag_load_base_addr *) ptrorig;
|
|
|
|
tag->type = MULTIBOOT_TAG_TYPE_LOAD_BASE_ADDR;
|
|
|
|
tag->size = sizeof (struct multiboot_tag_load_base_addr);
|
|
|
|
tag->load_base_addr = load_base_addr;
|
|
|
|
ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
|
|
|
|
/ sizeof (grub_properly_aligned_t);
|
|
|
|
}
|
|
|
|
|
2010-01-16 15:25:43 +00:00
|
|
|
{
|
|
|
|
struct multiboot_tag_string *tag = (struct multiboot_tag_string *) ptrorig;
|
|
|
|
tag->type = MULTIBOOT_TAG_TYPE_CMDLINE;
|
2010-03-07 13:59:15 +00:00
|
|
|
tag->size = sizeof (struct multiboot_tag_string) + cmdline_size;
|
2010-01-16 15:25:43 +00:00
|
|
|
grub_memcpy (tag->string, cmdline, cmdline_size);
|
2011-12-13 15:22:44 +00:00
|
|
|
ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
|
|
|
|
/ sizeof (grub_properly_aligned_t);
|
2010-01-16 15:25:43 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
struct multiboot_tag_string *tag = (struct multiboot_tag_string *) ptrorig;
|
|
|
|
tag->type = MULTIBOOT_TAG_TYPE_BOOT_LOADER_NAME;
|
2010-03-07 13:59:15 +00:00
|
|
|
tag->size = sizeof (struct multiboot_tag_string) + sizeof (PACKAGE_STRING);
|
2010-01-16 15:25:43 +00:00
|
|
|
grub_memcpy (tag->string, PACKAGE_STRING, sizeof (PACKAGE_STRING));
|
2011-12-13 15:22:44 +00:00
|
|
|
ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
|
|
|
|
/ sizeof (grub_properly_aligned_t);
|
2010-01-16 15:25:43 +00:00
|
|
|
}
|
|
|
|
|
2010-09-15 09:42:18 +00:00
|
|
|
#ifdef GRUB_MACHINE_PCBIOS
|
|
|
|
{
|
|
|
|
struct grub_apm_info info;
|
|
|
|
if (grub_apm_get_info (&info))
|
|
|
|
{
|
|
|
|
struct multiboot_tag_apm *tag = (struct multiboot_tag_apm *) ptrorig;
|
|
|
|
|
|
|
|
tag->type = MULTIBOOT_TAG_TYPE_APM;
|
|
|
|
tag->size = sizeof (struct multiboot_tag_apm);
|
|
|
|
|
|
|
|
tag->cseg = info.cseg;
|
|
|
|
tag->offset = info.offset;
|
|
|
|
tag->cseg_16 = info.cseg_16;
|
|
|
|
tag->dseg = info.dseg;
|
|
|
|
tag->flags = info.flags;
|
|
|
|
tag->cseg_len = info.cseg_len;
|
|
|
|
tag->dseg_len = info.dseg_len;
|
|
|
|
tag->cseg_16_len = info.cseg_16_len;
|
|
|
|
tag->version = info.version;
|
|
|
|
|
2011-12-13 15:22:44 +00:00
|
|
|
ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
|
|
|
|
/ sizeof (grub_properly_aligned_t);
|
2010-09-15 09:42:18 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2010-01-16 15:25:43 +00:00
|
|
|
{
|
|
|
|
unsigned i;
|
|
|
|
struct module *cur;
|
|
|
|
|
|
|
|
for (i = 0, cur = modules; i < modcnt; i++, cur = cur->next)
|
|
|
|
{
|
|
|
|
struct multiboot_tag_module *tag
|
|
|
|
= (struct multiboot_tag_module *) ptrorig;
|
|
|
|
tag->type = MULTIBOOT_TAG_TYPE_MODULE;
|
2010-03-07 13:59:15 +00:00
|
|
|
tag->size = sizeof (struct multiboot_tag_module) + cur->cmdline_size;
|
2010-04-01 20:17:26 +00:00
|
|
|
tag->mod_start = cur->start;
|
2010-01-16 15:25:43 +00:00
|
|
|
tag->mod_end = tag->mod_start + cur->size;
|
|
|
|
grub_memcpy (tag->cmdline, cur->cmdline, cur->cmdline_size);
|
2011-12-13 15:22:44 +00:00
|
|
|
ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
|
|
|
|
/ sizeof (grub_properly_aligned_t);
|
2010-01-16 15:25:43 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-07-17 22:09:31 +00:00
|
|
|
if (!keep_bs)
|
|
|
|
{
|
|
|
|
struct multiboot_tag_mmap *tag = (struct multiboot_tag_mmap *) ptrorig;
|
|
|
|
grub_fill_multiboot_mmap (tag);
|
|
|
|
ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
|
|
|
|
/ sizeof (grub_properly_aligned_t);
|
|
|
|
}
|
2010-01-16 15:25:43 +00:00
|
|
|
|
2010-05-02 17:39:46 +00:00
|
|
|
{
|
|
|
|
struct multiboot_tag_elf_sections *tag
|
|
|
|
= (struct multiboot_tag_elf_sections *) ptrorig;
|
|
|
|
tag->type = MULTIBOOT_TAG_TYPE_ELF_SECTIONS;
|
|
|
|
tag->size = sizeof (struct multiboot_tag_elf_sections)
|
|
|
|
+ elf_sec_entsize * elf_sec_num;
|
|
|
|
grub_memcpy (tag->sections, elf_sections, elf_sec_entsize * elf_sec_num);
|
|
|
|
tag->num = elf_sec_num;
|
|
|
|
tag->entsize = elf_sec_entsize;
|
|
|
|
tag->shndx = elf_sec_shstrndx;
|
2011-12-13 15:22:44 +00:00
|
|
|
ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
|
|
|
|
/ sizeof (grub_properly_aligned_t);
|
2010-05-02 17:39:46 +00:00
|
|
|
}
|
|
|
|
|
2015-07-17 22:09:31 +00:00
|
|
|
if (!keep_bs)
|
|
|
|
{
|
|
|
|
struct multiboot_tag_basic_meminfo *tag
|
|
|
|
= (struct multiboot_tag_basic_meminfo *) ptrorig;
|
|
|
|
tag->type = MULTIBOOT_TAG_TYPE_BASIC_MEMINFO;
|
|
|
|
tag->size = sizeof (struct multiboot_tag_basic_meminfo);
|
|
|
|
|
|
|
|
/* Convert from bytes to kilobytes. */
|
|
|
|
tag->mem_lower = grub_mmap_get_lower () / 1024;
|
|
|
|
tag->mem_upper = grub_mmap_get_upper () / 1024;
|
|
|
|
ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
|
|
|
|
/ sizeof (grub_properly_aligned_t);
|
|
|
|
}
|
2010-01-16 15:25:43 +00:00
|
|
|
|
2013-10-28 14:53:39 +00:00
|
|
|
{
|
|
|
|
struct grub_net_network_level_interface *net;
|
|
|
|
|
|
|
|
FOR_NET_NETWORK_LEVEL_INTERFACES(net)
|
|
|
|
if (net->dhcp_ack)
|
|
|
|
{
|
|
|
|
struct multiboot_tag_network *tag
|
|
|
|
= (struct multiboot_tag_network *) ptrorig;
|
|
|
|
tag->type = MULTIBOOT_TAG_TYPE_NETWORK;
|
|
|
|
tag->size = sizeof (struct multiboot_tag_network) + net->dhcp_acklen;
|
|
|
|
grub_memcpy (tag->dhcpack, net->dhcp_ack, net->dhcp_acklen);
|
|
|
|
ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
|
|
|
|
/ sizeof (grub_properly_aligned_t);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-01-16 15:25:43 +00:00
|
|
|
if (bootdev_set)
|
|
|
|
{
|
|
|
|
struct multiboot_tag_bootdev *tag
|
|
|
|
= (struct multiboot_tag_bootdev *) ptrorig;
|
|
|
|
tag->type = MULTIBOOT_TAG_TYPE_BOOTDEV;
|
|
|
|
tag->size = sizeof (struct multiboot_tag_bootdev);
|
|
|
|
|
|
|
|
tag->biosdev = biosdev;
|
|
|
|
tag->slice = slice;
|
|
|
|
tag->part = part;
|
2011-12-13 15:22:44 +00:00
|
|
|
ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
|
|
|
|
/ sizeof (grub_properly_aligned_t);
|
2010-01-16 15:25:43 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
err = retrieve_video_parameters (&ptrorig);
|
|
|
|
if (err)
|
|
|
|
{
|
|
|
|
grub_print_error ();
|
|
|
|
grub_errno = GRUB_ERR_NONE;
|
|
|
|
}
|
|
|
|
}
|
2010-09-21 00:19:29 +00:00
|
|
|
|
2010-09-28 16:38:34 +00:00
|
|
|
#if defined (GRUB_MACHINE_EFI) && defined (__x86_64__)
|
2010-09-21 00:19:29 +00:00
|
|
|
{
|
|
|
|
struct multiboot_tag_efi64 *tag = (struct multiboot_tag_efi64 *) ptrorig;
|
|
|
|
tag->type = MULTIBOOT_TAG_TYPE_EFI64;
|
|
|
|
tag->size = sizeof (*tag);
|
|
|
|
tag->pointer = (grub_addr_t) grub_efi_system_table;
|
2011-12-13 15:22:44 +00:00
|
|
|
ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
|
|
|
|
/ sizeof (grub_properly_aligned_t);
|
2010-09-21 00:19:29 +00:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2010-09-28 16:38:34 +00:00
|
|
|
#if defined (GRUB_MACHINE_EFI) && defined (__i386__)
|
2010-09-21 00:19:29 +00:00
|
|
|
{
|
2010-09-29 21:58:43 +00:00
|
|
|
struct multiboot_tag_efi32 *tag = (struct multiboot_tag_efi32 *) ptrorig;
|
2010-09-21 00:19:29 +00:00
|
|
|
tag->type = MULTIBOOT_TAG_TYPE_EFI32;
|
|
|
|
tag->size = sizeof (*tag);
|
|
|
|
tag->pointer = (grub_addr_t) grub_efi_system_table;
|
2011-12-13 15:22:44 +00:00
|
|
|
ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
|
|
|
|
/ sizeof (grub_properly_aligned_t);
|
2010-09-21 00:19:29 +00:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2010-09-22 12:51:49 +00:00
|
|
|
#if GRUB_MACHINE_HAS_ACPI
|
2010-09-21 06:37:50 +00:00
|
|
|
{
|
|
|
|
struct multiboot_tag_old_acpi *tag = (struct multiboot_tag_old_acpi *)
|
|
|
|
ptrorig;
|
|
|
|
struct grub_acpi_rsdp_v10 *a = grub_acpi_get_rsdpv1 ();
|
|
|
|
if (a)
|
|
|
|
{
|
|
|
|
tag->type = MULTIBOOT_TAG_TYPE_ACPI_OLD;
|
|
|
|
tag->size = sizeof (*tag) + sizeof (*a);
|
|
|
|
grub_memcpy (tag->rsdp, a, sizeof (*a));
|
2011-12-13 15:22:44 +00:00
|
|
|
ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
|
|
|
|
/ sizeof (grub_properly_aligned_t);
|
2010-09-21 06:37:50 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
struct multiboot_tag_new_acpi *tag = (struct multiboot_tag_new_acpi *)
|
|
|
|
ptrorig;
|
|
|
|
struct grub_acpi_rsdp_v20 *a = grub_acpi_get_rsdpv2 ();
|
|
|
|
if (a)
|
|
|
|
{
|
|
|
|
tag->type = MULTIBOOT_TAG_TYPE_ACPI_NEW;
|
|
|
|
tag->size = sizeof (*tag) + a->length;
|
|
|
|
grub_memcpy (tag->rsdp, a, a->length);
|
2011-12-13 15:22:44 +00:00
|
|
|
ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
|
|
|
|
/ sizeof (grub_properly_aligned_t);
|
2010-09-21 06:37:50 +00:00
|
|
|
}
|
|
|
|
}
|
2010-09-22 12:51:49 +00:00
|
|
|
#endif
|
2010-09-21 06:37:50 +00:00
|
|
|
|
2013-10-28 14:37:00 +00:00
|
|
|
#ifdef GRUB_MACHINE_EFI
|
|
|
|
{
|
|
|
|
struct multiboot_tag_efi_mmap *tag = (struct multiboot_tag_efi_mmap *) ptrorig;
|
|
|
|
grub_efi_uintn_t efi_desc_size;
|
|
|
|
grub_efi_uint32_t efi_desc_version;
|
|
|
|
|
2013-12-13 11:56:14 +00:00
|
|
|
if (!keep_bs)
|
|
|
|
{
|
2015-07-17 22:09:31 +00:00
|
|
|
tag->type = MULTIBOOT_TAG_TYPE_EFI_MMAP;
|
|
|
|
tag->size = sizeof (*tag) + efi_mmap_size;
|
2013-10-28 14:37:00 +00:00
|
|
|
|
2015-07-17 22:09:31 +00:00
|
|
|
err = grub_efi_finish_boot_services (&efi_mmap_size, tag->efi_mmap, NULL,
|
|
|
|
&efi_desc_size, &efi_desc_version);
|
|
|
|
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
tag->descr_size = efi_desc_size;
|
|
|
|
tag->descr_vers = efi_desc_version;
|
|
|
|
tag->size = sizeof (*tag) + efi_mmap_size;
|
|
|
|
|
|
|
|
ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
|
|
|
|
/ sizeof (grub_properly_aligned_t);
|
|
|
|
}
|
2013-10-28 14:37:00 +00:00
|
|
|
}
|
2013-12-13 11:56:14 +00:00
|
|
|
|
|
|
|
if (keep_bs)
|
|
|
|
{
|
2014-11-19 23:09:54 +00:00
|
|
|
{
|
|
|
|
struct multiboot_tag *tag = (struct multiboot_tag *) ptrorig;
|
|
|
|
tag->type = MULTIBOOT_TAG_TYPE_EFI_BS;
|
|
|
|
tag->size = sizeof (struct multiboot_tag);
|
|
|
|
ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
|
|
|
|
/ sizeof (grub_properly_aligned_t);
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef __i386__
|
|
|
|
{
|
|
|
|
struct multiboot_tag_efi32_ih *tag = (struct multiboot_tag_efi32_ih *) ptrorig;
|
|
|
|
tag->type = MULTIBOOT_TAG_TYPE_EFI32_IH;
|
|
|
|
tag->size = sizeof (struct multiboot_tag_efi32_ih);
|
|
|
|
tag->pointer = (grub_addr_t) grub_efi_image_handle;
|
|
|
|
ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
|
|
|
|
/ sizeof (grub_properly_aligned_t);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef __x86_64__
|
|
|
|
{
|
|
|
|
struct multiboot_tag_efi64_ih *tag = (struct multiboot_tag_efi64_ih *) ptrorig;
|
|
|
|
tag->type = MULTIBOOT_TAG_TYPE_EFI64_IH;
|
|
|
|
tag->size = sizeof (struct multiboot_tag_efi64_ih);
|
|
|
|
tag->pointer = (grub_addr_t) grub_efi_image_handle;
|
|
|
|
ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
|
|
|
|
/ sizeof (grub_properly_aligned_t);
|
|
|
|
}
|
|
|
|
#endif
|
2013-12-13 11:56:14 +00:00
|
|
|
}
|
2013-10-28 14:37:00 +00:00
|
|
|
#endif
|
|
|
|
|
2010-01-16 15:25:43 +00:00
|
|
|
{
|
|
|
|
struct multiboot_tag *tag = (struct multiboot_tag *) ptrorig;
|
|
|
|
tag->type = MULTIBOOT_TAG_TYPE_END;
|
|
|
|
tag->size = sizeof (struct multiboot_tag);
|
2011-12-13 15:22:44 +00:00
|
|
|
ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
|
|
|
|
/ sizeof (grub_properly_aligned_t);
|
2010-01-16 15:25:43 +00:00
|
|
|
}
|
|
|
|
|
2011-12-13 15:22:44 +00:00
|
|
|
((grub_uint32_t *) mbistart)[0] = (char *) ptrorig - (char *) mbistart;
|
2010-03-07 13:59:15 +00:00
|
|
|
((grub_uint32_t *) mbistart)[1] = 0;
|
2010-01-16 16:18:02 +00:00
|
|
|
|
2010-01-16 15:25:43 +00:00
|
|
|
return GRUB_ERR_NONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2017-08-14 10:51:26 +00:00
|
|
|
grub_multiboot2_free_mbi (void)
|
2010-01-16 15:25:43 +00:00
|
|
|
{
|
|
|
|
struct module *cur, *next;
|
|
|
|
|
|
|
|
cmdline_size = 0;
|
|
|
|
total_modcmd = 0;
|
|
|
|
modcnt = 0;
|
|
|
|
grub_free (cmdline);
|
|
|
|
cmdline = NULL;
|
|
|
|
bootdev_set = 0;
|
|
|
|
|
|
|
|
for (cur = modules; cur; cur = next)
|
|
|
|
{
|
|
|
|
next = cur->next;
|
|
|
|
grub_free (cur->cmdline);
|
|
|
|
grub_free (cur);
|
|
|
|
}
|
|
|
|
modules = NULL;
|
|
|
|
modules_last = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
grub_err_t
|
2017-08-14 10:51:26 +00:00
|
|
|
grub_multiboot2_init_mbi (int argc, char *argv[])
|
2010-01-16 15:25:43 +00:00
|
|
|
{
|
|
|
|
grub_ssize_t len = 0;
|
|
|
|
|
2017-08-14 10:51:26 +00:00
|
|
|
grub_multiboot2_free_mbi ();
|
2010-01-16 15:25:43 +00:00
|
|
|
|
2013-11-09 16:32:37 +00:00
|
|
|
len = grub_loader_cmdline_size (argc, argv);
|
2010-01-16 15:25:43 +00:00
|
|
|
|
2013-11-09 16:32:37 +00:00
|
|
|
cmdline = grub_malloc (len);
|
2010-01-16 15:25:43 +00:00
|
|
|
if (! cmdline)
|
|
|
|
return grub_errno;
|
|
|
|
cmdline_size = len;
|
|
|
|
|
2013-11-09 16:32:37 +00:00
|
|
|
grub_create_loader_cmdline (argc, argv, cmdline,
|
|
|
|
cmdline_size);
|
2010-01-16 15:25:43 +00:00
|
|
|
|
|
|
|
return GRUB_ERR_NONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
grub_err_t
|
2017-08-14 10:51:26 +00:00
|
|
|
grub_multiboot2_add_module (grub_addr_t start, grub_size_t size,
|
2010-01-16 15:25:43 +00:00
|
|
|
int argc, char *argv[])
|
|
|
|
{
|
|
|
|
struct module *newmod;
|
2013-11-09 16:32:37 +00:00
|
|
|
grub_size_t len = 0;
|
2010-01-16 15:25:43 +00:00
|
|
|
|
|
|
|
newmod = grub_malloc (sizeof (*newmod));
|
|
|
|
if (!newmod)
|
|
|
|
return grub_errno;
|
|
|
|
newmod->start = start;
|
|
|
|
newmod->size = size;
|
|
|
|
|
2013-11-09 16:32:37 +00:00
|
|
|
len = grub_loader_cmdline_size (argc, argv);
|
2010-01-16 15:25:43 +00:00
|
|
|
|
2013-11-09 16:32:37 +00:00
|
|
|
newmod->cmdline = grub_malloc (len);
|
2010-01-16 15:25:43 +00:00
|
|
|
if (! newmod->cmdline)
|
|
|
|
{
|
|
|
|
grub_free (newmod);
|
|
|
|
return grub_errno;
|
|
|
|
}
|
|
|
|
newmod->cmdline_size = len;
|
2010-03-07 13:59:15 +00:00
|
|
|
total_modcmd += ALIGN_UP (len, MULTIBOOT_TAG_ALIGN);
|
2010-01-16 15:25:43 +00:00
|
|
|
|
2013-11-09 16:32:37 +00:00
|
|
|
grub_create_loader_cmdline (argc, argv, newmod->cmdline,
|
|
|
|
newmod->cmdline_size);
|
2010-01-16 15:25:43 +00:00
|
|
|
|
|
|
|
if (modules_last)
|
|
|
|
modules_last->next = newmod;
|
|
|
|
else
|
2013-11-08 03:59:46 +00:00
|
|
|
modules = newmod;
|
2010-01-16 15:25:43 +00:00
|
|
|
modules_last = newmod;
|
|
|
|
|
|
|
|
modcnt++;
|
|
|
|
|
|
|
|
return GRUB_ERR_NONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2017-08-14 10:51:26 +00:00
|
|
|
grub_multiboot2_set_bootdev (void)
|
2010-01-16 15:25:43 +00:00
|
|
|
{
|
|
|
|
grub_device_t dev;
|
|
|
|
|
|
|
|
slice = ~0;
|
|
|
|
part = ~0;
|
|
|
|
|
|
|
|
#ifdef GRUB_MACHINE_PCBIOS
|
|
|
|
biosdev = grub_get_root_biosnumber ();
|
|
|
|
#else
|
|
|
|
biosdev = 0xffffffff;
|
|
|
|
#endif
|
|
|
|
|
2010-01-16 15:36:42 +00:00
|
|
|
if (biosdev == 0xffffffff)
|
|
|
|
return;
|
|
|
|
|
2010-01-16 15:25:43 +00:00
|
|
|
dev = grub_device_open (0);
|
|
|
|
if (dev && dev->disk && dev->disk->partition)
|
|
|
|
{
|
2010-03-27 21:40:49 +00:00
|
|
|
if (dev->disk->partition->parent)
|
|
|
|
{
|
|
|
|
part = dev->disk->partition->number;
|
|
|
|
slice = dev->disk->partition->parent->number;
|
2010-01-16 15:25:43 +00:00
|
|
|
}
|
2010-03-27 21:40:49 +00:00
|
|
|
else
|
|
|
|
slice = dev->disk->partition->number;
|
2010-01-16 15:25:43 +00:00
|
|
|
}
|
|
|
|
if (dev)
|
|
|
|
grub_device_close (dev);
|
|
|
|
|
|
|
|
bootdev_set = 1;
|
|
|
|
}
|