On Fri, 2017-02-24 at 13:52 -0700, Jason Gunthorpe wrote: > On Fri, Feb 24, 2017 at 03:29:15PM -0500, James Bottomley wrote: > > On Fri, 2017-02-24 at 11:11 -0700, Jason Gunthorpe wrote: > > > On Fri, Feb 24, 2017 at 07:39:22PM +0200, Jarkko Sakkinen wrote: > > > > > > > > I think therefore that tpmns<n> for TPM Namespace would be > > > > > very > > > > > appropriate. > > > > > > > > Makes sense. We can go with tpmns. > > > > > > When we have talked about TPM namespaces in the past it has been > > > around the idea of restricting which TPMs the namespace has > > > access > > > too and changing the 'kernel tpm' for that namespace. > > > > Well, you know, nothing in the TPM Space code prevents us from > > exposing > > the namespace so that it could be shared. However, I think the > > namespace follows connect (device open) paradigm is pretty much the > > behaviour everyone (including the kernel) wants, mostly because > > TPM2 > > has such a tiny amount of resources that you're always dealing with > > loadable keys meaning you don't really want to see anyone else's > > volatile state. > > I'm not arguing with that use model, I am asking what do you want to > call the future feature that restricts which TPMs a process can view > if you want to use the word namespace for the resource manager?
Well, as a glib answer, I'd say the TPM is a device, so the thing which restricts device access to containers is the device cgroup ... that's what we should be plugging into. I'd have to look, but I suspect the device cgroup basically operates on device node appearance, so it should "just work"(tm). I can explore when I'm back home. James > This is something Stephen B has been exploring in conjunction with > vtpm. (eg restrict a container to only use a single vtpm and ban it > from the system tpm) > > Jason > > --------------------------------------------------------------------- > --------- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > tpmdd-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/tpmdd-devel >
