Re: [edk2-devel] [PATCH 1/1] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: add security warning

["Yao, Jiewen" <jiewen.yao@intel.com>]

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Gerd
> Hoffmann
> Sent: Monday, December 19, 2022 4:53 PM
> To: Yao, Jiewen <jiewen.yao@intel.com>
> Cc: devel@edk2.groups.io; Justen, Jordan L <jordan.l.justen@intel.com>; Ard
> Biesheuvel <ardb+tianocore@kernel.org>; Oliver Steffen
> <osteffen@redhat.com>; Pawel Polawski <ppolawsk@redhat.com>
> Subject: Re: [edk2-devel] [PATCH 1/1]
> OvmfPkg/QemuFlashFvbServicesRuntimeDxe: add security warning
> 
> On Sat, Dec 17, 2022 at 03:10:25AM +0000, Yao, Jiewen wrote:
> > Hi Gerd
> > I would like to clarify a couple of things:
> >
> > 1) "Using these builds with writable flash is not secure."
> >
> > Whenever we say "secure" or "not secure", we need align the threat model
> at first.
> > What component is trusted? Which is not trusted? Who is adversary? With
> which capability? Under which attack scenario?
> 
> Well, the OS can write directly to flash, bypassing the firmware.  It
> can update secure boot efi variables without the firmware enforcing the
> usual restrictions (KEK signature being required for db/dbx updates
> etc).

[Jiewen] I would say: It is the typical use case. But not the only use case.
Typically, the BIOS shall configure the flash to prevent OS directly to flash, with SMM in this case. I do not disagree.
That feature fully really on the hardware (on a real platform) or VMM (on a virtual platform).

However, in confidential computing use case, the flash is controlled by the untrusted entity - VMM.
It is *impossible* to lock down the flash, even with SMM enabled. That is because the VMM is also emulating SMM.
To rely on an untrusted entity (VMM) to provide security protection (e.g. SMM) is meaningless.

The best way we can do is to enable measured boot together with secure boot.
As such, no matter how VMM or untrusted OS modifies the SecureBoot variable, it will be recorded by measured boot mechanism and detected in attestation later.
In summary, Secure boot in CC cannot resist the policy override, but Measured boot in CC will detect such override, and mitigate such threat.
That is fine, because it is meaningless to enable CC without measured boot.


> 
> > If we are going to say something like that, we need a full description. Just
> saying: "not secure" is not enough.
> 
> We simply don't get the protection secure boot is supposed to provide.
> 
> > 3) What is definition of "stateless secure boot configuration" ?
> > What does you mean "stateless"? Do you mean "SMM_REQUIRE=FALSE" or
> something else?
> 
> "stateless" means we don't have persistent efi variables.
> 
> > Then why not call it as simple as "secure boot without SMM" ?
> > I don't understand how "SMM_REQUIRE=FALSE" will contribute "stateless".
> 
> Secure boot in OVMF in 2022-08 + older requires flash memory as efi
> variables storage and SMM mode support to enforce all efi variable
> updates being handled by the firmware.
> 
> Starting with 2022-11 it is also possible to use secure boot without SNN
> mode and with the emulated variable store in RAM.  Min added that for
> IntelTdx.  The firmware can't enforce variable update rules in that
> case, but that is compensated by initializing the emulated variable
> store content with a pristine copy from ROM on each boot.  So the OS can
> tamper with the efi variables, but it can't attack the system that way
> because any changes done are wiped on reset, before the firmware looks
> at those variables again when checking efi binary signatures.  This also
> means any regular efi variable updates (like setting Boot* variables on
> install) are wiped on reset too.  This is where the term "stateless"
> comes from.
> 
> I don't see how "secure boot without SMM" is easier to understand than
> "stateless".

[Jiewen] "stateless" is a new term introduced in this patch. Not in UEFI spec, nor in EDKII.
If you want to use it, please define it clearly. At least, I don't understand.

>  It also is x64-specific.

[Jiewen] I don't understand why it is x64-specific.

>  But the idea to give up variable
> persistence to get secure boot support without processor support for a
> separate privilege level can work on other platforms too.  ArmVirt for
> example could get secure boot support that way without depending on
> TrustZone.



> 
> > 4) What is the purpose of "Log a warning" ?
> > Is that to tell people, DON'T DO IT?
> 
> Yes.

[Jiewen] Disagree. It can work together with measured boot in CC use case.
If you really really want to add something, you should also check if CC is enabled.

> 
> Maybe it's better to refuse to boot in that case, 
[Jiewen] You may refuse in non-CC case. But it is legal in CC case.

> a warning in
> a logfile is easily missed.
[Jiewen] Yes, that is why I don't like WARNING in log.
I think we had better describe it in readme.

> 
> In 2022-08 and older the world is relatively simple.  We have
> three possible build configurations
> 
>   (1) SECURE_BOOT_ENABLE=FALSE SMM_REQUIRE=FALSE
>       Build without secure boot support.
> 
>   (2) SECURE_BOOT_ENABLE=TRUE SMM_REQUIRE=TRUE
>       Build with secure boot support, secure.
> 
>   (3) SECURE_BOOT_ENABLE=TRUE SMM_REQUIRE=FALSE
>       Build with secure boot support, not secure.
> 
> Linux Distributions typically provide builds for (1) and (2),
> so (3) existing isn't much of a problem in practice because
> people typically don't compile edk2 by themself.

[Jiewen] Above description is based upon assumption that SMM is trusted. It is TRUE in non-CC use case.
However, the assumption is wrong in CC use case, because VMM is untrusted and SMM might colluder.
The VMM may fake the flash lock in SMM, and allow OS to bypass the flash protection.
Following your logic, I would say: even with SMM, it is still not secure.

The only way to make it secure is to add measurement and attestation in CC scenario.

> 
> In 2022-11 the (3) case is splitted into two:
> 
>   (3a) build being used with ROM (or r/o flash):
>        -> this is the new "stateless secure boot" mode.
>   (3b) build being used with writable flash:
>        -> insecure configuration.

[Jiewen] If you want to use term "stateless", please define it.

Also, I think we can separate the non-CC and CC use case, because the TCB is totally different.


> 
> Now the same build can be secure or not depending on
> runtime configuration.  So this patch tries to catch
> (3b) with a runtime check.
> 
> take care,
>   Gerd
> 
> 
> 
> 
>