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
