Re: [edk2-devel] [PATCH v2 0/6] ArmVirtPkg: Increase PlatformCI coverage

["Ard Biesheuvel" <ardb@kernel.org>]

On Wed, 25 Jan 2023 at 10:42, Gerd Hoffmann <kraxel@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 <kraxel@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-a75484eccc35@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.