On Tue, 2020-08-18 at 19:19 +0300, Jarkko Sakkinen wrote: > On Tue, Aug 18, 2020 at 07:12:09PM +0300, Jarkko Sakkinen wrote: > > On Mon, Aug 17, 2020 at 02:35:06PM -0700, James Bottomley wrote: > > > Create sysfs per hash groups with 24 PCR files in them one group, > > > named pcr-<hash>, for each agile hash of the TPM. The files are > > > plugged in to a PCR read function which is TPM version agnostic, > > > so this works also for TPM 1.2 but the hash is only sha1 in that > > > case. > > > > > > Note: the macros used to create the hashes emit spurious > > > checkpatch warnings. Do not try to "fix" them as checkpatch > > > recommends, otherwise they'll break. > > > > > > Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership > > > .com> > > > Reviewed-by: Jerry Snitselaar <jsnitsel@xxxxxxxxxx> > > > Tested-by: Thiago Jung Bauermann <bauerman@xxxxxxxxxxxxx> > > > > I have hard time understanding why this is required. > > > > You can grab the information through /dev/tpm0 just fine. > > I just think it is principally wrong to add sysfs files if they don't > have any measurable value other than perhaps some convenience. That's pretty much the whole point of sysfs (and procfs): to add convenient extraction of information even if it could potentially be obtained by other sources. For instance, the whole reason we add a lot of the broken out inquiry data in SCSI via sysfs is precisely so users don't have to go prodding devices with direct SCSI commands, which are pretty much analagous to TPM device commands. The question you should be asking isn't whether the information *could* be obtained by other means, but whether providing it in this form facilitates current operations and whether the interface would have users. > It is trival to write only a libc dependent program that outputs > PCRs. Not for someone who understands only scripting. There are two problems: firstly the actual construction of TPM commands is somewhat complex and pretty much impossible even for shells like bash to construct and secondly without a TSS installed, the tpm and tpmrm devices are root owned and 0600 permissioned, so a non-root user simply can't use them. > I think this is essentially an user space problem that is getting > sorted out with kernel code. So you'd argue that a kernel shouldn't provide a filesystem because it's simply a seekable key/value retrieval system provided over storage devices (and there are plenty of databases that do it for you on raw devices from userspace)? A big point of a Kernel is to provide a load of convenience interfaces to users even if users could, in theory, do it all themselves. A filesystem is actually a classic example because the directory structure and file API make data organization and retrieval relatively easy for the average user, whereas just presenting them with a SCSI command interface and telling them to use it would be an instant blocker for most of them. The question, again, is not whether a user *could* do this another way but whether the interface provided makes a task (or set of tasks) easier, whether the API provided is easy to use and finally, whether the interface will actually attract any users. James
