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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Aug 20, 2020 at 09:14:44AM -0700, James Bottomley wrote:
> On Wed, 2020-08-19 at 20:21 -0300, Jason Gunthorpe wrote:
> > On Wed, Aug 19, 2020 at 01:09:16PM -0700, James Bottomley wrote:
> > 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?
> 
> I could do the same with perl, but not bash.  In the same way I could
> construct an anomalous SO(3) higgs model as a party trick.
> 
> the point is that when you ask users would they rather do the above or
> cat /sys/class/tpm/tpm0/pcr-sha1/1 they'll universally opt for the
> latter because it's way simpler.
> 
> Now perhaps if the mechanism that services this in the kernel were
> thousands of lines long and unmaintainable you'd think twice, but it's
> not, it's under 200 lines.  So the maintainability bar to us providing
> this is low and the user convenience quite high ... that's what makes
> it look like a good interface.
> 
> James

I'd also point out that this is the fundamental thing you do with the
pcrs.  There is no other way that some library would want to do it, and
everything builds on it.  We're exporting the core functionality as a
simpler file read/write.  I know that after taking filesystem interfaces
to an extreme, over the past 20 years we've turned back a bit, but in
this case it seems the right way to do it.



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux