Re: [PATCH v4 1/1] tpm: add sysfs exports for all banks of PCR registers

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Aug 19, 2020 at 01:09:16PM -0700, James Bottomley wrote:
> On Wed, 2020-08-19 at 14:17 -0300, Jason Gunthorpe wrote:
> > On Wed, Aug 19, 2020 at 12:57:42PM -0400, Mimi Zohar wrote:
> > > On Wed, 2020-08-19 at 13:18 -0300, Jason Gunthorpe wrote:
> > > > Yes - it was dropped because TPM 2 was a *complete ABI break* for
> > > > everything. The kernel was reset to a uABI that matches current
> > > > uABI standards starting TPM 2.
> > > > 
> > > > The whole userspace needed to be redone anyhow, and certainly
> > > > nobody objected at the time.
> > > > 
> > > > At least my expecation was that a sensible userspace for TPM (for
> > > > administrator user) would be built, like we see in other
> > > > subsystems eg 'ip' for netdev.
> > > 
> > > "Because TPM 2 was a complete ABI break for everything" could be
> > > reason for upstreaming a minimal subset of functionality initially,
> > > which could be expanded over time.  I don't recall a discussion
> > > about limting features in the future.
> > 
> > All new uAPI additions need to pass the usual uAPI hurdles.
> > 
> > As James outlined, justify why the kernel must present a duplicated
> > uAPI between sysfs and /dev/tpm. 
> > 
> > There have been good reasons in the past, eg SCSI inquiry.
> 
> First, can we please agree /dev/tpm does not substitute as a "duplicate
> API". 

Er? Huh? How so?

> I can now clarify the objection into "it's a binary marshalled
> interface and Linus doesn't think we should force users to use them":
> 
> https://lore.kernel.org/linux-api/CAHk-=wh5YifP7hzKSbwJj94+DZ2czjrZsczy6GBimiogZws=rg@mail.gmail.com/

I'm not sure which part of that you want to quote?

"It's great for well-specified wire protocols." which is describing
/dev/tpm - it has a multivendor standards body.

Bit puzzled about the rest of this message? Do you think Linus belives
netlink should have been implemented as ASCII? JSON parser in the
kernel maybe? Confusing.

> Perhaps we should also simply copy linux-api and accept the judgment of
> the experts on whether we should expose PCRs via sysfs.

Well, AFAIK, for a long time now the mantra has been "if it can be
done in userspace then it should not be in the kernel" ..

I would really like to see a better reason for this - one that doesn't
boil down to it being 'too hard' to write a bit of code in userspace.

eg we can't do it because we can't access /dev/tpm for permissions or
something.

> The reason we provide a kernel interface instead of a library or tool
> is that libraries and tools tend to be domain specific and the
> information needs to be provided across domains.  So: both the current
> TPM 2.0 TSSs are written in C.  This means they can just about be
> plugged into python but not easily into Go because of its abhorrence of
> ffis.  Providing the PCRs from sysfs allows Go attestation easy access
> that the TSS tools don't because of the language domain problem.

I went to try to make a python implementation.. After about 10mins I
came up with this approximate thing:

 select = struct.pack(">BBB", 1, 0, 0) # PCR 1
 pcrread_in = struct.pack(">IHB", 1, TPM2_ALG_SHA1, len(select)) + select
 msg = struct.pack(">HII", TPM2_ST_NO_SESSIONS, 10 + len(pcrread_in), TPM2_CC_PCR_READ) + pcrread_in

 with open("/dev/tpm","wb") as tpm:
    tpm.write(msg)
    resp = tpm.read(msg)

 tag, length, return_code = struct.unpack(">HII",res[:10])
 if not return_code:
    raise Error()

 return res[10+20:] # digest

Which is hopefully quite close to being something working - at least
it looks fairly close to what the kernel implementation does.

Fortunately no Phd was required! I think Go would be about similar,
right?

Jason