Hi, > > 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.
In the confidential computing use case there is no flash in the first place. At least for the cases where the processor not the VMM manages guest memory (i.e SEV-SNP and TDX) the qemu patches I've seen so far handle it that way. That configuration goes into the (3a) bucket. No flash (and no other place to store any state which survives reboot -> stateless). Guest starts with a fixed varstore coming from the firmware rom. > The best way we can do is to enable measured boot together with secure > boot. measured boot can be used to attest the VM actually runs the configuration it is supposed to run. That is independent from secure boot, even though it is possible to combine the two and in that case also measure secure boot configuration. Works in both confidential and non-confidential VMs. > 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 you don't want trust the VMM, then yes, measured boot is required to make sure the VMM actually started the VM the way it is supposed to be started. For attacks against the guest OS there isn't that much of a difference between CC and non-CC guests. I think in both cases the (hacked) guest OS can't change the secure boot configuration. Even in case the guest OS manages to modify the varstore the firmware will never use the modification. For non-confidential guests the firmware will initialize the varstore with the pristine copy from firmware rom on reset. For CC guests there is no reset in the first place (reset requires the VMM changing guest state), you can only kill and restart the VM, which will likewise start with pristine varstore state. > > 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. "stateless" == no persistent variable store, i.e. no flash. > > It also is x64-specific. > > [Jiewen] I don't understand why it is x64-specific. SMM is x86-specific, that's why I don't like the term "secure boot without SMM". > > > 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. See above. CC runs without flash anyway so no warning in that case. > > 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. Yes. > 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. Not sure what you are trying to tell me. In CC mode SMM is not supported in the first place, so your argument doesn't make sense to me. > > 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. "stateless" == no persistent variable store, i.e. no flash. > Also, I think we can separate the non-CC and CC use case, because the TCB is > totally different. CC goes into (3a). take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#97615): https://edk2.groups.io/g/devel/message/97615 Mute This Topic: https://groups.io/mt/95707152/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
