4cdb7ba9b6
This patch extends the protection domain framework with an additional plugin to use Task-State Segment (TSS) structures to offload much of the work of switching protection domains to the CPU. This can save space compared to paging, since paging requires two 4KiB page tables and one 32-byte page table plus one whole-system TSS and an additional 32-byte data structure for each protection domain, whereas the approach implemented by this patch just requires a 128-byte data structure for each protection domain. Only a small number of protection domains will typically be used, so n * 128 < 8328 + (n * 32). For additional information, please refer to cpu/x86/mm/README.md. GCC 6 is introducing named address spaces for the FS and GS segments [1]. LLVM Clang also provides address spaces for the FS and GS segments [2]. This patch also adds support to the multi-segment X86 memory management subsystem for using these features instead of inline assembly blocks, which enables type checking to detect some address space mismatches. [1] https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html [2] http://llvm.org/releases/3.3/tools/clang/docs/LanguageExtensions.html#target-specific-extensions
191 lines
6.4 KiB
Plaintext
191 lines
6.4 KiB
Plaintext
/*
|
|
* Copyright (C) 2015, Intel Corporation. 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.
|
|
*
|
|
* 3. Neither the name of the copyright holder nor the names of its
|
|
* contributors may be used to endorse or promote products derived
|
|
* from this software without specific prior written permission.
|
|
*
|
|
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS 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
|
|
* COPYRIGHT HOLDER 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.
|
|
*/
|
|
|
|
OUTPUT_FORMAT("elf32-i386")
|
|
|
|
ENTRY(start)
|
|
|
|
/*
|
|
The TSS-based protection domain implementation does not explicitly reference
|
|
these symbols, so we list them here to prevent them from being garbage-
|
|
collected.
|
|
*/
|
|
EXTERN(stacks_int)
|
|
EXTERN(stacks_exc)
|
|
|
|
PHDRS {
|
|
boot_text PT_LOAD;
|
|
text PT_LOAD;
|
|
data PT_LOAD;
|
|
}
|
|
|
|
SECTIONS {
|
|
/*
|
|
OS-Dev Wiki says it is common for kernels to start at 1M. Addresses before that
|
|
are used by BIOS/EFI, the bootloader and memory-mapped I/O.
|
|
|
|
The UEFI GenFw program inserts a 0x220 byte offset between the image base and
|
|
the .text section. We add that same offset here to align the symbols in the
|
|
UEFI DLL with those in the final UEFI binary to make debugging easier.
|
|
*/
|
|
. = 1M + 0x220;
|
|
|
|
/*
|
|
The GenFw program in the EDK2 UEFI toolchain outputs UEFI images with a
|
|
section alignment of at least 32 bytes. Thus, it is desirable to use at
|
|
least that alignment granularity to avoid symbols being shifted from the
|
|
intermediate DLL to the final UEFI image. Such shifting may make
|
|
debugging more difficult by preventing the DLL from being a useful
|
|
source of symbol information. The debugging symbols are not included in
|
|
the final UEFI image.
|
|
*/
|
|
.text.boot : ALIGN (32)
|
|
{
|
|
*(.multiboot)
|
|
/*
|
|
The initial bootstrap code expects to operate in a flat address
|
|
space with an identity mapping between linear and physical
|
|
addresses.
|
|
*/
|
|
*(.boot_text)
|
|
} :boot_text
|
|
|
|
/* The post-boot code segments define tight bounds around the code
|
|
section, so this directive resets the virtual address to 0. */
|
|
. = 0;
|
|
|
|
/* The virtual address differs from the load address. */
|
|
.text : AT(LOADADDR(.text.boot) + ALIGN(SIZEOF(.text.boot), 32)) ALIGN (32)
|
|
{
|
|
/*
|
|
These BYTE directives emit a UD2 instruction to cause execution to
|
|
halt if the control flow ever deviates to address 0. This also
|
|
prevents other code from being placed at address 0. Some code
|
|
considers a function pointer to address 0 to be a null function
|
|
pointer.
|
|
*/
|
|
BYTE(0x0F);
|
|
BYTE(0x0B);
|
|
*(.text*)
|
|
|
|
/*
|
|
An alternative design to eliminate the need for ALIGN directives
|
|
within the AT directives in later sections could have padded
|
|
each section out to a 32-byte boundary. However, that would have
|
|
enabled unneeded software accesses to the padding past the end of actual
|
|
code/data in each section, since segments are also configured based on
|
|
the values of the SIZEOF expressions. As a general principle, accesses
|
|
should be as restricted as is feasible.
|
|
*/
|
|
} :text
|
|
|
|
_stext_addr = LOADADDR(.text);
|
|
_etext_addr = LOADADDR(.text) + SIZEOF(.text);
|
|
|
|
. = 0;
|
|
|
|
.data : AT(ALIGN(_etext_addr, 32)) ALIGN (32)
|
|
{
|
|
*(.main_stack)
|
|
*(.int_stack)
|
|
*(.exc_stack)
|
|
*(.rodata*)
|
|
*(.data*)
|
|
|
|
/*
|
|
These could alternatively be treated as read-only data to prevent tampering
|
|
from the user privilege level.
|
|
*/
|
|
_sdata_shared_isr = .;
|
|
KEEP(*(.shared_isr_data*))
|
|
_edata_shared_isr = .;
|
|
} :data
|
|
|
|
.bss : ALIGN (32)
|
|
{
|
|
*(COMMON)
|
|
*(.bss*)
|
|
}
|
|
|
|
_sdata_addr = LOADADDR(.data);
|
|
_edata_addr = LOADADDR(.bss) + SIZEOF(.bss);
|
|
|
|
. = 0;
|
|
|
|
.bss.kern (NOLOAD) : AT(ALIGN(_edata_addr, 32)) ALIGN (32)
|
|
{
|
|
/*
|
|
This directive prevents any data from being allocated at address
|
|
zero, since the address 0 is commonly used to represent null
|
|
pointers.
|
|
*/
|
|
LONG(0);
|
|
*(.kern_bss)
|
|
|
|
syscalls_entrypoints = .;
|
|
*(.syscall_bss)
|
|
syscalls_entrypoints_end = .;
|
|
}
|
|
|
|
_ebss_syscall_addr = LOADADDR(.bss.kern) + SIZEOF(.bss.kern);
|
|
|
|
.bss.kern_priv (NOLOAD) : ALIGN (32)
|
|
{
|
|
prot_domains_kern_data = .;
|
|
/*
|
|
The kernel and app protection domain control structures must always
|
|
be placed in the first two slots in this order, so that they have
|
|
well-known protection domain IDs:
|
|
*/
|
|
*(.kern_prot_dom_bss)
|
|
*(.app_prot_dom_bss)
|
|
*(.prot_dom_bss)
|
|
prot_domains_kern_data_end = .;
|
|
|
|
*(.gdt_bss_start)
|
|
KEEP(*(.gdt_bss_mid))
|
|
*(.gdt_bss)
|
|
_ebss_gdt_addr = .;
|
|
}
|
|
|
|
_sbss_kern_addr = LOADADDR(.bss.kern);
|
|
_ebss_kern_addr = LOADADDR(.bss.kern_priv) + SIZEOF(.bss.kern_priv);
|
|
|
|
. = _ebss_kern_addr;
|
|
|
|
.bss.meta (NOLOAD) : AT(ALIGN(_ebss_kern_addr, 32)) ALIGN (32)
|
|
{
|
|
*(.meta_bss)
|
|
}
|
|
|
|
/* .bss.meta may be empty, so this uses .bss.kern_priv as a base instead: */
|
|
_ebss_pre_dma_addr = ALIGN(ALIGN(_ebss_kern_addr, 32) + SIZEOF(.bss.meta), 32);
|
|
}
|