On Thu, Oct 20, 2022 at 02:28:36PM -0700, Eric Biggers wrote:

On Thu, Oct 20, 2022 at 04:23:53PM -0300, Jason Gunthorpe wrote:

quoted

On Wed, Oct 19, 2022 at 09:26:05PM -0700, Eric Biggers wrote:

quoted

Are you referring to the support for hardware-wrapped inline crypto keys?  It
isn't upstream yet, but my latest patchset is at
https://lore.kernel.org/linux-fscrypt/20220927014718.125308-2-ebiggers@kernel.org/T/#u (local).
There's also a version of it used by some Android devices already.  Out of
curiosity, are you using it in an Android device, or have you adopted it in some
other downstream?

Unrelated to Android, similar functionality, but slightly different
ultimate purpose. We are going to be sending a fscrypt patch series
for mlx5 and nvme soonish.

That's interesting, though also slightly scary in that it sounds like you've
already shipped some major fscrypt changes without review!

Heh, says the Android guy :)

Fortunately nothing major, we are enterprise focused, we need stuff in
real distros - we know know how to do it.

quoted

That sounds disappointing that we are now having parallel ways for the
admin to manipulate kernel owned keys.

Well, the keyrings subsystem never worked properly for fscrypt anyway.  At most,
it's only useful for providing the key to the filesystem initially (by passing a
key ID to FS_IOC_ADD_ENCRYPTION_KEY, instead of the key bytes), similar to what
dm-crypt allows.  After that, the keyrings subsystem plays no role.

Sure, but loading the key into the keyring should allow many different
options, including things like TPM PCR secured keys (eg like
bitlocker) - we shouldn't allow user space the ability to see the key
data at all.

Duplicating this in every subsystem makes no sense, there is a
reasonable role for the keyring to play in solving these kinds of
problems for everything.

Jason