On Mon, 2019-09-02 at 16:26 -0300, Jason Gunthorpe wrote: > On Fri, Aug 30, 2019 at 02:20:54PM -0700, Tadeusz Struk wrote: > > On 8/28/19 9:15 AM, Jason Gunthorpe wrote: > > >>> So exposing PCRs and things through sysfs is not going to happen. > > >>> > > >>> If you had some very narrowly defined things like version, then > > >>> *maybe* but I think a well defined use case is needed for why this > > >>> needs to be sysfs and can't be done in C as Jarkko explained. > > >> Piotr's request for a sysfs file to differentiate between TPM 1.2 and > > >> TPM 2.0 is a reasonable request and probably could be implemented on > > >> TPM registration. > > >> > > >> If exposing the PCRs through sysfs is not acceptable, then perhaps > > >> suggest an alternative. > > > Use the char dev, this is exactly what is is for. > > > > What about a new /proc entry? > > Currently there are /proc/cpuinfo, /proc/meminfo, /proc/slabinfo... > > What about adding a new /proc/tpminfo that would print info like > > version, number of enabled PCR banks, physical interface [tis|crb], > > vendor, etc. > > I thought we were not really doing new proc entries? > > Why this focus on making some textual output? I don't really care if we define procfs, sysfs, or securityfs file(s) or whether those files are ascii or binary. Whatever is defined, should be defined for both TPM 1.2 and TPM 2.0 (eg. TPM version). Mimi
