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 <f...@shokubai.tech> > Sent: 09 February 2023 10:48 > To: Ard Biesheuvel <a...@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 <f...@shokubai.tech > <mailto:f...@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&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-le...@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. _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
