On Tue, Mar 26, 2019 at 09:59:40AM -0500, Denis Kenzior wrote: > Hi James, > > On 03/26/2019 09:25 AM, James Bottomley wrote: > > Looking at the contents of linux/keys/trusted.h, it looks like the > > wrong decision to move it. The contents are way too improperly named > > and duplicative to be in a standard header. It's mostly actually TPM > > code including a redefinition of the tpm_buf structure, so it doesn't > > even seem to be necessary for trusted keys. > The reason this was done was because asym_tpm.c needed a bunch of the same > functionality already provided by trusted.c, e.g. TSS_authmac and friends. > > > > > If you want to fix this as a bug, I'd move it back again, but long term > > I think it should simply be combined with trusted.c because nothing > > else can include it sanely anyway. > > Ideally I'd like to see the TPM subsystem expose these functions using some > proper API / library abstraction. David Howells had an RFC patch set that > tried to address some of this a while back. Not sure if that went anywhere. I think it'd be best to expose tpm_buf API to outside and allow trusted keys code to construct the TPM commands. It is a single consumer use (e.g. not like PCR operations where it does make sense to consolidate to the TPM subsystem). /Jarkko
