---
# System prepended metadata

title: 'Bootloader WG, January 18, 2023'
tags: [' bootloader', unikraft, ' loader']

---

---
title: "Bootloader WG, January 18, 2023"
tags: unikraft, bootloader, loader
datetime: 2023-01-18T10:30:00+02:00
location: Online, Discord (https://bit.ly/UnikraftDiscord), the `#monkey-business` voice channel
teams:
- bootloader
participants:
- TODO
---

## :dart: Agenda

- Status update
- Next steps

## :closed_book: Discussions

SM: I started to look into GNU-EFI and managed to write a short loader that grabs the memory map, commandline and other metadata required in order to boot Unikraft on both bare-metal and KVM. The code is here and it is a mess, because all I wanted to do for now is get to coding and get a feeling for what might be required to achieve Unikraft running on bare-metal: https://github.com/mogasergiu/unikraft/commits/efi_stub
Along the way I was met with several problems (many of which I docummented throughout the code):
- UEFI requires a relocatable PE and Unikraft is not relocatable and it requires to be loaded at an illegal address in UEFI so I had to add a custom linker script to embed the final Unikraft image into my EFI loader so that I could take control from there and be somewhat compliant with UEFI
- integrating the efi-stub into the build system (Makefile.uk + Config.uk) was a pain because it is not something I could link with
(as stated in the above point) so I could not treat it like any other library and had to do some ugly workarounds (including copy-pasting some headers into the same directory)
- GNU-EFI is GPLv2 and we link against it, I think I would like to write our own UEFI definitions and relocator so that we do not depend on it (like GRUB and U-Boot do), which would take some more time but is not difficult
- I had to do some dirty hacks to be able to boot the Unikraft Multiboot1 image from UEFI and also had to jump over the static page tables from Unikraft and actually use those from EFI's
- I would like to do some re-work of the ACPI subsystem to accomodate ACPI 2.0 and the MCFG, not just MADT, since I was also able to parse the PCIe peripherals through ECAM, it could provide further work on higher performance drivers. Also managed to boot with SMP on baremetal but had to do a fall-back on RSDT since Unikraft does not know of XSDT.
- for bare-metal in order to print something to the screen from Unikraft, as I do not have a serial port and VGA is extinct, I had to initialise my GPU's VRAM through GOP and draw something on the screen instead of the classic "Hello World" (UEFI console printing is only available before exiting Boot Services), so perhaps there could also be some work done on a framebuffer driver that is aware of fonts (like Linux uses PSF for its tty's)
- also why do we have multiple GDT's for each lcpu? I believe it is better to have only one GDT with multiple TSS entries.

MR: Let's focus for now on VM's only
I will try to publish the generic boot information PR, hopefully that will help

DP: managed to compile Unikraft as a PIE
- checked with GCC 7.0+ (on 7.0 it compiles but not as a PIE, on 8.0+ it is fine)
- O_MAGIC breaks compatibility
- For Xen and KVM I did not manage to get it to work, only for linuxu

MR: Marco will publish a PR that remove O_MAGIC on KVM




## :wrench: TODOs and Decisions

SM: Look into improving our ACPI subsystem and add support for ACPI 2.0
SM: Look into MR's PR for generic boot info and re-write the loader with that

DP: Take a look into the PR from Marco removing the omagic flag for KVM and try to build a KVM-enabled PIE image.
DP: Look into the boot PR to see if it would fit the requirements for chainloading and ASLR.


------------------------------------------------------------------------------
15.02.2023t[]
MR: Apply the relocations in the boot protocol specific entry point
SK: (idea) Build a minimal image to randomly load and apply relocations to the microlibraries separately
MR: Strip all devices and do a custom minimal boot for that, that is, supposedly, the chain-loader - will manage the boot protocol conversion to struct bootinfo and forwards that to the actual Unikraft app image


TODO:
SM: Figure out why the .rela/.symtab sections are getting stripped off
SM: Finish the self-modifying code stuff
DP: Try to make a minimal boot image - replace ukboot with smth of your own - see how small you can get Unikraft