Re: [PATCH v3 09/11] tpm: Driver for supporting multiple emulated TPMs

["Stefan Berger" <stefanb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 3398 bytes --]

Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote on 02/25/2016 
08:17:32 AM:

> 
> On Wed, Feb 24, 2016 at 06:10:42PM -0500, Stefan Berger wrote:
> >    Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote on 
02/22/2016
> >    09:17:30 PM:
> > 
> >    >
> >    > On Mon, Feb 22, 2016 at 08:45:51PM -0500, Stefan Berger wrote:
> >    >
> >    > > Two things:
> >    > > - the ioctl takes flags; should we return an error on flags 
that are
> >    not
> >    > > supported but set by userspace?
> >    >
> >    > Typically yes. Otherwise you cannot introduce new flags in
> >    > future.
> >    >
> >    > > - the sysfs works but I wished we could give some control over
> >    > whether it shows
> >    > > any entries. Can we have a flag in the ioctl on whether to show
> >    > these files in
> >    > > sysfs?
> >    >
> >    > That is something to address in the future namespace patch series 
I
> >    > expect you'll prepare..
> > 
> >    It may be a while until we get there ... nevertheless it may 
beworth some
> >    thought already.
> > 
> >    So we have at least two choices for how to avoid data leakage via 
sysfs;
> >    the problem is that sysfs shows all vtpm devices in all containers; 
the
> >    good thing is that at least Docker (other mgmt. stacks probably 
also)
> >    mount sysfs read-only into 'normal' containers, so that 
writing(even only
> >    to cancel) isn't typically possible.
> > 
> >    1) allow user space to set a flag whether the sysfs entries are to 
be
> >    registered; a typical container mgmt. stack would set the flag to 
avoid
> >    data leakage between containers; no vtpm device with that flag set 
would
> >    show anything via sysfs
> > 
> >    2) we know in which (user) namespace a /dev/tpm%d device is moved 
into
> >    following an ioctl on the device where a process's PID is a 
parameter; we
> >    could associate the process's (user) namespace with the chip and 
compare
> >    the current_user_ns() with chip->user_ns and return an empty string 
if
> >    they don't match; here the vtpm device owned by a particular (user)
> >    namespace would then also show data in sysfs entries if accessed 
from the
> >    right namespace; which sysfs entry to look at could be inferred 
from the
> >    minor number on /dev/tpm0 inside the container

With clone() not necessarily setting the user namespace and setns() being 
able to do that after some fork()s, I think 2) doesn't work so well.

> 
> 3) Do not show any existing sysfs attributes for containers. All but

A separate sysfs tree isn't built for every container, so sysfs is more or 
less global showing pretty much the same in every container except for 
networking namespace seems to have a way of not doing that.

>    'ppi' are nonsense anyway or is there something that you couldn't 
read
>    from /dev/tpm0? TPM 1.x user space tools could implement them by
>    using the character device. It is not backwards compatibility break
>    technically because existing code does not yet support vTPMs.

Is this the same as 1) then ?

> 
> >       Stefan
> 
> How would you address measurement logs?

IMA would be namespaced and log separately for every IMA namespace / 
container.

   Stefan

> 
> /Jarkko
> 



[-- Attachment #1.2: Type: text/html, Size: 4696 bytes --]

[-- Attachment #2: Type: text/plain, Size: 413 bytes --]

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140

[-- Attachment #3: Type: text/plain, Size: 192 bytes --]

_______________________________________________
tpmdd-devel mailing list
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel