Messages in this thread | | | From | Peter Gonda <> | Date | Fri, 4 Aug 2023 10:34:01 -0600 | Subject | Re: [PATCH 1/4] keys: Introduce tsm keys |
| |
> > > > > > > > + * 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.
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?
> > [1]: http://lore.kernel.org/r/c6576d1682b576ba47556478a98f397ed518a177.camel@HansenPartnership.com
| |