[RFC PATCH 0/3] Allow access to confidential computing secret area

[James Bottomley]

On Mon, 2021-05-24 at 13:08 +0100, Dr. David Alan Gilbert wrote:
> * Andi Kleen (ak at linux.intel.com) wrote:
[...]
> > We opted to use ioctls, with the idea that it should be just read
> > and cleared once to not let the secret lying around. Typically you
> > would just use it to set up dmcrypt or similar once. I think read-
> > and-clear with explicit operations is a better model than some
> > virtual file because of the security properties.
> 
> Do you think the ioctl is preferable to read+ftruncate/unlink ?

I really think if we do a unified upper interface it should be file
based.  An ioctl based on will have too much temptation to expose the
architecture of the underlying system.  However, the way to explore
this would be to ask if there's anything the current ioctl based one
can do that a file based one couldn't?

I think ftruncate/unlink is a preferable interface because it puts the
control in the hands of the consumer: you don't know how far the secret
might get shared, so by doing clear on first read the driver is forcing
the user implementation to cache it instead, thus shifting the problem
not solving it.

James