Messages in this thread | | | Date | Mon, 27 Feb 2017 10:28:34 -0700 | From | Jason Gunthorpe <> | Subject | Re: [tpmdd-devel] [PATCH v2 6/7] tpm: expose spaces via a device link /dev/tpms<n> |
| |
On Sat, Feb 25, 2017 at 12:04:49PM -0500, James Bottomley wrote:
> > device cgroup blocks access to the cdevs of tpm0 but not to the > > sysfs files. > > What the device cgroup currently does for us and what it could do are > two different things. It seems if it exported > __devcgroup_check_permission, we could use that as a check to gate the > sysfs file access.
Make sense, maybe we should be doing that..
Stefan, are you still interested in this? This seems like a fairly simple solution to your problem???
> > I am talking about using a situation like kernel IMA or keyring in > > the container with a tpm that is not tpm0, eg a vtpm. > > a vtpm appears as a tpm device so it can be controlled by the device > cgroup ... I think I'm not seeing the issue.
When an in-kernel call opens the TPM it does not go through the cdev, it does something like this:
extern int tpm_pcr_read(u32 chip_num, int pcr_idx, u8 *res_buf);
And hardwires 'chip_num' to TPM_ANY_NUM. Keyring does the same (see trusted_instantiate)
Practically speaking this means in-kernel callers pretty much always operate on tpm0.
I think we need to change TPM_ANY_NUM to something more container friendly, but I'm not sure what that should be.
> be done at all) it's usually better to start with use cases. So > instead of saying we need to virtualize the PCRs we should start with X > container has this requirement for attestation of its Y state. Often > the best way simply is an extension of the multi user model for the > resource ... in this case no-one's really come up with one for PCRs, so > that might be the place to begin.
Broadly makes sense to me.
Maybe kernel keyring is a better example, it already has a multi-user model.
Jason
| |