On Wed, 25 Jan 2023 at 10:42, Gerd Hoffmann <kra...@redhat.com> wrote: > > On Tue, Jan 24, 2023 at 05:34:11PM +0100, Ard Biesheuvel wrote: > > We recently experienced some build breakage in one of the ArmVirtPkg > > platforms that is not covered by PlatformCI, in the PrePi component > > which replaces the entire PEI stage. This component is now also being > > used in TDVF, and so any modifications to it may regress the existing > > users. > > > > So add build and boot tests of ArmVirtQemuKernel (which is a version of > > ArmVirtQemu which can be loaded as a loadable image instead of executing > > from [emulated] NOR flash), and a build test of ArmVirtKvmTool, which is > > also based on PrePi and runs under the kvmtool VMM. To further increase > > coverage, enable secure boot, TPM support and HTTP(s) boot support when > > building ArmVirtQemu for AARCH64. > > Acked-by: Gerd Hoffmann <kra...@redhat.com> >
Thanks. > As you mention secure boot: As far I know current state of affairs is > that nothing protects efi variable flash on ArmVirt, so secure boot > isn't actually secure because the OS can easily manipulate 'db' etc. > True. There is a way around this, though: we could emulate secure EL0 using KVM and a separate EL1 context that implements the Secure Partition interface that standalone MM supports. That way, we would be able to run the entire MM based variable runtime stack, similar to how SMM emulation is implemented (or so I am told) None of this has been implemented or prototyped, though, and nobody seems to want it badly enough to bother. > State of affairs on physical hardware (at least on Qualcomm SoCs) seems > to be that there is some service running in the Trusted Zone secure > world which manages (and controls access to) EFI variables. See > > https://lore.kernel.org/lkml/eaa455ed-2dd2-a33f-6420-a75484ecc...@gmail.com/t/ > Yes. There are other efforts underway that are OP-TEE based, i.e., RPMB partition owned by the secure firmware, and a supplicant in Linux user space that marshalls requests between the Linux kernel and the secure firmware. And yes, this is a terrible design, and the qcom approach seems slightly better. On bare metal hardware, you can generally just use the standalone MM based driver stack. I implemented this for SynQuacer/Developerbox, when building its firmware with SECURE_BOOT_ENABLE from edk2-platforms. However, this approach only works if the secure world can have complete ownership of the storage. On QCOM devices or other eMMC/UFS based devices, there is only a single controller which must be owned by the Linux kernel, and so any access by the firmware needs to be routed via some component that performs the arbitration. In the OP-TEE case, this is the supplicant in user space. in the QCOM case, I imagine there may be some code in the magic hypervisor that takes care of this. > Do you happen to know whenever any of this is available as open source, > be it the secure world code or the EFI drivers talking to it? Is there > some kind of standard for this or does every vendor brew its own? > There is no standard for this, as far as I know, even though the problem was well understood 8+ years ago. As far as I know, the QCOM approach is specific to snapdragon EFI platforms, and similar hacks are needed in Windows for the EFI runtime stack to be swapped out and the special driver swapped into the consumers of the EFI variables. The secure world calling convention is standardized, though, and IIRC, there were some suggestions regarding reuse of the EFI variable emulation function IDs. But in general, it is very hard to get QCOM engineers to care about any of this - even if Lenovo are now invested in running Linux on the ARM ThinkPads, they still have to work around the buggy firmware that they get from QCOM and AMI, and getting it fixed appears to be very hard. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#99020): https://edk2.groups.io/g/devel/message/99020 Mute This Topic: https://groups.io/mt/96501363/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
