pvh: Support booting via PVH ELFNOTE #26

We don't actually need an AtomicRefcell here. It's fine for paging::setup() to run multiple times, it's idempontent and we only do writes. We also place the page tables in #[no_mangle] static mut variables so they can be linked from assembly code. Signed-off-by: Joe Richey <[email protected]>

We really only need from_bytes and as_bytes. There's no need for a generic from_slice method. Signed-off-by: Joe Richey <[email protected]>

As our error types are enums, we can include the "source" error in our later error types. This allows for more information when debugging failures. To this end, we also implement Debug. Signed-off-by: Joe Richey <[email protected]>

We can have `ascii_strip` use entirely safe code by `unwrap()`ing the result of `from_utf8` instead of using `from_utf8_unchecked`. We also add a helper function to convert a C-string pointer into a byte slice. Signed-off-by: Joe Richey <[email protected]>

To support multiple boot protocols, we need a common abstraction for the information given in a boot protocol. This is the Info trait. This also requires adding a common E820Entry structure, so we can get the memory map. We also add a boot::Params structure (i.e. the Linux Zeropage) to make reading/writing the structure easier. This will let us avoid needing to hardcode struct offsets. The layout for these structures is taken from the Kernel's arch/x86/include/uapi/asm/bootparam.h Signed-off-by: Joe Richey <[email protected]>

This allows much of the existing code to be simplified, by letting us load the remainer of a file into a specific memory region. This also makes it much easier to write the code to load the Linux Kernel header from the bzimage file. Signed-off-by: Joe Richey <[email protected]>

This works because Option<&T> has the same FFI layout as *const T except that a null pointer is None. Signed-off-by: Joe Richey <[email protected]>

This allows efi_exec to work with multiple boot protocols. Signed-off-by: Joe Richey <[email protected]>

This allows Linux to be booted with any boot protocol. The old code took in the Zeropage passed in via the Linux Kernel Boot Protocol, modified it, and passed it into the Linux Kernel. This is not the correct way to boot Linux per the documentation: https://www.kernel.org/doc/Documentation/x86/boot.txt This code now correctly: - Uses a brand-new Zeropage inside the `Kernel` struct - Adds in the E820 map and RSDP pointer from the boot::Info - Reads the header from the file and copies it into the Zeropage - Loads the kernel and initrd into avalible memory - Properly manages the command-line at a fixed memory location - Jumps to the appropriate starting address Signed-off-by: Joe Richey <[email protected]>

We now pass the boot::Info to `loader::load_default_entry` and `efi::efi_exec`. We also reorganize the code in this function to: - Avoid unnecessary nesting - log errors when they occur The code is now much more readable Signed-off-by: Joe Richey <[email protected]>

These are simply translated from the C structs in: xen/include/public/arch-x86/hvm/start_info.h Note that unlike the Linux Boot Protocol structures, these structures don't need to be `#[repr(packed)]` as they are garunteed to have the proper alignment. Signed-off-by: Joe Richey <[email protected]>

This approch doesn't scale to our other ASM code and it clutters the output. Signed-off-by: Joe Richey <[email protected]>

Signed-off-by: Joe Richey <[email protected]>

Note that this also requires zeroing out %rdi in the Linux Boot Protocol path, so that the rdi parameter will have a valid repr. Signed-off-by: Joe Richey <[email protected]>

PVH starts in 32-bit mode, so we have to transition to 64-bit mode before we can start running Rust code. As we have not yet initialized the stack, we can only use registers and static memory. This transition does the following: - Sets up page tables to identity map 2 MiB - Loads page tables into CR3 - Sets CR4.PAE, EFER.LME, and CRO.PG - Sets up a 64-bit GDT - Long Jumps to 64-bit code We put the GDT in the .rodata section, and we put the 32-bit code in its own section. This makes it easier to debug and dissassemble the binary. Signed-off-by: Joe Richey <[email protected]>

This adds information to the ELF binary so that a loader will know where to start the executable. This now allows the firmware to be booted via the PVH Boot Protocol. Signed-off-by: Joe Richey <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

pvh: Support booting via PVH ELFNOTE #26

pvh: Support booting via PVH ELFNOTE #26

Commits on Mar 30, 2020