Hello Boris, On 03/01/2022 20:59, Borislav Petkov wrote: > On Mon, Nov 29, 2021 at 11:42:46AM +0000, Dov Murik wrote: >> As a usage example, consider a guest performing computations on >> encrypted files. The Guest Owner provides the decryption key (= secret) >> using the secret injection mechanism. The guest application reads the >> secret from the efi_secret filesystem and proceeds to decrypt the files >> into memory and then performs the needed computations on the content. >> >> In this example, the host can't read the files from the disk image >> because they are encrypted. Host can't read the decryption key because >> it is passed using the secret injection mechanism (= secure channel). >> Host can't read the decrypted content from memory because it's a >> confidential (memory-encrypted) guest. > > So maybe I don't understand the example properly or something's missing > but why can't the guest owner simply scp the secrets into the guest? Why > is this special thing needed? 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. One way to achieve that would be to inject the guest's SSH private key 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). > > The secret below says "...kata-secrets" so this sounds like > something-automated-containers-thing where they'd profit from getting > secrets automatically supplied to the guest. But I guess there you can > scp too... 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 what am I missing? > 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. -Dov
