Messages in this thread | | | Date | Fri, 4 Aug 2023 15:24:24 -0700 | From | Dan Williams <> | Subject | Re: [PATCH 1/4] keys: Introduce tsm keys |
| |
Peter Gonda wrote: > > > > > > > > > > + * shared secret and then use that communication channel to instantiate > > > > > > + * other keys. The expectation is that the requester of the tsm key > > > > > > + * knows a priori the key-exchange protocol associated with the > > > > > > + * 'pubkey'. > > > > > > > > > > Can we instead be very specific about what protocols and cryptography > > > > > are being used? > > > > > > > > Again this is a contract to which the kernel is not a party. The > > > > requester knows the significance of the user-data, and it knows where to > > > > send the combined user-data plus quote to provision further secrets. > > > > > > > > Not that I like that arrangement, but the kernel is not enabled by these > > > > TSM implementations to know much more than "user-data in", "report out". > > > > > > Can you explain why using this key API is better than the ioctl > > > version? Is there an overhead to adding keys? > > > > Setting aside that folks that have been involved in the Keyring > > subsystem a lot longer than I are not keen on this usage [1], I expect > > the overhead is negligible. Keys are already used in RPC scenarios and > > can be destroyed immediately after being instantiated and read. > > OK the overhead is negligible. But why is this any better? > > To me this seems strictly worse to me as a user since I have much less > input into the hardware attestation which is one of the primary > benefits of confidential compute. I don't want the kernel limiting > what cryptographic algorithm I use, or limiting attestation reports to > signing pubkeys.
The current proposal on the table is not to have the kernel enforce anything with respect to the format of the "pubkey" payload. The only feedback so far I have seen about improving the semantics here is enforce a nonce which the ioctl() interface just has to trust userspace is handling and the Keyring approach can enforce a callout for that input.
> I understand having a proliferation of similar drivers may not be > ideal but given the hardware lift required to make confidential > compute happen will we really see too many?
From my perspective this discussion has already been worth it as some people were unaware that security relevant development had started under drivers/virt/coco/. The details of the kernel/user contract are coming into focus.
In general, the point at which to have these types of discussions is at the 1 -> 2 implementation transition, to my knowledge we are already up to 5 of these things (AMD, Intel, RISC-V, ARM, S390).
| |