* Borislav Petkov (bp@xxxxxxx) wrote: > On Tue, Jan 04, 2022 at 09:02:03AM +0200, Dov Murik wrote: > > If the Guest Owner chooses to inject secrets via scp, it needs > > to be sure it is scp-ing to the correct VM - the one that has SEV > > enabled and was measured at launch. > > Hmm, I'd expect that to be part of the attestation dance. I admit, > though, I have only listened about the whole attestation bla from the > sidelines so I'm unclear whether that's part of that protocol. I guess > Tom and Brijesh should have a better idea here. There's more than one type of dance; this partially varies depending on the system (SEV/TDX etc) and also depends on how you depend to boot your VM (separate kernel or VM disk). Also it's important to note that when the dance happens varies - in SEV and SEV-ES this happens before the guest executes any code. So at the end of the dance, the guest owner hands over that secret - but only then does the geust start booting; that secret has to go somewhere to be used by something later. For example, something might pull out that key and use it to decrypt a disk that then has other secrets on it (e.g. your ssh key). Dave > > One way to achieve that would be to inject the guest's SSH private key > > Well, is that "one way" or *the way*? > > > using the proposed efi_secret mechanism. This way the Guest Owner is > > sure it is talking to the correct guest and not to some other VM that > > was started by the untrusted cloud provider (say, with SEV disabled so > > the cloud provider can steal its memory content). > > Because we would need *some* way of verifying the owner is talking > to the correct guest. And if so, this should be made part of the big > picture of SEV guest attestation. Or is this part of that attestation > dance? > > I guess I'm wondering where in the big picture this fits into? > > > Indeed this proposed efi_secret module is in use for enabling SEV > > confidential containers using Kata containers [1], but there's nothing > > specific in the current patch series about containers. The patch series > > just exposes the launch-injected SEV secrets to userspace as virtual files > > (under securityfs). > > > > [1] https://github.com/confidential-containers/attestation-agent/tree/main/src/kbc_modules/offline_sev_kbc > > So one of the aspects for this is to use it in automated deployments. > > > It boils down to: the confidential guest needs to have access to a > > secret which the untrusted host can't read, and which is essential for > > the normal operation of the guest. This secret can be a decryption key, > > an SSH private key, an API key to a Key Management system, etc. If a > > malicious cloud provider tries to start that VM without a secret (or > > with the wrong one), the actual workload that the guest is supposed to > > run will not execute meaningfully. > > > > The proposed patch series exposes the SEV injected secrets as virtual > > files, which can later be used as decryption keys (as done in the kata > > confidential containers use-case), or SSH private keys, or any other > > possible implementation. > > Right, and is this going to be the proper way to authenticate SEV guests > to their owners or is this just another technique for safely supplying > secrets into the guest? > > I hope I'm making some sense here... > > -- > Regards/Gruss, > Boris. > > SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG Nürnberg > -- Dr. David Alan Gilbert / dgilbert@xxxxxxxxxx / Manchester, UK
