(my mail client doesn't ident, sorry for the mess)

On Thu, 9 Feb 2023 at 10:48, ff <ff@shokubai.tech mailto: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 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://www.linkedin.com/posts/fozog_github-fozogbarekit-rust-base-code-to-activity-7026199056116822017-7_l8?utm_source=share&utm_medium=member_desktop https://github.com/fozog/barekit https://github.com/fozog/barekit

Interesting! I implemented something similar last year for QEM/mach-virt

https://github.com/ardbiesheuvel/efilite 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.

<ff_response> That's fantastic. Efilite is the perfect companion: - U-Boot is needed for special hardware initialization (Serdes...) at boot time - Efilite is really for VM startup.

BTW, as you are associated with gnuefi: dealing with relocs has been a challenge __ I now understand the .bss issue with GNUEFI: it is a "virtual" section hidden in .data. The problem is the Rust linker (may be others) do not updated some headers that would help know it's size. And I discovered that .bss has to be initialized to 0... more details in coff_stager.rs. </ff_response>

Thanks a lot Jose.

________________________________ De : Jose Marinho Jose.Marinho@arm.com Envoyé : jeudi, février 9, 2023 20:43 À : ff ff@shokubai.tech; Ard Biesheuvel ardb@kernel.org Cc : boot-architecture@lists.linaro.org boot-architecture@lists.linaro.org Objet : RE: Firmware handoff status

Hi François, Ard,

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

This spec is still undergoing some final discussions (in the open PR). Once this PR is merged, we should be close to an initial release of the spec.

The enablement in the adopting codebases is expected after the initial release of the spec.

Regards, Jose

-----Original Message----- From: ff ff@shokubai.tech Sent: 09 February 2023 10:48 To: Ard Biesheuvel ardb@kernel.org Cc: boot-architecture@lists.linaro.org Subject: Re: Firmware handoff status

(my mail client doesn't ident, sorry for the mess)

On Thu, 9 Feb 2023 at 10:48, ff <ff@shokubai.tech mailto: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 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-cod e-to-activity-7026199056116822017-

7_l8?utm_source=share&utm_medium=mem

...

ber_desktop <https://www.linkedin.com/posts/fozog_github-fozogbarekit-rust-base-co de-to-activity-7026199056116822017-

7_l8?utm_source=share&amp;utm_mediu

...

m=member_desktop> https://github.com/fozog/barekit https://github.com/fozog/barekit

Interesting! I implemented something similar last year for QEM/mach-virt

https://github.com/ardbiesheuvel/efilite 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.

<ff_response> That's fantastic. Efilite is the perfect companion: - U-Boot is needed for special hardware initialization (Serdes...) at boot time - Efilite is really for VM startup.

BTW, as you are associated with gnuefi: dealing with relocs has been a challenge __ I now understand the .bss issue with GNUEFI: it is a "virtual" section hidden in .data. The problem is the Rust linker (may be others) do not updated some headers that would help know it's size. And I discovered that .bss has to be initialized to 0... more details in coff_stager.rs.

</ff_response>

---

boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.