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. > 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
