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@xxxxxxxxxxxxxx/ 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
