On Thu, 9 Feb 2023 at 10:48, ff ff@shokubai.tech wrote:
Hi
Anyone knows what is the status of standardizing firmware handoff (when starting BL33) ? Here is a reference to the topic: https://github.com/FirmwareHandoff/firmware_handoff
I would be interested in both standard text and standard implementation in TFA.
The context is portability of type-1 hypervisors that need to be fully in control of security and thus execute BL33 in an ad hoc "VM". The rationale is to isolate everything that deals with devices or IO (at its core, a hypervisor deals only with CPU, RAM, MMU, SMMU, GIC).
Cheers
FF
PS: To explore how easy it is to boot a hypervisor with either booti, bootefi or BL33 I published a Rust tool (barekit) that can do precisely that (and much more as it can be used to create BL32 or even a Rust based FF-A implementation): https://www.linkedin.com/posts/fozog_github-fozogbarekit-rust-base-code-to-a... https://github.com/fozog/barekit
Interesting! I implemented something similar last year for QEM/mach-virt
https://github.com/ardbiesheuvel/efilite
Doing EFI boot like this in a VM is actually faster than without any firmware whatsoever, given that there is no need to play with the MMU and caches or clean the entire kernel image to the PoC. (In my testing, EFI boot takes 3.5ms whereas bare metal boot takes 4.5 ms from vCPU reset to reaching start_kernel() in Linux)
The main reason is precisely the one you mention: hypervisor folks ask for 'direct kernel boot' because it is faster but still want to pretend while in the kernel that we did EFI boot, for ACPI tables, SMBIOS, TPM support etc, but all this mucking about with uncached memory with the MMU off is both slow and unsafe, especially on recent micro-architectures.