On Mon, 2017-02-27 at 17:16 +0530, Nayna wrote: > > On 02/24/2017 06:23 PM, James Bottomley wrote: > > On Fri, 2017-02-24 at 12:29 +0530, Nayna wrote: > > > > > > On 02/17/2017 12:55 AM, Jarkko Sakkinen wrote: > > > > From: James Bottomley <james.bottom...@hansenpartnership.com> > > > > > > > > Currently the tpm spaces are not exposed to userspace. Make > > > > this exposure via a separate device, which can now be opened > > > > multiple times because each read/write transaction goes > > > > separately via the space. > > > > > > > > Concurrency is protected by the chip->tpm_mutex for each > > > > read/write transaction separately. The TPM is cleared of all > > > > transient objects by the time the mutex is dropped, so there > > > > should be no interference between the kernel and userspace. > > > > > > To understand, I have two questions: > > > > > > 1. How would a userspace application using TPM know whether to > > > use /dev/tpm0 or /dev/tpms0 ? > > > > Likely they can't use /dev/tpm0 becuase it will be root only, but > > the major indicator will be whether /dev/tpms0 exists or not. > > Thanks James !! > Currently, I see even /dev/tpms0 is also only root accessible. I did > see the discussion to make it 0666, and I understand adding command > filtering is part of enabling /dev/tpms0 as all-accessible.
I don't think we'd ever do that from the kernel. Accessibility would be a userspace policy. This is what I have on my system to make it accessible: /etc/udev/rules.d/80-tpm-2.rules: # tpm 2 devices need to be world readable SUBSYSTEM=="tpms", ACTION=="add", MODE="0666" > Sorry, I didn't understand when you said, "major indicator will be > whether /dev/tpms0" exists or not ? I mean in what case it might not > exist.. If the kernel is too old or you have a 1.2 TPM. > > > > > 2. How would a userspace RM know to build on top of /dev/tpm0 or > > > /dev/tpms0. And if it is built on top of /dev/tpms0, can there be > > > issues with one RM on top of other RM. > > > > There's a known problem with RMs in that they're not fully > > stackable, so I suspect the answer is that if tpms0 exists you > > won't use an RM, but this is currently an area of active research. > > The other potential problem is that if you build a RM on tpm0 in > > userspace, it will fight with the kernel when the kernel uses > > sessions. > > Does it imply that there should be restriction to disallow any RM > specific commands from userspace on /dev/tpm0 ? The only such command would be session or policy context save. It's debateable whether we should interfere. James
