On Fri, Sep 25, 2020 at 10:39:23AM -0700, James Bottomley wrote: > 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 I'll debug it further sometime next week, just acknowledged the issue. I'll use bpftrace for the purpose. In your environment, would be interesting to see what happens if you use tpm2-root-key to generate the key instead of IBMTSS. It is now available here: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/tpm2-scripts.git/ /Jarkko
