1998-08-21 03:17:42 +00:00
|
|
|
/*-
|
|
|
|
* Copyright (c) 1998 Michael Smith <msmith@freebsd.org>
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
* SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
2003-08-25 23:28:32 +00:00
|
|
|
#include <sys/cdefs.h>
|
|
|
|
__FBSDID("$FreeBSD$");
|
|
|
|
|
1998-08-21 03:17:42 +00:00
|
|
|
#include <stand.h>
|
1998-10-02 20:53:17 +00:00
|
|
|
#include <sys/param.h>
|
|
|
|
#include <sys/reboot.h>
|
1998-10-09 23:24:55 +00:00
|
|
|
#include <sys/linker.h>
|
1998-10-02 20:53:17 +00:00
|
|
|
#include <machine/bootinfo.h>
|
2008-10-07 14:05:42 +00:00
|
|
|
#include <machine/cpufunc.h>
|
loader: implement multiboot support for Xen Dom0
Implement a subset of the multiboot specification in order to boot Xen
and a FreeBSD Dom0 from the FreeBSD bootloader. This multiboot
implementation is tailored to boot Xen and FreeBSD Dom0, and it will
most surely fail to boot any other multiboot compilant kernel.
In order to detect and boot the Xen microkernel, two new file formats
are added to the bootloader, multiboot and multiboot_obj. Multiboot
support must be tested before regular ELF support, since Xen is a
multiboot kernel that also uses ELF. After a multiboot kernel is
detected, all the other loaded kernels/modules are parsed by the
multiboot_obj format.
The layout of the loaded objects in memory is the following; first the
Xen kernel is loaded as a 32bit ELF into memory (Xen will switch to
long mode by itself), after that the FreeBSD kernel is loaded as a RAW
file (Xen will parse and load it using it's internal ELF loader), and
finally the metadata and the modules are loaded using the native
FreeBSD way. After everything is loaded we jump into Xen's entry point
using a small trampoline. The order of the multiboot modules passed to
Xen is the following, the first module is the RAW FreeBSD kernel, and
the second module is the metadata and the FreeBSD modules.
Since Xen will relocate the memory position of the second
multiboot module (the one that contains the metadata and native
FreeBSD modules), we need to stash the original modulep address inside
of the metadata itself in order to recalculate its position once
booted. This also means the metadata must come before the loaded
modules, so after loading the FreeBSD kernel a portion of memory is
reserved in order to place the metadata before booting.
In order to tell the loader to boot Xen and then the FreeBSD kernel the
following has to be added to the /boot/loader.conf file:
xen_cmdline="dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga"
xen_kernel="/boot/xen"
The first argument contains the command line that will be passed to the Xen
kernel, while the second argument is the path to the Xen kernel itself. This
can also be done manually from the loader command line, by for example
typing the following set of commands:
OK unload
OK load /boot/xen dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga
OK load kernel
OK load zfs
OK load if_tap
OK load ...
OK boot
Sponsored by: Citrix Systems R&D
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D517
For the Forth bits:
Submitted by: Julien Grall <julien.grall AT citrix.com>
2015-01-15 16:27:20 +00:00
|
|
|
#include <machine/metadata.h>
|
2008-10-07 14:05:42 +00:00
|
|
|
#include <machine/psl.h>
|
|
|
|
#include <machine/specialreg.h>
|
1998-08-21 03:17:42 +00:00
|
|
|
#include "bootstrap.h"
|
1998-10-02 20:53:17 +00:00
|
|
|
#include "libi386.h"
|
|
|
|
#include "btxv86.h"
|
1998-08-21 03:17:42 +00:00
|
|
|
|
Implement boot-time encryption key passing (keybuf)
This patch adds a general mechanism for providing encryption keys to the
kernel from the boot loader. This is intended to enable GELI support at
boot time, providing a better mechanism for passing keys to the kernel
than environment variables. It is designed to be extensible to other
applications, and can easily handle multiple encrypted volumes with
different keys.
This mechanism is currently used by the pending GELI EFI work.
Additionally, this mechanism can potentially be used to interface with
GRUB, opening up options for coreboot+GRUB configurations with completely
encrypted disks.
Another benefit over the existing system is that it does not require
re-deriving the user key from the password at each boot stage.
Most of this patch was written by Eric McCorkle. It was extended by
Allan Jude with a number of minor enhancements and extending the keybuf
feature into boot2.
GELI user keys are now derived once, in boot2, then passed to the loader,
which reuses the key, then passes it to the kernel, where the GELI module
destroys the keybuf after decrypting the volumes.
Submitted by: Eric McCorkle <eric@metricspace.net> (Original Version)
Reviewed by: oshogbo (earlier version), cem (earlier version)
MFC after: 3 weeks
Relnotes: yes
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D9575
2017-04-01 05:05:22 +00:00
|
|
|
#ifdef LOADER_GELI_SUPPORT
|
|
|
|
#include "geliboot.h"
|
|
|
|
#endif
|
|
|
|
|
1998-08-21 03:17:42 +00:00
|
|
|
/*
|
|
|
|
* Copy module-related data into the load area, where it can be
|
|
|
|
* used as a directory for loaded modules.
|
|
|
|
*
|
|
|
|
* Module data is presented in a self-describing format. Each datum
|
2001-02-18 10:25:42 +00:00
|
|
|
* is preceded by a 32-bit identifier and a 32-bit size field.
|
1998-08-21 03:17:42 +00:00
|
|
|
*
|
|
|
|
* Currently, the following data are saved:
|
|
|
|
*
|
|
|
|
* MOD_NAME (variable) module name (string)
|
|
|
|
* MOD_TYPE (variable) module type (string)
|
1999-03-08 11:05:52 +00:00
|
|
|
* MOD_ARGS (variable) module parameters (string)
|
1998-08-21 03:17:42 +00:00
|
|
|
* MOD_ADDR sizeof(vm_offset_t) module load address
|
|
|
|
* MOD_SIZE sizeof(size_t) module size
|
|
|
|
* MOD_METADATA (variable) type-specific metadata
|
|
|
|
*/
|
2003-05-01 03:56:30 +00:00
|
|
|
#define COPY32(v, a, c) { \
|
2018-03-13 16:33:00 +00:00
|
|
|
uint32_t x = (v); \
|
2003-05-01 03:56:30 +00:00
|
|
|
if (c) \
|
|
|
|
i386_copyin(&x, a, sizeof(x)); \
|
1998-10-09 07:11:19 +00:00
|
|
|
a += sizeof(x); \
|
|
|
|
}
|
|
|
|
|
2003-05-01 03:56:30 +00:00
|
|
|
#define MOD_STR(t, a, s, c) { \
|
|
|
|
COPY32(t, a, c); \
|
|
|
|
COPY32(strlen(s) + 1, a, c); \
|
|
|
|
if (c) \
|
|
|
|
i386_copyin(s, a, strlen(s) + 1); \
|
2018-03-13 16:33:00 +00:00
|
|
|
a += roundup(strlen(s) + 1, sizeof(uint64_t));\
|
1998-08-21 03:17:42 +00:00
|
|
|
}
|
|
|
|
|
2003-05-01 03:56:30 +00:00
|
|
|
#define MOD_NAME(a, s, c) MOD_STR(MODINFO_NAME, a, s, c)
|
|
|
|
#define MOD_TYPE(a, s, c) MOD_STR(MODINFO_TYPE, a, s, c)
|
|
|
|
#define MOD_ARGS(a, s, c) MOD_STR(MODINFO_ARGS, a, s, c)
|
1998-08-21 03:17:42 +00:00
|
|
|
|
2003-05-01 03:56:30 +00:00
|
|
|
#define MOD_VAR(t, a, s, c) { \
|
|
|
|
COPY32(t, a, c); \
|
|
|
|
COPY32(sizeof(s), a, c); \
|
|
|
|
if (c) \
|
|
|
|
i386_copyin(&s, a, sizeof(s)); \
|
2018-03-13 16:33:00 +00:00
|
|
|
a += roundup(sizeof(s), sizeof(uint64_t)); \
|
1998-08-21 03:17:42 +00:00
|
|
|
}
|
|
|
|
|
2003-05-01 03:56:30 +00:00
|
|
|
#define MOD_ADDR(a, s, c) MOD_VAR(MODINFO_ADDR, a, s, c)
|
|
|
|
#define MOD_SIZE(a, s, c) MOD_VAR(MODINFO_SIZE, a, s, c)
|
1998-08-21 03:17:42 +00:00
|
|
|
|
2003-05-01 03:56:30 +00:00
|
|
|
#define MOD_METADATA(a, mm, c) { \
|
|
|
|
COPY32(MODINFO_METADATA | mm->md_type, a, c); \
|
|
|
|
COPY32(mm->md_size, a, c); \
|
|
|
|
if (c) \
|
|
|
|
i386_copyin(mm->md_data, a, mm->md_size); \
|
2018-03-13 16:33:00 +00:00
|
|
|
a += roundup(mm->md_size, sizeof(uint64_t));\
|
1998-08-21 03:17:42 +00:00
|
|
|
}
|
|
|
|
|
2003-05-01 03:56:30 +00:00
|
|
|
#define MOD_END(a, c) { \
|
|
|
|
COPY32(MODINFO_END, a, c); \
|
|
|
|
COPY32(0, a, c); \
|
1998-09-14 18:27:06 +00:00
|
|
|
}
|
|
|
|
|
2003-05-01 03:56:30 +00:00
|
|
|
static vm_offset_t
|
|
|
|
bi_copymodules64(vm_offset_t addr)
|
1998-08-21 03:17:42 +00:00
|
|
|
{
|
2000-05-01 17:41:25 +00:00
|
|
|
struct preloaded_file *fp;
|
|
|
|
struct file_metadata *md;
|
2003-05-01 03:56:30 +00:00
|
|
|
int c;
|
2018-03-13 16:33:00 +00:00
|
|
|
uint64_t v;
|
1998-08-21 03:17:42 +00:00
|
|
|
|
2003-05-01 03:56:30 +00:00
|
|
|
c = addr != 0;
|
1998-08-21 03:17:42 +00:00
|
|
|
/* start with the first module on the list, should be the kernel */
|
2000-05-01 17:41:25 +00:00
|
|
|
for (fp = file_findfile(NULL, NULL); fp != NULL; fp = fp->f_next) {
|
1998-10-09 23:24:55 +00:00
|
|
|
|
2003-05-01 03:56:30 +00:00
|
|
|
MOD_NAME(addr, fp->f_name, c); /* this field must come first */
|
|
|
|
MOD_TYPE(addr, fp->f_type, c);
|
2000-05-01 17:41:25 +00:00
|
|
|
if (fp->f_args)
|
2003-05-01 03:56:30 +00:00
|
|
|
MOD_ARGS(addr, fp->f_args, c);
|
|
|
|
v = fp->f_addr;
|
|
|
|
MOD_ADDR(addr, v, c);
|
|
|
|
v = fp->f_size;
|
|
|
|
MOD_SIZE(addr, v, c);
|
2000-05-01 17:41:25 +00:00
|
|
|
for (md = fp->f_metadata; md != NULL; md = md->md_next)
|
1998-09-03 02:10:09 +00:00
|
|
|
if (!(md->md_type & MODINFOMD_NOCOPY))
|
2003-05-01 03:56:30 +00:00
|
|
|
MOD_METADATA(addr, md, c);
|
1998-08-21 03:17:42 +00:00
|
|
|
}
|
2003-05-01 03:56:30 +00:00
|
|
|
MOD_END(addr, c);
|
1998-08-21 03:17:42 +00:00
|
|
|
return(addr);
|
|
|
|
}
|
1998-10-02 20:53:17 +00:00
|
|
|
|
|
|
|
/*
|
2008-10-07 14:05:42 +00:00
|
|
|
* Check to see if this CPU supports long mode.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
bi_checkcpu(void)
|
|
|
|
{
|
|
|
|
char *cpu_vendor;
|
|
|
|
int vendor[3];
|
2013-01-14 15:05:22 +00:00
|
|
|
int eflags;
|
|
|
|
unsigned int regs[4];
|
2008-10-07 14:05:42 +00:00
|
|
|
|
|
|
|
/* Check for presence of "cpuid". */
|
|
|
|
eflags = read_eflags();
|
|
|
|
write_eflags(eflags ^ PSL_ID);
|
|
|
|
if (!((eflags ^ read_eflags()) & PSL_ID))
|
|
|
|
return (0);
|
|
|
|
|
|
|
|
/* Fetch the vendor string. */
|
|
|
|
do_cpuid(0, regs);
|
|
|
|
vendor[0] = regs[1];
|
|
|
|
vendor[1] = regs[3];
|
|
|
|
vendor[2] = regs[2];
|
|
|
|
cpu_vendor = (char *)vendor;
|
|
|
|
|
|
|
|
/* Check for vendors that support AMD features. */
|
2009-01-12 16:28:19 +00:00
|
|
|
if (strncmp(cpu_vendor, INTEL_VENDOR_ID, 12) != 0 &&
|
|
|
|
strncmp(cpu_vendor, AMD_VENDOR_ID, 12) != 0 &&
|
Add support for Hygon Dhyana Family 18h processor.
As a new x86 CPU vendor, Chengdu Haiguang IC Design Co., Ltd (Hygon)
is a joint venture between AMD and Haiguang Information Technology Co.,
Ltd., aims at providing x86 processors for China server market.
The first generation Hygon processor(Dhyana) shares most architecture
with AMD's family 17h, but with different CPU vendor ID("HygonGenuine")
and PCI vendor ID(0x1d94) and family series number 18h(Hygon negotiated
with AMD to confirm that only Hygon use family 18h).
To enable Hygon Dhyana support in FreeBSD, add new definitions
HYGON_VENDOR_ID("HygonGenuine") and X86_VENDOR_HYGON(0x1d94) to identify
Hygon Dhyana CPU.
Initialize the CPU features(topology, local APIC ext, MSI, TSC, hwpstate,
MCA, DEBUG_CTL, etc) for amd64 and i386 mode by sharing the code path of
AMD family 17h.
The changes have been applied on FreeBSD 13.0-CURRENT and tested
successfully on Hygon Dhyana processor.
References:
[1] Linux kernel patches for Hygon Dhyana, merged in 4.20:
https://git.kernel.org/tip/c9661c1e80b609cd038db7c908e061f0535804ef
[2] MSR and CPUID definition:
https://www.amd.com/system/files/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf
Submitted by: Pu Wen <puwen@hygon.cn>
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D23163
2020-01-21 13:22:35 +00:00
|
|
|
strncmp(cpu_vendor, HYGON_VENDOR_ID, 12) != 0 &&
|
2009-01-12 16:28:19 +00:00
|
|
|
strncmp(cpu_vendor, CENTAUR_VENDOR_ID, 12) != 0)
|
2008-10-07 14:05:42 +00:00
|
|
|
return (0);
|
|
|
|
|
|
|
|
/* Has to support AMD features. */
|
|
|
|
do_cpuid(0x80000000, regs);
|
|
|
|
if (!(regs[0] >= 0x80000001))
|
|
|
|
return (0);
|
|
|
|
|
|
|
|
/* Check for long mode. */
|
|
|
|
do_cpuid(0x80000001, regs);
|
|
|
|
return (regs[3] & AMDID_LM);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Load the information expected by an amd64 kernel.
|
1998-10-02 20:53:17 +00:00
|
|
|
*
|
|
|
|
* - The 'boothowto' argument is constructed
|
2000-08-03 09:14:02 +00:00
|
|
|
* - The 'bootdev' argument is constructed
|
1998-10-02 20:53:17 +00:00
|
|
|
* - The 'bootinfo' struct is constructed, and copied into the kernel space.
|
|
|
|
* - The kernel environment is copied into kernel space.
|
|
|
|
* - Module metadata are formatted and placed in kernel space.
|
|
|
|
*/
|
|
|
|
int
|
loader: implement multiboot support for Xen Dom0
Implement a subset of the multiboot specification in order to boot Xen
and a FreeBSD Dom0 from the FreeBSD bootloader. This multiboot
implementation is tailored to boot Xen and FreeBSD Dom0, and it will
most surely fail to boot any other multiboot compilant kernel.
In order to detect and boot the Xen microkernel, two new file formats
are added to the bootloader, multiboot and multiboot_obj. Multiboot
support must be tested before regular ELF support, since Xen is a
multiboot kernel that also uses ELF. After a multiboot kernel is
detected, all the other loaded kernels/modules are parsed by the
multiboot_obj format.
The layout of the loaded objects in memory is the following; first the
Xen kernel is loaded as a 32bit ELF into memory (Xen will switch to
long mode by itself), after that the FreeBSD kernel is loaded as a RAW
file (Xen will parse and load it using it's internal ELF loader), and
finally the metadata and the modules are loaded using the native
FreeBSD way. After everything is loaded we jump into Xen's entry point
using a small trampoline. The order of the multiboot modules passed to
Xen is the following, the first module is the RAW FreeBSD kernel, and
the second module is the metadata and the FreeBSD modules.
Since Xen will relocate the memory position of the second
multiboot module (the one that contains the metadata and native
FreeBSD modules), we need to stash the original modulep address inside
of the metadata itself in order to recalculate its position once
booted. This also means the metadata must come before the loaded
modules, so after loading the FreeBSD kernel a portion of memory is
reserved in order to place the metadata before booting.
In order to tell the loader to boot Xen and then the FreeBSD kernel the
following has to be added to the /boot/loader.conf file:
xen_cmdline="dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga"
xen_kernel="/boot/xen"
The first argument contains the command line that will be passed to the Xen
kernel, while the second argument is the path to the Xen kernel itself. This
can also be done manually from the loader command line, by for example
typing the following set of commands:
OK unload
OK load /boot/xen dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga
OK load kernel
OK load zfs
OK load if_tap
OK load ...
OK boot
Sponsored by: Citrix Systems R&D
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D517
For the Forth bits:
Submitted by: Julien Grall <julien.grall AT citrix.com>
2015-01-15 16:27:20 +00:00
|
|
|
bi_load64(char *args, vm_offset_t addr, vm_offset_t *modulep,
|
|
|
|
vm_offset_t *kernendp, int add_smap)
|
1998-10-02 20:53:17 +00:00
|
|
|
{
|
2003-05-01 03:56:30 +00:00
|
|
|
struct preloaded_file *xp, *kfp;
|
1998-10-02 20:53:17 +00:00
|
|
|
struct i386_devdesc *rootdev;
|
2003-05-01 03:56:30 +00:00
|
|
|
struct file_metadata *md;
|
2018-03-13 16:33:00 +00:00
|
|
|
uint64_t kernend;
|
|
|
|
uint64_t envp;
|
|
|
|
uint64_t module;
|
2003-05-01 03:56:30 +00:00
|
|
|
vm_offset_t size;
|
1998-10-02 20:53:17 +00:00
|
|
|
char *rootdevname;
|
2006-09-29 20:27:41 +00:00
|
|
|
int howto;
|
1998-10-02 20:53:17 +00:00
|
|
|
|
2008-10-07 14:05:42 +00:00
|
|
|
if (!bi_checkcpu()) {
|
|
|
|
printf("CPU doesn't support long mode\n");
|
|
|
|
return (EINVAL);
|
|
|
|
}
|
|
|
|
|
2003-05-01 03:56:30 +00:00
|
|
|
howto = bi_getboothowto(args);
|
1998-10-02 20:53:17 +00:00
|
|
|
|
Implement boot-time encryption key passing (keybuf)
This patch adds a general mechanism for providing encryption keys to the
kernel from the boot loader. This is intended to enable GELI support at
boot time, providing a better mechanism for passing keys to the kernel
than environment variables. It is designed to be extensible to other
applications, and can easily handle multiple encrypted volumes with
different keys.
This mechanism is currently used by the pending GELI EFI work.
Additionally, this mechanism can potentially be used to interface with
GRUB, opening up options for coreboot+GRUB configurations with completely
encrypted disks.
Another benefit over the existing system is that it does not require
re-deriving the user key from the password at each boot stage.
Most of this patch was written by Eric McCorkle. It was extended by
Allan Jude with a number of minor enhancements and extending the keybuf
feature into boot2.
GELI user keys are now derived once, in boot2, then passed to the loader,
which reuses the key, then passes it to the kernel, where the GELI module
destroys the keybuf after decrypting the volumes.
Submitted by: Eric McCorkle <eric@metricspace.net> (Original Version)
Reviewed by: oshogbo (earlier version), cem (earlier version)
MFC after: 3 weeks
Relnotes: yes
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D9575
2017-04-01 05:05:22 +00:00
|
|
|
/*
|
|
|
|
* Allow the environment variable 'rootdev' to override the supplied device
|
1998-10-02 20:53:17 +00:00
|
|
|
* This should perhaps go to MI code and/or have $rootdev tested/set by
|
|
|
|
* MI code before launching the kernel.
|
|
|
|
*/
|
|
|
|
rootdevname = getenv("rootdev");
|
|
|
|
i386_getdev((void **)(&rootdev), rootdevname, NULL);
|
|
|
|
if (rootdev == NULL) { /* bad $rootdev/$currdev */
|
|
|
|
printf("can't determine root device\n");
|
|
|
|
return(EINVAL);
|
|
|
|
}
|
1998-11-13 23:40:02 +00:00
|
|
|
|
1999-07-21 00:08:54 +00:00
|
|
|
/* Try reading the /etc/fstab file to select the root device */
|
|
|
|
getrootmount(i386_fmtdev((void *)rootdev));
|
|
|
|
|
loader: implement multiboot support for Xen Dom0
Implement a subset of the multiboot specification in order to boot Xen
and a FreeBSD Dom0 from the FreeBSD bootloader. This multiboot
implementation is tailored to boot Xen and FreeBSD Dom0, and it will
most surely fail to boot any other multiboot compilant kernel.
In order to detect and boot the Xen microkernel, two new file formats
are added to the bootloader, multiboot and multiboot_obj. Multiboot
support must be tested before regular ELF support, since Xen is a
multiboot kernel that also uses ELF. After a multiboot kernel is
detected, all the other loaded kernels/modules are parsed by the
multiboot_obj format.
The layout of the loaded objects in memory is the following; first the
Xen kernel is loaded as a 32bit ELF into memory (Xen will switch to
long mode by itself), after that the FreeBSD kernel is loaded as a RAW
file (Xen will parse and load it using it's internal ELF loader), and
finally the metadata and the modules are loaded using the native
FreeBSD way. After everything is loaded we jump into Xen's entry point
using a small trampoline. The order of the multiboot modules passed to
Xen is the following, the first module is the RAW FreeBSD kernel, and
the second module is the metadata and the FreeBSD modules.
Since Xen will relocate the memory position of the second
multiboot module (the one that contains the metadata and native
FreeBSD modules), we need to stash the original modulep address inside
of the metadata itself in order to recalculate its position once
booted. This also means the metadata must come before the loaded
modules, so after loading the FreeBSD kernel a portion of memory is
reserved in order to place the metadata before booting.
In order to tell the loader to boot Xen and then the FreeBSD kernel the
following has to be added to the /boot/loader.conf file:
xen_cmdline="dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga"
xen_kernel="/boot/xen"
The first argument contains the command line that will be passed to the Xen
kernel, while the second argument is the path to the Xen kernel itself. This
can also be done manually from the loader command line, by for example
typing the following set of commands:
OK unload
OK load /boot/xen dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga
OK load kernel
OK load zfs
OK load if_tap
OK load ...
OK boot
Sponsored by: Citrix Systems R&D
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D517
For the Forth bits:
Submitted by: Julien Grall <julien.grall AT citrix.com>
2015-01-15 16:27:20 +00:00
|
|
|
if (addr == 0) {
|
|
|
|
/* find the last module in the chain */
|
|
|
|
for (xp = file_findfile(NULL, NULL); xp != NULL; xp = xp->f_next) {
|
|
|
|
if (addr < (xp->f_addr + xp->f_size))
|
|
|
|
addr = xp->f_addr + xp->f_size;
|
|
|
|
}
|
1998-10-15 17:06:36 +00:00
|
|
|
}
|
1998-10-02 20:53:17 +00:00
|
|
|
/* pad to a page boundary */
|
2003-05-01 03:56:30 +00:00
|
|
|
addr = roundup(addr, PAGE_SIZE);
|
1998-10-02 20:53:17 +00:00
|
|
|
|
loader: implement multiboot support for Xen Dom0
Implement a subset of the multiboot specification in order to boot Xen
and a FreeBSD Dom0 from the FreeBSD bootloader. This multiboot
implementation is tailored to boot Xen and FreeBSD Dom0, and it will
most surely fail to boot any other multiboot compilant kernel.
In order to detect and boot the Xen microkernel, two new file formats
are added to the bootloader, multiboot and multiboot_obj. Multiboot
support must be tested before regular ELF support, since Xen is a
multiboot kernel that also uses ELF. After a multiboot kernel is
detected, all the other loaded kernels/modules are parsed by the
multiboot_obj format.
The layout of the loaded objects in memory is the following; first the
Xen kernel is loaded as a 32bit ELF into memory (Xen will switch to
long mode by itself), after that the FreeBSD kernel is loaded as a RAW
file (Xen will parse and load it using it's internal ELF loader), and
finally the metadata and the modules are loaded using the native
FreeBSD way. After everything is loaded we jump into Xen's entry point
using a small trampoline. The order of the multiboot modules passed to
Xen is the following, the first module is the RAW FreeBSD kernel, and
the second module is the metadata and the FreeBSD modules.
Since Xen will relocate the memory position of the second
multiboot module (the one that contains the metadata and native
FreeBSD modules), we need to stash the original modulep address inside
of the metadata itself in order to recalculate its position once
booted. This also means the metadata must come before the loaded
modules, so after loading the FreeBSD kernel a portion of memory is
reserved in order to place the metadata before booting.
In order to tell the loader to boot Xen and then the FreeBSD kernel the
following has to be added to the /boot/loader.conf file:
xen_cmdline="dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga"
xen_kernel="/boot/xen"
The first argument contains the command line that will be passed to the Xen
kernel, while the second argument is the path to the Xen kernel itself. This
can also be done manually from the loader command line, by for example
typing the following set of commands:
OK unload
OK load /boot/xen dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga
OK load kernel
OK load zfs
OK load if_tap
OK load ...
OK boot
Sponsored by: Citrix Systems R&D
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D517
For the Forth bits:
Submitted by: Julien Grall <julien.grall AT citrix.com>
2015-01-15 16:27:20 +00:00
|
|
|
/* place the metadata before anything */
|
2015-01-20 12:28:24 +00:00
|
|
|
module = *modulep = addr;
|
2003-05-01 03:56:30 +00:00
|
|
|
|
2003-05-01 04:31:33 +00:00
|
|
|
kfp = file_findfile(NULL, "elf kernel");
|
2003-05-01 03:56:30 +00:00
|
|
|
if (kfp == NULL)
|
2003-05-01 04:31:33 +00:00
|
|
|
kfp = file_findfile(NULL, "elf64 kernel");
|
2003-05-01 03:56:30 +00:00
|
|
|
if (kfp == NULL)
|
|
|
|
panic("can't find kernel file");
|
|
|
|
kernend = 0; /* fill it in later */
|
|
|
|
file_addmetadata(kfp, MODINFOMD_HOWTO, sizeof howto, &howto);
|
|
|
|
file_addmetadata(kfp, MODINFOMD_ENVP, sizeof envp, &envp);
|
|
|
|
file_addmetadata(kfp, MODINFOMD_KERNEND, sizeof kernend, &kernend);
|
2015-01-20 12:28:24 +00:00
|
|
|
file_addmetadata(kfp, MODINFOMD_MODULEP, sizeof module, &module);
|
loader: implement multiboot support for Xen Dom0
Implement a subset of the multiboot specification in order to boot Xen
and a FreeBSD Dom0 from the FreeBSD bootloader. This multiboot
implementation is tailored to boot Xen and FreeBSD Dom0, and it will
most surely fail to boot any other multiboot compilant kernel.
In order to detect and boot the Xen microkernel, two new file formats
are added to the bootloader, multiboot and multiboot_obj. Multiboot
support must be tested before regular ELF support, since Xen is a
multiboot kernel that also uses ELF. After a multiboot kernel is
detected, all the other loaded kernels/modules are parsed by the
multiboot_obj format.
The layout of the loaded objects in memory is the following; first the
Xen kernel is loaded as a 32bit ELF into memory (Xen will switch to
long mode by itself), after that the FreeBSD kernel is loaded as a RAW
file (Xen will parse and load it using it's internal ELF loader), and
finally the metadata and the modules are loaded using the native
FreeBSD way. After everything is loaded we jump into Xen's entry point
using a small trampoline. The order of the multiboot modules passed to
Xen is the following, the first module is the RAW FreeBSD kernel, and
the second module is the metadata and the FreeBSD modules.
Since Xen will relocate the memory position of the second
multiboot module (the one that contains the metadata and native
FreeBSD modules), we need to stash the original modulep address inside
of the metadata itself in order to recalculate its position once
booted. This also means the metadata must come before the loaded
modules, so after loading the FreeBSD kernel a portion of memory is
reserved in order to place the metadata before booting.
In order to tell the loader to boot Xen and then the FreeBSD kernel the
following has to be added to the /boot/loader.conf file:
xen_cmdline="dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga"
xen_kernel="/boot/xen"
The first argument contains the command line that will be passed to the Xen
kernel, while the second argument is the path to the Xen kernel itself. This
can also be done manually from the loader command line, by for example
typing the following set of commands:
OK unload
OK load /boot/xen dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga
OK load kernel
OK load zfs
OK load if_tap
OK load ...
OK boot
Sponsored by: Citrix Systems R&D
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D517
For the Forth bits:
Submitted by: Julien Grall <julien.grall AT citrix.com>
2015-01-15 16:27:20 +00:00
|
|
|
if (add_smap != 0)
|
|
|
|
bios_addsmapdata(kfp);
|
Implement boot-time encryption key passing (keybuf)
This patch adds a general mechanism for providing encryption keys to the
kernel from the boot loader. This is intended to enable GELI support at
boot time, providing a better mechanism for passing keys to the kernel
than environment variables. It is designed to be extensible to other
applications, and can easily handle multiple encrypted volumes with
different keys.
This mechanism is currently used by the pending GELI EFI work.
Additionally, this mechanism can potentially be used to interface with
GRUB, opening up options for coreboot+GRUB configurations with completely
encrypted disks.
Another benefit over the existing system is that it does not require
re-deriving the user key from the password at each boot stage.
Most of this patch was written by Eric McCorkle. It was extended by
Allan Jude with a number of minor enhancements and extending the keybuf
feature into boot2.
GELI user keys are now derived once, in boot2, then passed to the loader,
which reuses the key, then passes it to the kernel, where the GELI module
destroys the keybuf after decrypting the volumes.
Submitted by: Eric McCorkle <eric@metricspace.net> (Original Version)
Reviewed by: oshogbo (earlier version), cem (earlier version)
MFC after: 3 weeks
Relnotes: yes
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D9575
2017-04-01 05:05:22 +00:00
|
|
|
#ifdef LOADER_GELI_SUPPORT
|
2018-07-13 17:50:25 +00:00
|
|
|
geli_export_key_metadata(kfp);
|
Implement boot-time encryption key passing (keybuf)
This patch adds a general mechanism for providing encryption keys to the
kernel from the boot loader. This is intended to enable GELI support at
boot time, providing a better mechanism for passing keys to the kernel
than environment variables. It is designed to be extensible to other
applications, and can easily handle multiple encrypted volumes with
different keys.
This mechanism is currently used by the pending GELI EFI work.
Additionally, this mechanism can potentially be used to interface with
GRUB, opening up options for coreboot+GRUB configurations with completely
encrypted disks.
Another benefit over the existing system is that it does not require
re-deriving the user key from the password at each boot stage.
Most of this patch was written by Eric McCorkle. It was extended by
Allan Jude with a number of minor enhancements and extending the keybuf
feature into boot2.
GELI user keys are now derived once, in boot2, then passed to the loader,
which reuses the key, then passes it to the kernel, where the GELI module
destroys the keybuf after decrypting the volumes.
Submitted by: Eric McCorkle <eric@metricspace.net> (Original Version)
Reviewed by: oshogbo (earlier version), cem (earlier version)
MFC after: 3 weeks
Relnotes: yes
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D9575
2017-04-01 05:05:22 +00:00
|
|
|
#endif
|
|
|
|
|
2003-05-01 03:56:30 +00:00
|
|
|
size = bi_copymodules64(0);
|
loader: implement multiboot support for Xen Dom0
Implement a subset of the multiboot specification in order to boot Xen
and a FreeBSD Dom0 from the FreeBSD bootloader. This multiboot
implementation is tailored to boot Xen and FreeBSD Dom0, and it will
most surely fail to boot any other multiboot compilant kernel.
In order to detect and boot the Xen microkernel, two new file formats
are added to the bootloader, multiboot and multiboot_obj. Multiboot
support must be tested before regular ELF support, since Xen is a
multiboot kernel that also uses ELF. After a multiboot kernel is
detected, all the other loaded kernels/modules are parsed by the
multiboot_obj format.
The layout of the loaded objects in memory is the following; first the
Xen kernel is loaded as a 32bit ELF into memory (Xen will switch to
long mode by itself), after that the FreeBSD kernel is loaded as a RAW
file (Xen will parse and load it using it's internal ELF loader), and
finally the metadata and the modules are loaded using the native
FreeBSD way. After everything is loaded we jump into Xen's entry point
using a small trampoline. The order of the multiboot modules passed to
Xen is the following, the first module is the RAW FreeBSD kernel, and
the second module is the metadata and the FreeBSD modules.
Since Xen will relocate the memory position of the second
multiboot module (the one that contains the metadata and native
FreeBSD modules), we need to stash the original modulep address inside
of the metadata itself in order to recalculate its position once
booted. This also means the metadata must come before the loaded
modules, so after loading the FreeBSD kernel a portion of memory is
reserved in order to place the metadata before booting.
In order to tell the loader to boot Xen and then the FreeBSD kernel the
following has to be added to the /boot/loader.conf file:
xen_cmdline="dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga"
xen_kernel="/boot/xen"
The first argument contains the command line that will be passed to the Xen
kernel, while the second argument is the path to the Xen kernel itself. This
can also be done manually from the loader command line, by for example
typing the following set of commands:
OK unload
OK load /boot/xen dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga
OK load kernel
OK load zfs
OK load if_tap
OK load ...
OK boot
Sponsored by: Citrix Systems R&D
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D517
For the Forth bits:
Submitted by: Julien Grall <julien.grall AT citrix.com>
2015-01-15 16:27:20 +00:00
|
|
|
|
|
|
|
/* copy our environment */
|
|
|
|
envp = roundup(addr + size, PAGE_SIZE);
|
|
|
|
addr = bi_copyenv(envp);
|
|
|
|
|
|
|
|
/* set kernend */
|
|
|
|
kernend = roundup(addr, PAGE_SIZE);
|
2003-05-01 03:56:30 +00:00
|
|
|
*kernendp = kernend;
|
|
|
|
|
|
|
|
/* patch MODINFOMD_KERNEND */
|
|
|
|
md = file_findmetadata(kfp, MODINFOMD_KERNEND);
|
|
|
|
bcopy(&kernend, md->md_data, sizeof kernend);
|
1998-10-02 20:53:17 +00:00
|
|
|
|
loader: implement multiboot support for Xen Dom0
Implement a subset of the multiboot specification in order to boot Xen
and a FreeBSD Dom0 from the FreeBSD bootloader. This multiboot
implementation is tailored to boot Xen and FreeBSD Dom0, and it will
most surely fail to boot any other multiboot compilant kernel.
In order to detect and boot the Xen microkernel, two new file formats
are added to the bootloader, multiboot and multiboot_obj. Multiboot
support must be tested before regular ELF support, since Xen is a
multiboot kernel that also uses ELF. After a multiboot kernel is
detected, all the other loaded kernels/modules are parsed by the
multiboot_obj format.
The layout of the loaded objects in memory is the following; first the
Xen kernel is loaded as a 32bit ELF into memory (Xen will switch to
long mode by itself), after that the FreeBSD kernel is loaded as a RAW
file (Xen will parse and load it using it's internal ELF loader), and
finally the metadata and the modules are loaded using the native
FreeBSD way. After everything is loaded we jump into Xen's entry point
using a small trampoline. The order of the multiboot modules passed to
Xen is the following, the first module is the RAW FreeBSD kernel, and
the second module is the metadata and the FreeBSD modules.
Since Xen will relocate the memory position of the second
multiboot module (the one that contains the metadata and native
FreeBSD modules), we need to stash the original modulep address inside
of the metadata itself in order to recalculate its position once
booted. This also means the metadata must come before the loaded
modules, so after loading the FreeBSD kernel a portion of memory is
reserved in order to place the metadata before booting.
In order to tell the loader to boot Xen and then the FreeBSD kernel the
following has to be added to the /boot/loader.conf file:
xen_cmdline="dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga"
xen_kernel="/boot/xen"
The first argument contains the command line that will be passed to the Xen
kernel, while the second argument is the path to the Xen kernel itself. This
can also be done manually from the loader command line, by for example
typing the following set of commands:
OK unload
OK load /boot/xen dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga
OK load kernel
OK load zfs
OK load if_tap
OK load ...
OK boot
Sponsored by: Citrix Systems R&D
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D517
For the Forth bits:
Submitted by: Julien Grall <julien.grall AT citrix.com>
2015-01-15 16:27:20 +00:00
|
|
|
/* patch MODINFOMD_ENVP */
|
|
|
|
md = file_findmetadata(kfp, MODINFOMD_ENVP);
|
|
|
|
bcopy(&envp, md->md_data, sizeof envp);
|
|
|
|
|
2003-05-01 03:56:30 +00:00
|
|
|
/* copy module list and metadata */
|
loader: implement multiboot support for Xen Dom0
Implement a subset of the multiboot specification in order to boot Xen
and a FreeBSD Dom0 from the FreeBSD bootloader. This multiboot
implementation is tailored to boot Xen and FreeBSD Dom0, and it will
most surely fail to boot any other multiboot compilant kernel.
In order to detect and boot the Xen microkernel, two new file formats
are added to the bootloader, multiboot and multiboot_obj. Multiboot
support must be tested before regular ELF support, since Xen is a
multiboot kernel that also uses ELF. After a multiboot kernel is
detected, all the other loaded kernels/modules are parsed by the
multiboot_obj format.
The layout of the loaded objects in memory is the following; first the
Xen kernel is loaded as a 32bit ELF into memory (Xen will switch to
long mode by itself), after that the FreeBSD kernel is loaded as a RAW
file (Xen will parse and load it using it's internal ELF loader), and
finally the metadata and the modules are loaded using the native
FreeBSD way. After everything is loaded we jump into Xen's entry point
using a small trampoline. The order of the multiboot modules passed to
Xen is the following, the first module is the RAW FreeBSD kernel, and
the second module is the metadata and the FreeBSD modules.
Since Xen will relocate the memory position of the second
multiboot module (the one that contains the metadata and native
FreeBSD modules), we need to stash the original modulep address inside
of the metadata itself in order to recalculate its position once
booted. This also means the metadata must come before the loaded
modules, so after loading the FreeBSD kernel a portion of memory is
reserved in order to place the metadata before booting.
In order to tell the loader to boot Xen and then the FreeBSD kernel the
following has to be added to the /boot/loader.conf file:
xen_cmdline="dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga"
xen_kernel="/boot/xen"
The first argument contains the command line that will be passed to the Xen
kernel, while the second argument is the path to the Xen kernel itself. This
can also be done manually from the loader command line, by for example
typing the following set of commands:
OK unload
OK load /boot/xen dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga
OK load kernel
OK load zfs
OK load if_tap
OK load ...
OK boot
Sponsored by: Citrix Systems R&D
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D517
For the Forth bits:
Submitted by: Julien Grall <julien.grall AT citrix.com>
2015-01-15 16:27:20 +00:00
|
|
|
(void)bi_copymodules64(*modulep);
|
1998-10-02 20:53:17 +00:00
|
|
|
|
|
|
|
return(0);
|
|
|
|
}
|