On Fri, 2020-09-25 at 10:28 +0300, Jarkko Sakkinen wrote: > On Mon, Sep 21, 2020 at 07:28:07PM -0700, James Bottomley wrote: [...] > > keyctl add trusted kmk "new 32 > > blobauth=f572d396fae9206628714fb2ce00f72e94f2258fkeyhandle=81000001 > > " @u > > > > after we will accept both the old hex sha1 form as well as a new > > directly supplied password: > > > > keyctl add trusted kmk "new 32 blobauth=hello keyhandle=81000001" > > @u > > I'm still getting -EINVAL from both with a Geminilake NUC. Since I don't have one of those you're going to have to give me more to go on. I've tested this works in a VM with the ibmtss and on a Rainbow Pass with a variety of physical TPMs. Keyctl returns -EINVAL for an annoying number of conditions it shouldn't ... the most frequent of which is that the key already exists in the keyring. So what's different about the Geminilake NUC? Either it's a kernel problem with the TPM, in which case there should be something in dmesg or it's a userspace problem with keyctl, in which case perhaps strace might get us further forward. James
