On Mon, 2021-05-24 at 13:08 +0100, Dr. David Alan Gilbert wrote: > * Andi Kleen (ak@xxxxxxxxxxxxxxx) 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
