From: James Bottomley <jejb@linux.vnet.ibm.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: 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: Tue, 03 Jan 2017 11:34:29 -0800 [thread overview]
Message-ID: <1483472069.2464.24.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170103191456.vpl6ny7rbgu3yigx@intel.com>
On Tue, 2017-01-03 at 21:14 +0200, Jarkko Sakkinen wrote:
> On Tue, Jan 03, 2017 at 08:36:02PM +0200, Jarkko Sakkinen wrote:
> > On Tue, Jan 03, 2017 at 08:14:55AM -0800, James Bottomley wrote:
> > > On Tue, 2017-01-03 at 15:41 +0200, Jarkko Sakkinen wrote:
[...]
> > > > Just thinking how to split up the non-RFC patch set. This was
> > > > also what Jason suggested if I understood his remark correctly.
> > >
> > > SUre ... let's get agreement on how we move forward first. How
> > > the patch is activated by the user has to be sorted out as well
> > > before it can go in, but it doesn't have to be the first thing we
> > > do. I'm happy to continue playing with the interfaces to see
> > > what works and what doesn't. My main current feedback is that I
> > > think separate devices works way better than an ioctl becuase the
> > > separate devices approach allows differing system policies for
> > > who accesses the RM backed TPM vs who accesses the raw one.
> >
> > I think I see your point. I would rather name the device as tpms0
> > but otherwise I think we could do it in the way you suggest...
I'm not at all wedded to the name tpm0rm, so tpms0 is fine by me.
> I think one more stronger argument for tpms0 is that it keeps tpm0
> intact. Those who don't care about tpms0 don't have to worry about it
> causing regressions. Also it makes it cleaner to put the whole
> feature under a compilation flag, which would make to me because that
> gives distributions a choice to not enable in-kernel RM when it first
> hits the mainline.
I wouldn't go that far: one of the evils we cause for distros is too
many compile options. In this case, I can't think of a good reason to
have an option to disable this now the feature is segregated on to a
separate device. If we get a regression, only users of the new device
will notice. If it's a compile option, this is the same if the distro
enables it and if it's disabled, no user can test out the feature (and
distros eventually get complaints about it not working).
James
WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <jejb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@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,
open list <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH RFC 0/4] RFC: in-kernel resource manager
Date: Tue, 03 Jan 2017 11:34:29 -0800 [thread overview]
Message-ID: <1483472069.2464.24.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170103191456.vpl6ny7rbgu3yigx-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
On Tue, 2017-01-03 at 21:14 +0200, Jarkko Sakkinen wrote:
> On Tue, Jan 03, 2017 at 08:36:02PM +0200, Jarkko Sakkinen wrote:
> > On Tue, Jan 03, 2017 at 08:14:55AM -0800, James Bottomley wrote:
> > > On Tue, 2017-01-03 at 15:41 +0200, Jarkko Sakkinen wrote:
[...]
> > > > Just thinking how to split up the non-RFC patch set. This was
> > > > also what Jason suggested if I understood his remark correctly.
> > >
> > > SUre ... let's get agreement on how we move forward first. How
> > > the patch is activated by the user has to be sorted out as well
> > > before it can go in, but it doesn't have to be the first thing we
> > > do. I'm happy to continue playing with the interfaces to see
> > > what works and what doesn't. My main current feedback is that I
> > > think separate devices works way better than an ioctl becuase the
> > > separate devices approach allows differing system policies for
> > > who accesses the RM backed TPM vs who accesses the raw one.
> >
> > I think I see your point. I would rather name the device as tpms0
> > but otherwise I think we could do it in the way you suggest...
I'm not at all wedded to the name tpm0rm, so tpms0 is fine by me.
> I think one more stronger argument for tpms0 is that it keeps tpm0
> intact. Those who don't care about tpms0 don't have to worry about it
> causing regressions. Also it makes it cleaner to put the whole
> feature under a compilation flag, which would make to me because that
> gives distributions a choice to not enable in-kernel RM when it first
> hits the mainline.
I wouldn't go that far: one of the evils we cause for distros is too
many compile options. In this case, I can't think of a good reason to
have an option to disable this now the feature is segregated on to a
separate device. If we get a regression, only users of the new device
will notice. If it's a compile option, this is the same if the distro
enables it and if it's disabled, no user can test out the feature (and
distros eventually get complaints about it not working).
James
------------------------------------------------------------------------------
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 1:27 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 ` James Bottomley [this message]
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 ` [tpmdd-devel] " Jason Gunthorpe
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=1483472069.2464.24.camel@linux.vnet.ibm.com \
--to=jejb@linux.vnet.ibm.com \
--cc=jarkko.sakkinen@linux.intel.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.