Add EFI stub support
#909
Closed
Add EFI stub support
#909
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced May 25, 2023
unikraft-bot
added
arch/arm
arch/arm64
arch/x86_64
area/arch
If `CONFIG_EFI_STUB` is enabled, add to the build system the fake PE header, the architecture generic EFI stub, and the x86 specific post-EFI stub that applies finishing touches to the platform initialization. Signed-off-by: Sergiu Moga <sergiu.moga@protonmail.com>
Implements the small ARM specific UEFI entry point which will call the early self relocator, and jump to the architecture generic EFI stub. Signed-off-by: Sergiu Moga <sergiu.moga@protonmail.com>
Implement a stub that comes after the architecture generic EFI stub calls the routine that exits `Boot Services`. This is supposed to finish the architecture specific setupin order to be able to have a Unikraft valid initial environment state before `_libkvmplat_start` is execited. Thus, the interrupt flags are masked, the data cache is invalidated in the range of this image's instance and then default, warm reset values are placed into the system registers that EFI would have otherwise left modified. Signed-off-by: Sergiu Moga <sergiu.moga@protonmail.com>
If `CONFIG_EFI_STUB` is enabled, add to the build system the ARM UEFI entry stub and the ARM specific post-EFI stub that applies finishing touches to the platform initialization. Add a configuration entry `KVM_BOOT_QEMU_VIRT` to explicitly indicate that we are booting from the default `QEMU virt` environment. This will help us differentiate between UEFI and non-UEFI ARM builds. Signed-off-by: Sergiu Moga <sergiu.moga@protonmail.com>
Preferably, a UEFI system is also an ACPI system and thus these functionalities should be implemented through ACPI methods. But for now, make use of UEFI's Runtime Services for resetting the system, since they are more reliable than what we have at the moment. Signed-off-by: Sergiu Moga <sergiu.moga@protonmail.com>
Add `Trusted Computing Group`'s `Reset Attack Mitigation` mechanism. Whenever a machine shuts down or reboots, due to lack of electric charge, the contents of RAM may dissipate after a short amount of time. However this may be enough for an attacker to quickly boot again into a custom program and dump memory contents. Thus, by using this, the OS instructs POST BIOS to overwrite memory contents before continuing to boot into the rest of the BIOS code. Since this is not really implemented in `OVMF`'s `NVRAM` variables we disable this by default. Signed-off-by: Sergiu Moga <sergiu.moga@protonmail.com>
|
❗ Checkpatch failed Beep boop! I ran Unikraft's
Truncated logs starting from first error 9efe743: View complete logs | Learn more about Unikraft's coding style and contribution guidelines. |
michpappas
approved these changes
Aug 11, 2023
razvand
approved these changes
Aug 11, 2023
unikraft-bot
pushed a commit
that referenced
this pull request
Aug 11, 2023
Add a description and proper dependencies for the `KVM_BOOT_PROTO_MULTIBOOT` configuration entry. Since `Firecracker` only supports the `Linux` 64-bit boot protocol and `Multiboot` is x86 specific (not taking into consideration the `Multiboot` ported to `ARM` for `Xen`), make the configuration entry reflect that. Signed-off-by: Sergiu Moga <sergiu.moga@protonmail.com> Reviewed-by: Michalis Pappas <michalis@unikraft.io> Approved-by: Razvan Deaconescu <razvand@unikraft.io> Tested-by: Unikraft CI <monkey@unikraft.io> GitHub-Closes: #909
unikraft-bot
pushed a commit
that referenced
this pull request
Aug 11, 2023
Add a description and proper dependencies for the `KVM_BOOT_PROTO_LXBOOT` configuration entry. Since `Firecracker` only supports the `Linux` 64-bit boot protocol and we do not yet support booting through it on `QEMU`, make the dependencies reflect that. Signed-off-by: Sergiu Moga <sergiu.moga@protonmail.com> Reviewed-by: Michalis Pappas <michalis@unikraft.io> Approved-by: Razvan Deaconescu <razvand@unikraft.io> Tested-by: Unikraft CI <monkey@unikraft.io> GitHub-Closes: #909
unikraft-bot
pushed a commit
that referenced
this pull request
Aug 11, 2023
Add a configuration option to build the Unikernel as a valid, loadable UEFI application. Make it depend on `ACPI` and, obviously, on not having `PLAT_LINUXU` enabled. Furthermore, remove default selection of the Multiboot boot protocol if QEMU VMM is selected, now that a QEMU image can also be an EFI image. Signed-off-by: Sergiu Moga <sergiu.moga@protonmail.com> Reviewed-by: Michalis Pappas <michalis@unikraft.io> Approved-by: Razvan Deaconescu <razvand@unikraft.io> Tested-by: Unikraft CI <monkey@unikraft.io> GitHub-Closes: #909
unikraft-bot
pushed a commit
that referenced
this pull request
Aug 11, 2023
Add an architecture generic EFI stub that sets up a `struct ukplat_bootinfo`'s memory region descriptors, `bootloader` and `bootprotocol` fields. Furthermore, the memory region descriptors corresponding to the UEFI `Runtime Services` are gathered separately, through UEFI's `Memory Attribute Table`, since they have to be treated differently, in order for the `Runtime Services` to be used properly after `exit_boot_services`. At the end, the stub calls `uk_efi_jmp_to_kern` which each architecture is supposed to independently implement the remaining setup for its platform. Signed-off-by: Sergiu Moga <sergiu.moga@protonmail.com> Reviewed-by: Michalis Pappas <michalis@unikraft.io> Approved-by: Razvan Deaconescu <razvand@unikraft.io> Tested-by: Unikraft CI <monkey@unikraft.io> GitHub-Closes: #909
unikraft-bot
pushed a commit
that referenced
this pull request
Aug 11, 2023
Define the minimum subset of EFI definitions required to be able to do file I/O in an UEFI environment. Signed-off-by: Sergiu Moga <sergiu.moga@protonmail.com> Reviewed-by: Michalis Pappas <michalis@unikraft.io> Approved-by: Razvan Deaconescu <razvand@unikraft.io> Tested-by: Unikraft CI <monkey@unikraft.io> GitHub-Closes: #909
unikraft-bot
pushed a commit
that referenced
this pull request
Aug 11, 2023
Implement support to pass command-line arguments through Unikraft's `struct ukplat_bootinfo`. This can be done in two ways: 1. Through the UEFI Shell when launching the image or through `qemu`'s `-append` option. 2. Through the filesystem of the same partition (the EFI System Partition) that the image was launched from. The loader will look for a file with the name configured through the `UK_EFI_STUB_CMDLINE_FNAME` in the `\EFI\BOOT' directory. The first way, if applicable, takes priority over the second. Signed-off-by: Sergiu Moga <sergiu.moga@protonmail.com> Reviewed-by: Michalis Pappas <michalis@unikraft.io> Approved-by: Razvan Deaconescu <razvand@unikraft.io> Tested-by: Unikraft CI <monkey@unikraft.io> GitHub-Closes: #909
unikraft-bot
pushed a commit
that referenced
this pull request
Aug 11, 2023
This enables the EFI stub to load an initial RAM disk file from the same filesystem that the Unikraft image was loaded from (the EFI System Partition) and register it as a `Memory Region Descriptor`. The name of the `initrd` file is given through the `CONFIG_UK_EFI_STUB_INITRD_FNAME` configuration entry and it tells the loader the name of the file to load from the `\EFI\BOOT` directory of the EFI System Partition. Signed-off-by: Sergiu Moga <sergiu.moga@protonmail.com> Reviewed-by: Michalis Pappas <michalis@unikraft.io> Approved-by: Razvan Deaconescu <razvand@unikraft.io> Tested-by: Unikraft CI <monkey@unikraft.io> GitHub-Closes: #909
unikraft-bot
pushed a commit
that referenced
this pull request
Aug 11, 2023
This enables the EFI stub to load a Devicetree Blob file from the same filesystem that the Unikraft image was loaded from (the EFI System Partition) and register it as a `Memory Region Descriptor`. The name of the `dtb` file is given through the `CONFIG_UK_EFI_STUB_DTB_FNAME` configuration entry and it tells the loader the name of the file to load from the `\EFI\BOOT` directory of the EFI System Partition. Signed-off-by: Sergiu Moga <sergiu.moga@protonmail.com> Reviewed-by: Michalis Pappas <michalis@unikraft.io> Approved-by: Razvan Deaconescu <razvand@unikraft.io> Tested-by: Unikraft CI <monkey@unikraft.io> GitHub-Closes: #909
unikraft-bot
pushed a commit
that referenced
this pull request
Aug 11, 2023
This script allows patching of the architecture specific fake PE headers. It only fills in the fields that UEFI firmware looks for when validating and loading the image. Specifically, it does the following: - Write MS-DOS signature in the first bytes of the binary - Write at the standard MS-DOS file offset `0x3c` the offset to the beginning in file of the fake PE header - Append the original ELF file that also contains the PE header - Fill in the following fields of the Optional Header: SizeOfCode, AddressOfEntryPoint, BaseOfCode, SizeOfImage - Fill in the dummy PE sections, as PE, unlike ELF, is loaded by sections: - dummy .reloc section pointing to itsel with all fields zeroed out except the VirtualAddress and PointerToRawData fields which point to the section itself, to fool UEFI into thinking this is a valid relocation. - All PT_LOAD ELF Program Headers will be encapsulated into PE sections with all permissions enabled (RWX) For these sections, only the following fields are required to be filed in: VirtualSize, VirtualAddress, SizeOfRawData, PointerToRawData. Thus, the script fills in the bare-minimum fields, according to EDKII, the most complete and official UEFI implementation, that are required by an UEFI application's PE header to be considered valid and loadable. Signed-off-by: Sergiu Moga <sergiu.moga@protonmail.com> Reviewed-by: Michalis Pappas <michalis@unikraft.io> Approved-by: Razvan Deaconescu <razvand@unikraft.io> Tested-by: Unikraft CI <monkey@unikraft.io> GitHub-Closes: #909
unikraft-bot
pushed a commit
that referenced
this pull request
Aug 11, 2023
Implements the small x86 specific UEFI entry point which will call the early self relocator, adjust the initially unaligned stack and finally jump to the architecture generic EFI stub. Signed-off-by: Sergiu Moga <sergiu.moga@protonmail.com> Reviewed-by: Michalis Pappas <michalis@unikraft.io> Approved-by: Razvan Deaconescu <razvand@unikraft.io> Tested-by: Unikraft CI <monkey@unikraft.io> GitHub-Closes: #909
unikraft-bot
pushed a commit
that referenced
this pull request
Aug 11, 2023
Implement a stub that comes after the architecture generic EFI stub calls the routine that exits `Boot Services`. This is supposed to finish the architecture specific setupin order to be able to have a Unikraft valid initial environment state before `_ukplat_entry` is execited. Thus, begin by disabling the `Interrupt Flag`, updating the root of the page tables with our in-image static page tables, unmask the legacy `8259 PIC`, since, at this point, we do not have `I/O APIC` support, disable the `LAPIC Timer` initially setup by `UEFI`, set the legacy shared PCI IRQ's as level triggered since UEFI does not do it for us (unless we boot in `CSM`) and we do not, at this moment have a proper IRQ subsystem and, finally, jump to `lcpu_start64` with the entry function as `_ukplat_entry` and a statically allocated page-sized stack. Signed-off-by: Sergiu Moga <sergiu.moga@protonmail.com> Reviewed-by: Michalis Pappas <michalis@unikraft.io> Approved-by: Razvan Deaconescu <razvand@unikraft.io> Tested-by: Unikraft CI <monkey@unikraft.io> GitHub-Closes: #909
unikraft-bot
pushed a commit
that referenced
this pull request
Aug 11, 2023
If `CONFIG_EFI_STUB` is enabled, add to the build system the fake PE header, the architecture generic EFI stub, and the x86 specific post-EFI stub that applies finishing touches to the platform initialization. Signed-off-by: Sergiu Moga <sergiu.moga@protonmail.com> Reviewed-by: Michalis Pappas <michalis@unikraft.io> Approved-by: Razvan Deaconescu <razvand@unikraft.io> Tested-by: Unikraft CI <monkey@unikraft.io> GitHub-Closes: #909
unikraft-bot
pushed a commit
that referenced
this pull request
Aug 11, 2023
Implements the small ARM specific UEFI entry point which will call the early self relocator, and jump to the architecture generic EFI stub. Signed-off-by: Sergiu Moga <sergiu.moga@protonmail.com> Reviewed-by: Michalis Pappas <michalis@unikraft.io> Approved-by: Razvan Deaconescu <razvand@unikraft.io> Tested-by: Unikraft CI <monkey@unikraft.io> GitHub-Closes: #909
unikraft-bot
pushed a commit
that referenced
this pull request
Aug 11, 2023
Implement a stub that comes after the architecture generic EFI stub calls the routine that exits `Boot Services`. This is supposed to finish the architecture specific setupin order to be able to have a Unikraft valid initial environment state before `_libkvmplat_start` is execited. Thus, the interrupt flags are masked, the data cache is invalidated in the range of this image's instance and then default, warm reset values are placed into the system registers that EFI would have otherwise left modified. Signed-off-by: Sergiu Moga <sergiu.moga@protonmail.com> Reviewed-by: Michalis Pappas <michalis@unikraft.io> Approved-by: Razvan Deaconescu <razvand@unikraft.io> Tested-by: Unikraft CI <monkey@unikraft.io> GitHub-Closes: #909
unikraft-bot
pushed a commit
that referenced
this pull request
Aug 11, 2023
If `CONFIG_EFI_STUB` is enabled, add to the build system the ARM UEFI entry stub and the ARM specific post-EFI stub that applies finishing touches to the platform initialization. Add a configuration entry `KVM_BOOT_QEMU_VIRT` to explicitly indicate that we are booting from the default `QEMU virt` environment. This will help us differentiate between UEFI and non-UEFI ARM builds. Signed-off-by: Sergiu Moga <sergiu.moga@protonmail.com> Reviewed-by: Michalis Pappas <michalis@unikraft.io> Approved-by: Razvan Deaconescu <razvand@unikraft.io> Tested-by: Unikraft CI <monkey@unikraft.io> GitHub-Closes: #909
unikraft-bot
pushed a commit
that referenced
this pull request
Aug 11, 2023
Preferably, a UEFI system is also an ACPI system and thus these functionalities should be implemented through ACPI methods. But for now, make use of UEFI's Runtime Services for resetting the system, since they are more reliable than what we have at the moment. Signed-off-by: Sergiu Moga <sergiu.moga@protonmail.com> Reviewed-by: Michalis Pappas <michalis@unikraft.io> Approved-by: Razvan Deaconescu <razvand@unikraft.io> Tested-by: Unikraft CI <monkey@unikraft.io> GitHub-Closes: #909
unikraft-bot
pushed a commit
that referenced
this pull request
Aug 11, 2023
Add `Trusted Computing Group`'s `Reset Attack Mitigation` mechanism. Whenever a machine shuts down or reboots, due to lack of electric charge, the contents of RAM may dissipate after a short amount of time. However this may be enough for an attacker to quickly boot again into a custom program and dump memory contents. Thus, by using this, the OS instructs POST BIOS to overwrite memory contents before continuing to boot into the rest of the BIOS code. Since this is not really implemented in `OVMF`'s `NVRAM` variables we disable this by default. Signed-off-by: Sergiu Moga <sergiu.moga@protonmail.com> Reviewed-by: Michalis Pappas <michalis@unikraft.io> Approved-by: Razvan Deaconescu <razvand@unikraft.io> Tested-by: Unikraft CI <monkey@unikraft.io> GitHub-Closes: #909
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Prerequisite checklist
checkpatch.plon your commit series before opening this PR;Base target
x86_64,arm64kvmAdditional configuration
Description of changes
Add support for
EFIstub, so that we can boot from anEFIenvironment without a bootloader as well as have access toEFIstructures. Furthermore, add corresponding configurations, as well as aQEMU Virtspecific configuration to distinguish, in the case ofAarch64between the two booting methods.This PR depends on #907 #772 #848 and #908, therefore it includes them.
NOTE
This is part of a larger set of Pull Requests. To make things easier and to ensure that things build as expected, it is recommended that testing is done based on #912, which includes everything. The splitting has been done to ease the review process.