* Peter Gonda (pgonda@xxxxxxxxxx) wrote: > On Fri, Jan 7, 2022 at 4:59 AM Borislav Petkov <bp@xxxxxxx> wrote: > > > > On Wed, Jan 05, 2022 at 08:07:04PM +0000, Dr. David Alan Gilbert wrote: > > > I thought I saw something in their patch series where they also had a > > > secret that got passed down from EFI? > > > > Probably. I've seen so many TDX patchsets so that I'm completely > > confused what is what. > > > > > As I remember they had it with an ioctl and something; but it felt to > > > me if it would be great if it was shared. > > > > I guess we could try to share > > > > https://lore.kernel.org/r/20211210154332.11526-28-brijesh.singh@xxxxxxx > > > > for SNP and TDX. > > > > > I'd love to hear from those other cloud vendors; I've not been able to > > > find any detail on how their SEV(-ES) systems actually work. > > > > Same here. > > > > > However, this aims to be just a comms mechanism to pass that secret; > > > so it's pretty low down in the stack and is there for them to use - > > > hopefully it's general enough. > > > > Exactly! > > > > > (An interesting question is what exactly gets passed in this key and > > > what it means). > > > > > > All the contentious stuff I've seen seems to be further up the stack - like > > > who does the attestation and where they get the secrets and how they > > > know what a valid measurement looks like. > > > > It would be much much better if all the parties involved would sit down > > and decide on a common scheme so that implementation can be shared but > > getting everybody to agree is likely hard... > > I saw a request for other cloud provider input here. Thanks for the reply! > A little > background for our SEV VMs in GCE we rely on our vTPM for attestation, > we do this because of SEV security properties quoting from AMD being > to protect guests from a benign but vulnerable hypervisor. So a > benign/compliant hypervisor's vTPM wouldn't lie to the guest. So we > added a few bits in the PCRs to allow users to see their SEV status in > vTPM quotes. OK, so we're trying to protect from a malicious hypervisor - we don't trust anything on the host (other than the CPU, and it's got to be signing the attestation); we don't think there's a way to do that with a vTPM on plain SEV/SEV-ES > It would be very interesting to offer an attestation solution that > doesn't rely on our virtual TPM. But after reading through this cover > letter and the linked OVMF patches I am confused what's the high level > flow you are working towards? Are you loading in some OVMF using > LAUNCH_UPDATE_DATA, getting the measurement with LAUNCH_MEASURE, then > sending that to the customer who can then craft a "secret" (maybe say > SSH key) for injection with LAUNCH_SECRET? Thats sounds good but there > are a lot details left unattested there, how do you know you will boot > from the image loaded with the PSP into a known state? Do you have > some documentation I could read through to try and understand a little > more and apologies if I missed it. I'll defer to Dov's reply on that. Dave > > > > -- > > Regards/Gruss, > > Boris. > > > > SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG Nürnberg > > > -- Dr. David Alan Gilbert / dgilbert@xxxxxxxxxx / Manchester, UK
