On Wed, Mar 26, 2025 at 2:53 PM Gerd Hoffman <kra...@redhat.com> wrote: > > Hi, > > > > > 2) The security posture of the system may be different between 2 > > > > validly > > > > signed images. Think of Daniel's example of verbose kernel output. > > > > Maybe I > > > > consider verbose kernel output already inacceptable, while RH thinks > > > > it's an > > > > ok posture to have. The user needs to have the chance to differentiate > > > > between a system booted with or without verbose kernel output. > > > You easily get that by looking at the vTPM measurements. So not sure > > > what you are asking for, do you want be able to also do that without a > > > vTPM? > > > > All of this should work without vTPMs. Why add complexity when you don't > > need it? The industry is already struggling to deal with TPMs alone. There > > are way too many potential holes in a solution where you first have to > > reason about the integrity of your TPM before you can trust it. All of the > > vTPM in SEV-SNP talk is a house of cards I'm happy to push (blow to keep the > > analogy?) against as hard as I can. > > TPM is the only thing we have outside of confidential computing. So > naturally there is alot of code and infrastructure for that despite the > complexity of TPMs. So having vTPMs in CVMs allows to reuse that > infrastructure and it totally makes sense to support that. > > That doesn't imply this is the only option to handle things. Having the > option to tie everything to the launch measurement makes sense too. > Fair point. > > > > > Ukify.py then generates the blob along with the FUKI. > > > Doesn't fly from a distro point of view. The UKI is signed, so RH ships > > > that and the customer can't modify it to update the blob, say with some > > > additional hashes for 'db'. > > > > I don't follow. Is RH going to ship a UKI or a FUKI? > > How should I answer that one while we are still discussing the design? > > > And if RH ships the UKI, ukify could still take a UKI as input and > > generate a FUKI based on it, no? > > Of course you can, but it'll break the RH signature. > > > During that process, it would generate a db which gets put at a fixed > > location in RAM so the (RH provided) firmware picks it up and validates the > > UKI it loads is exactly that one UKI. > > Well. If you want put the db into the igvm and the igvm into the uki > you've got a chicken-and-egg problem. Moving the firmware from the main > UKI to UKI add-on would solve that.
Why is embedding a public key that will sign the IGVM in the IGVM a chicken-and-egg problem? It's only that if db were a list of acceptable measurements, which it isn't. I'm not sure why relying on secure boot makes any sense for confidential computing. I still think that tearing down the VM context and rebuilding it is more secure, given the need for an honest launch measurement/MRTD. For Cloud Computing, which is the only place that FUKI makes sense as a delivery mechanism, it's more important to rely on attestation policy that has more awareness of the current security posture of measurements. Secure boot conflates authentic with secure. With a supply chain distribution standard like CoRIM, we can ensure that individual binaries have not only authentic measurements, but also security version numbers (SVNs) that can be compared against a shorter-lived endorsement of what is the most up-to-date and which CVEs are known for lower SVNs. Revocation is just not a real thing that works. Short-lived policy is. Policy services can be updated more simply than the UEFI variables of every node in the fleet. > > > We can extend that with an additional signature flow, where the ukify > > generated db contains a signature for the UKI instead. > > certificate, not signature. But, yes, that would work. > > > But I would generally advise against optimizing for certificate based > > flows until revocation is sorted out. > > Well, if at the end of the day we'll go pass on a 'db' both signatures > and hashes can be used. > > > > Effectively we need something roughly equivalent to shim's MokList. The > > > distro ships a default configuration (like the cert compiled into the > > > shim binary) which works fine for most people. For IGVM that would be a > > > default efi variable store compiled into the firmware binary. > > > > This only makes sense in a world where RH ships an SVSM and that's all you > > want to attest. But that's a different flow from what we describe here. To > > actually get workload attestation, you need to include your rootfs in the > > attestation. And the only entity that can do that is the end customer. And > > they will typically do that through something like dm-verity or fs-verity > > and a hash provided on the kernel command line. > > So you'll have the RH UKI + customer add-on with the kernel command > line. And you need a customized igvm containing a 'db' which will allow > both, either via certificate+signature or via hash, whatever you prefer. > > > > Does it make sense to simply move the firmware update sections from the > > > main UKI to an add-on? That would allow customers to easily use their > > > own if they wish, without breaking the RH signature on the UKI. > > > > I'm still not convinced "RH signature" is a useful marker at execution time > > of confidential workloads. > > If the customer agrees they can go for hashes. If not they should be > able to use certificates. So patching the RH shipped UKI is not an > option. > > > > RH default igvm/add-on would simply have empty 'db' and 'dbx' pages. > > > > > > Looks workable to me. > > > > I would personally consider the "RH binary adds RH signature into binary by > > default" a backdoor, but that's you call :). > > It's surely possible to ship two variants, one with the RH certificates > and one blank, so customers can pick the latter if they want allow > specific hashes only. > > > I agree with the plan to amend the IGVM spec with the UEFI variable update > > page. I don't think it should be "db" and "dbx" pages. It should be a more > > generic. In fact, why not make it a loader UEFI (PE) binary? > > Not convinced a PE binary is a good idea. Adds one more indirection for > no obvious gain. > > > > > All unauthenticated data, such as locations of the UKI and its add-ons > > > > gets > > > > passed as parameter to the firmware IGVM. > > > i.e. have a IGVM parameter for opaque_addr + opaque_size instead of > > > placing this in the vmfwupdate struct? > > > > It would be a pretty natural fit for it, no? > > Absolutely. Just wanted to make sure we are talking about the same thing. > > take care, > Gerd > > -- -Dionna Glaze, PhD, CISSP, CCSP (she/her)
