From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: James Bottomley <jejb@linux.vnet.ibm.com>,
linux-security-module@vger.kernel.org,
tpmdd-devel@lists.sourceforge.net,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager
Date: Wed, 4 Jan 2017 09:55:51 -0700 [thread overview]
Message-ID: <20170104165550.GB783@obsidianresearch.com> (raw)
In-Reply-To: <20170104125810.3qkkfe72cnb76ige@intel.com>
On Wed, Jan 04, 2017 at 02:58:10PM +0200, Jarkko Sakkinen wrote:
> On Tue, Jan 03, 2017 at 02:54:45PM -0700, Jason Gunthorpe wrote:
> > On Mon, Jan 02, 2017 at 09:26:58PM -0800, James Bottomley wrote:
> >
> > > OK, so I put a patch together that does this (see below). It all works
> > > nicely (with a udev script that sets the resource manager device to
> > > 0666):
> > >
> > > jejb@jarvis:~> ls -l /dev/tpm*
> > > crw------- 1 root root 10, 224 Jan 2 20:54 /dev/tpm0
> > > crw-rw-rw- 1 root root 246, 65536 Jan 2 20:54 /dev/tpm0rm
> > >
> > > I've modified the tss to connect to /dev/tpm0rm by default and it all
> > > seems to work.
> > >
> > > The patch applies on top of your tabrm branch, by the way.
> >
> > If we are making a new /dev/ node we should think more carefully about
> > the design.
> >
> > - Do we need a cdev node for every chip? What about just '/dev/tpm' and
> > we encode the chip number in the message. Since the exclusive
> > locking is gone this is very doable.
>
> What about backwards compatiblity? Or would this be just for /dev/tpms?
> We can consider this.
Yes, just for the new char dev.
> > - Should we get rid of the read/write protocol and use ioctl instead?
> > As I understand it ioctl is more usable with seccomp and related
> > schemes? I could see passing a TPM FD into a sandbox and wanting the
> > sandbox only able to do do decrypt/encrypt operations, for instance.
>
> Are you suggesting that command/response transaction would be handled
> by ioctl instead of read/write pair. Would make sense looking at how
> read/write is managed now (it is more or less of a hack because it
> actually is a transction).
Yes.
> > - Something to identify tpm chips and help match key data with the
> > proper chip.
>
> Hey, here's what I propose. I take some of the ideas (not all there
> have been so many) and bake a v2 of the RFC. Lets see where we are
> at then. I won't add any reviewed/tested-by's before we are in the
> same line with "big ideas" nor do I create a non-RFC patch set.
Usually with something like this there will be lots of dicussion
around the uapi portion - that is the portion we have to reatin
backwards compatability with forever - so there is a natural need to
make sure it is sane.
This is why I'm so cautious to limit what is possible because it is
easier to add new stuff then take stuff away.
So design your patch set to keep the uapi stuff as distinct and
well-described as possible - the other parts are much easier to review
and agree on.
Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
To: Jarkko Sakkinen
<jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
James Bottomley
<jejb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>,
open list <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH RFC 0/4] RFC: in-kernel resource manager
Date: Wed, 4 Jan 2017 09:55:51 -0700 [thread overview]
Message-ID: <20170104165550.GB783@obsidianresearch.com> (raw)
In-Reply-To: <20170104125810.3qkkfe72cnb76ige-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
On Wed, Jan 04, 2017 at 02:58:10PM +0200, Jarkko Sakkinen wrote:
> On Tue, Jan 03, 2017 at 02:54:45PM -0700, Jason Gunthorpe wrote:
> > On Mon, Jan 02, 2017 at 09:26:58PM -0800, James Bottomley wrote:
> >
> > > OK, so I put a patch together that does this (see below). It all works
> > > nicely (with a udev script that sets the resource manager device to
> > > 0666):
> > >
> > > jejb@jarvis:~> ls -l /dev/tpm*
> > > crw------- 1 root root 10, 224 Jan 2 20:54 /dev/tpm0
> > > crw-rw-rw- 1 root root 246, 65536 Jan 2 20:54 /dev/tpm0rm
> > >
> > > I've modified the tss to connect to /dev/tpm0rm by default and it all
> > > seems to work.
> > >
> > > The patch applies on top of your tabrm branch, by the way.
> >
> > If we are making a new /dev/ node we should think more carefully about
> > the design.
> >
> > - Do we need a cdev node for every chip? What about just '/dev/tpm' and
> > we encode the chip number in the message. Since the exclusive
> > locking is gone this is very doable.
>
> What about backwards compatiblity? Or would this be just for /dev/tpms?
> We can consider this.
Yes, just for the new char dev.
> > - Should we get rid of the read/write protocol and use ioctl instead?
> > As I understand it ioctl is more usable with seccomp and related
> > schemes? I could see passing a TPM FD into a sandbox and wanting the
> > sandbox only able to do do decrypt/encrypt operations, for instance.
>
> Are you suggesting that command/response transaction would be handled
> by ioctl instead of read/write pair. Would make sense looking at how
> read/write is managed now (it is more or less of a hack because it
> actually is a transction).
Yes.
> > - Something to identify tpm chips and help match key data with the
> > proper chip.
>
> Hey, here's what I propose. I take some of the ideas (not all there
> have been so many) and bake a v2 of the RFC. Lets see where we are
> at then. I won't add any reviewed/tested-by's before we are in the
> same line with "big ideas" nor do I create a non-RFC patch set.
Usually with something like this there will be lots of dicussion
around the uapi portion - that is the portion we have to reatin
backwards compatability with forever - so there is a natural need to
make sure it is sane.
This is why I'm so cautious to limit what is possible because it is
easier to add new stuff then take stuff away.
So design your patch set to keep the uapi stuff as distinct and
well-described as possible - the other parts are much easier to review
and agree on.
Jason
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
next prev parent reply other threads:[~2017-01-04 16:57 UTC|newest]
Thread overview: 150+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-02 13:22 [PATCH RFC 0/4] RFC: in-kernel resource manager Jarkko Sakkinen
2017-01-02 13:22 ` Jarkko Sakkinen
2017-01-02 13:22 ` [PATCH RFC 1/4] tpm: migrate struct tpm_buf to struct tpm_chip Jarkko Sakkinen
2017-01-02 13:22 ` Jarkko Sakkinen
2017-01-02 21:01 ` Jason Gunthorpe
2017-01-02 21:01 ` Jason Gunthorpe
2017-01-03 0:57 ` Jarkko Sakkinen
2017-01-03 19:13 ` Jason Gunthorpe
2017-01-03 19:13 ` Jason Gunthorpe
2017-01-04 12:29 ` Jarkko Sakkinen
2017-01-04 12:29 ` Jarkko Sakkinen
2017-01-02 13:22 ` [PATCH RFC 2/4] tpm: validate TPM 2.0 commands Jarkko Sakkinen
2017-01-02 13:22 ` Jarkko Sakkinen
[not found] ` <20170102132213.22880-3-jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-01-04 18:04 ` Stefan Berger
2017-01-04 18:19 ` [tpmdd-devel] " James Bottomley
2017-01-04 18:19 ` James Bottomley
[not found] ` <1483553976.2561.38.camel-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-01-04 18:59 ` Stefan Berger
[not found] ` <OF3FD1DF4F.FB87C3F2-ON0025809E.00682E9B-8525809E.00684A8A-8eTO7WVQ4XIsd+ienQ86orlN3bxYEBpz@public.gmane.org>
2017-01-04 19:05 ` James Bottomley
[not found] ` <1483556735.2561.53.camel-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-01-04 19:22 ` Stefan Berger
[not found] ` <OFDFABBD23.E5E1F639-ON0025809E.006924C4-8525809E.006A7568-8eTO7WVQ4XIsd+ienQ86orlN3bxYEBpz@public.gmane.org>
2017-01-09 22:17 ` Jarkko Sakkinen
[not found] ` <20170109221700.q7tq362rd6r23d5b-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-01-09 22:39 ` Stefan Berger
2017-01-04 18:44 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-04 18:44 ` Jason Gunthorpe
2017-01-02 13:22 ` [PATCH RFC 3/4] tpm: export tpm2_flush_context_cmd Jarkko Sakkinen
2017-01-02 13:22 ` Jarkko Sakkinen
2017-01-02 13:22 ` [PATCH RFC 4/4] tpm: add the infrastructure for TPM space for TPM 2.0 Jarkko Sakkinen
2017-01-02 13:22 ` Jarkko Sakkinen
2017-01-02 21:09 ` Jason Gunthorpe
2017-01-02 21:09 ` Jason Gunthorpe
2017-01-03 0:37 ` Jarkko Sakkinen
2017-01-03 18:46 ` Jason Gunthorpe
2017-01-03 18:46 ` Jason Gunthorpe
2017-01-04 12:43 ` Jarkko Sakkinen
2017-01-04 12:43 ` Jarkko Sakkinen
2017-01-03 19:16 ` Jason Gunthorpe
2017-01-03 19:16 ` Jason Gunthorpe
2017-01-04 12:45 ` Jarkko Sakkinen
2017-01-04 12:45 ` Jarkko Sakkinen
[not found] ` <20170102132213.22880-5-jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-01-04 17:50 ` Stefan Berger
2017-01-09 22:11 ` [tpmdd-devel] " Jarkko Sakkinen
2017-01-02 16:36 ` [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager James Bottomley
2017-01-02 19:33 ` Jarkko Sakkinen
2017-01-02 19:33 ` Jarkko Sakkinen
2017-01-02 21:40 ` [tpmdd-devel] " James Bottomley
2017-01-02 21:40 ` James Bottomley
2017-01-03 5:26 ` [tpmdd-devel] " James Bottomley
2017-01-03 13:41 ` Jarkko Sakkinen
2017-01-03 13:41 ` Jarkko Sakkinen
2017-01-03 16:14 ` [tpmdd-devel] " James Bottomley
2017-01-03 16:14 ` James Bottomley
2017-01-03 18:36 ` [tpmdd-devel] " Jarkko Sakkinen
2017-01-03 18:36 ` Jarkko Sakkinen
2017-01-03 19:14 ` [tpmdd-devel] " Jarkko Sakkinen
2017-01-03 19:14 ` Jarkko Sakkinen
2017-01-03 19:34 ` [tpmdd-devel] " James Bottomley
2017-01-03 19:34 ` James Bottomley
2017-01-03 21:54 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-03 21:54 ` Jason Gunthorpe
2017-01-04 12:58 ` [tpmdd-devel] " Jarkko Sakkinen
2017-01-04 12:58 ` Jarkko Sakkinen
2017-01-04 16:55 ` Jason Gunthorpe [this message]
2017-01-04 16:55 ` Jason Gunthorpe
2017-01-04 5:47 ` [tpmdd-devel] " Andy Lutomirski
2017-01-04 13:00 ` Jarkko Sakkinen
2017-01-03 13:51 ` Jarkko Sakkinen
2017-01-03 13:51 ` Jarkko Sakkinen
2017-01-03 16:36 ` [tpmdd-devel] " James Bottomley
2017-01-03 16:36 ` James Bottomley
2017-01-03 18:40 ` [tpmdd-devel] " Jarkko Sakkinen
2017-01-03 21:47 ` Jason Gunthorpe
2017-01-03 22:21 ` Ken Goldman
2017-01-03 22:21 ` Ken Goldman
2017-01-03 23:20 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-03 23:20 ` Jason Gunthorpe
[not found] ` <20170103214702.GC29656-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2017-01-03 22:22 ` Ken Goldman
2017-01-03 22:39 ` [tpmdd-devel] " James Bottomley
2017-01-03 22:39 ` James Bottomley
2017-01-04 0:17 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-04 0:29 ` James Bottomley
2017-01-04 0:29 ` James Bottomley
2017-01-04 0:56 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-04 0:56 ` Jason Gunthorpe
2017-01-04 12:50 ` [tpmdd-devel] " Jarkko Sakkinen
2017-01-04 12:50 ` Jarkko Sakkinen
2017-01-04 14:53 ` [tpmdd-devel] " James Bottomley
2017-01-04 14:53 ` James Bottomley
2017-01-04 18:31 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-04 18:31 ` Jason Gunthorpe
2017-01-04 18:57 ` [tpmdd-devel] " James Bottomley
2017-01-04 18:57 ` James Bottomley
2017-01-04 19:24 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-04 19:24 ` Jason Gunthorpe
[not found] ` <20170104001732.GB32185-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2017-01-10 18:55 ` Ken Goldman
2017-01-04 12:48 ` [tpmdd-devel] " Jarkko Sakkinen
2017-01-04 12:48 ` Jarkko Sakkinen
[not found] ` <1483461370.2464.19.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2017-01-03 22:18 ` Ken Goldman
2017-01-03 21:32 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-03 21:32 ` Jason Gunthorpe
2017-01-03 22:03 ` [tpmdd-devel] " James Bottomley
2017-01-05 15:52 ` Fuchs, Andreas
2017-01-05 15:52 ` Fuchs, Andreas
2017-01-05 17:27 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-05 17:27 ` Jason Gunthorpe
2017-01-05 18:06 ` [tpmdd-devel] " James Bottomley
2017-01-05 18:06 ` James Bottomley
2017-01-06 8:43 ` [tpmdd-devel] " Andreas Fuchs
2017-01-06 8:43 ` Andreas Fuchs
[not found] ` <410e3045-58dc-5415-30c1-c86eb916b6c8-iXjGqz/onsDSyEMIgutvibNAH6kLmebB@public.gmane.org>
2017-01-10 18:57 ` Ken Goldman
2017-01-05 18:33 ` [tpmdd-devel] " James Bottomley
2017-01-05 18:33 ` James Bottomley
2017-01-05 19:20 ` Jason Gunthorpe
2017-01-05 19:20 ` Jason Gunthorpe
2017-01-05 19:55 ` [tpmdd-devel] " James Bottomley
2017-01-05 19:55 ` James Bottomley
2017-01-05 22:21 ` Jason Gunthorpe
2017-01-05 22:21 ` Jason Gunthorpe
2017-01-05 22:58 ` [tpmdd-devel] " James Bottomley
2017-01-05 22:58 ` James Bottomley
2017-01-05 23:50 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-05 23:50 ` Jason Gunthorpe
2017-01-06 0:36 ` [tpmdd-devel] " James Bottomley
2017-01-06 0:36 ` James Bottomley
2017-01-06 8:59 ` Andreas Fuchs
2017-01-06 8:59 ` Andreas Fuchs
2017-01-06 19:10 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-06 19:10 ` Jason Gunthorpe
2017-01-06 19:02 ` [tpmdd-devel] " Jason Gunthorpe
2017-01-06 19:02 ` Jason Gunthorpe
2017-01-10 19:03 ` Ken Goldman
2017-01-10 19:03 ` Ken Goldman
2017-01-09 22:39 ` [tpmdd-devel] " Jarkko Sakkinen
2017-01-09 22:39 ` Jarkko Sakkinen
2017-01-11 10:03 ` Andreas Fuchs
2017-01-11 10:03 ` Andreas Fuchs
2017-01-04 16:12 Dr. Greg Wettstein
2017-01-04 16:12 ` Dr. Greg Wettstein
2017-01-09 23:16 ` Jarkko Sakkinen
2017-01-10 19:29 ` Ken Goldman
2017-01-10 19:29 ` Ken Goldman
2017-01-11 11:36 ` Jarkko Sakkinen
2017-01-10 20:05 ` Jason Gunthorpe
2017-01-11 10:00 ` Andreas Fuchs
2017-01-11 18:03 ` Jason Gunthorpe
2017-01-11 18:27 ` Stefan Berger
2017-01-11 19:18 ` Jason Gunthorpe
2017-01-11 11:34 ` Jarkko Sakkinen
2017-01-11 15:39 ` James Bottomley
2017-01-11 17:56 ` Jason Gunthorpe
2017-01-11 18:25 ` James Bottomley
2017-01-11 19:04 ` Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170104165550.GB783@obsidianresearch.com \
--to=jgunthorpe@obsidianresearch.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jejb@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=tpmdd-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.