Messages in this thread | | | From | Dionna Amalie Glaze <> | Date | Fri, 4 Aug 2023 09:37:23 -0700 | Subject | Re: [PATCH 1/4] keys: Introduce tsm keys |
| |
> In this model the kernel is only a conduit to get 64-bytes of data > signed by the report, and the kernel need not have any requirements on > that data. That said, it could. That's where I would look to > recommendations from Dionna and James and others about what contract the > kernel *could* enforce to ensure that best security practices are being > deployed. I expect that also helps this implementation cross the > threshold from "blob store" to "key" as the Keyring expects. >
I believe there is no security best practice here yet to enforce.
Attestation reports are a power feature, just like a TPM. A TPM doesn't place any restriction on the format for its nonce, and like James said, there's already a special entry point for TPM-wrapped keys in the key API. Users have access to TPM quotes through /dev/tpm0 and can pass whatever nonce. I don't think we need to limit access to the interface this hardware gives us because we're trying to avoid another char device by saying a report is a key.
The coming addition of the SVSM to further isolate the guest and provide extra "security devices" is also something to be aware of. There will be a vTPM protocol and a new type of attestation that's rooted to VMPL0 while Linux is still in VMPL3. I don't think this will make sev-guest an unnecessary device though, since it's still undecided how the TPM hierarchy can bind itself to the hardware in a non-adhoc manner: there's no "attested TPM" spec to have something between the null hierarchy and the more persistent attestation key hierarchy. And TCG isn't in the business of specifying how to virtualize the TPM technology, so we might have to manually link the two together by getting the tpm quote and then doing a further binding operation with the sev-guest device.
So, can we give unfettered access to the hardware through not a Key API but an Attestation API, and for historical reasons allow vTPM to be its own thing with extra commands? The SVSM could allow users to have access to more commands than getting an attestation report, like a virtual HSM separate from the TPM. We wouldn't be able to access it without a SEV-SNP-specific device. Does that mean it can't be upstreamed? Do all confidential computing technologies specifically not differentiate themselves in their capabilities to all use the same kernel API for interaction?
-- -Dionna Glaze, PhD (she/her)
| |