From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> To: James Bottomley <James.Bottomley@HansenPartnership.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, 3 Jan 2017 15:51:21 +0200 [thread overview] Message-ID: <20170103135121.4kh3jld5gaq3ptj4@intel.com> (raw) In-Reply-To: <1483393248.2458.32.camel@HansenPartnership.com> On Mon, Jan 02, 2017 at 01:40:48PM -0800, James Bottomley wrote: > On Mon, 2017-01-02 at 21:33 +0200, Jarkko Sakkinen wrote: > > On Mon, Jan 02, 2017 at 08:36:20AM -0800, James Bottomley wrote: > > > On Mon, 2017-01-02 at 15:22 +0200, Jarkko Sakkinen wrote: > > > > This patch set adds support for TPM spaces that provide a context > > > > for isolating and swapping transient objects. This patch set does > > > > not yet include support for isolating policy and HMAC sessions > > > > but it is trivial to add once the basic approach is settled (and > > > > that's why I created an RFC patch set). > > > > > > The approach looks fine to me. The only basic query I have is > > > about the default: shouldn't it be with resource manager on rather > > > than off? I can't really think of a use case that wants the RM off > > > (even if you're running your own, having another doesn't hurt > > > anything, and it's still required to share with in-kernel uses). > > > > This is a valid question and here's a longish explanation. > > > > In TPM2_GetCapability and maybe couple of other commands you can get > > handles in the response body. I do not want to have special cases in > > the kernel for response bodies because there is no a generic way to > > do the substitution. What's worse, new commands in the standard > > future revisions could have such commands requiring special cases. In > > addition, vendor specific commans could have handles in the response > > bodies. > > OK, in general I buy this ... what you're effectively saying is that we > need a non-RM interface for certain management type commands. Not only that. Doing virtualization for commands like GetCapability is just a better fit for doing in the user space. You could have a thin translation layer in your TSS library for example to handle these specific messages. > However, let me expand a bit on why I'm fretting about the non-RM use > case. Right at the moment, we have a single TPM device which you use > for access to the kernel TPM. The current tss2 just makes direct use > of this, meaning it has to have 0666 permissions. This means that any > local user can simply DoS the TPM by running us out of transient > resources if they don't activate the RM. If they get a connection > always via the RM, this isn't a worry. Perhaps the best way of fixing > this is to expose two separate device nodes: one raw to the TPM which > we could keep at 0600 and one with an always RM connection which we can > set to 0666. That would mean that access to the non-RM connection is > either root only or governed by a system set ACL. I'm not sure about this. Why you couldn't have a very thin daemon that prepares the file descriptor and sends it through UDS socket to a client. The non-RFC version will also have whitelisting ioctl for further restricting the file descriptor to only specific TPM commands. This is also architecture I preseted in my LSS presentation and I think it makes sense especially when I add the whitelisting to the pack. > James I'm more dilated to keep things way they are now. I'll stick to that at least with the first non-RFC version and hopefully get the tpm2-space.c part reviewed as I split that stuff to a separate commit. /Jarkko
WARNING: multiple messages have this Message-ID (diff)
From: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> To: James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@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, 3 Jan 2017 15:51:21 +0200 [thread overview] Message-ID: <20170103135121.4kh3jld5gaq3ptj4@intel.com> (raw) In-Reply-To: <1483393248.2458.32.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> On Mon, Jan 02, 2017 at 01:40:48PM -0800, James Bottomley wrote: > On Mon, 2017-01-02 at 21:33 +0200, Jarkko Sakkinen wrote: > > On Mon, Jan 02, 2017 at 08:36:20AM -0800, James Bottomley wrote: > > > On Mon, 2017-01-02 at 15:22 +0200, Jarkko Sakkinen wrote: > > > > This patch set adds support for TPM spaces that provide a context > > > > for isolating and swapping transient objects. This patch set does > > > > not yet include support for isolating policy and HMAC sessions > > > > but it is trivial to add once the basic approach is settled (and > > > > that's why I created an RFC patch set). > > > > > > The approach looks fine to me. The only basic query I have is > > > about the default: shouldn't it be with resource manager on rather > > > than off? I can't really think of a use case that wants the RM off > > > (even if you're running your own, having another doesn't hurt > > > anything, and it's still required to share with in-kernel uses). > > > > This is a valid question and here's a longish explanation. > > > > In TPM2_GetCapability and maybe couple of other commands you can get > > handles in the response body. I do not want to have special cases in > > the kernel for response bodies because there is no a generic way to > > do the substitution. What's worse, new commands in the standard > > future revisions could have such commands requiring special cases. In > > addition, vendor specific commans could have handles in the response > > bodies. > > OK, in general I buy this ... what you're effectively saying is that we > need a non-RM interface for certain management type commands. Not only that. Doing virtualization for commands like GetCapability is just a better fit for doing in the user space. You could have a thin translation layer in your TSS library for example to handle these specific messages. > However, let me expand a bit on why I'm fretting about the non-RM use > case. Right at the moment, we have a single TPM device which you use > for access to the kernel TPM. The current tss2 just makes direct use > of this, meaning it has to have 0666 permissions. This means that any > local user can simply DoS the TPM by running us out of transient > resources if they don't activate the RM. If they get a connection > always via the RM, this isn't a worry. Perhaps the best way of fixing > this is to expose two separate device nodes: one raw to the TPM which > we could keep at 0600 and one with an always RM connection which we can > set to 0666. That would mean that access to the non-RM connection is > either root only or governed by a system set ACL. I'm not sure about this. Why you couldn't have a very thin daemon that prepares the file descriptor and sends it through UDS socket to a client. The non-RFC version will also have whitelisting ioctl for further restricting the file descriptor to only specific TPM commands. This is also architecture I preseted in my LSS presentation and I think it makes sense especially when I add the whitelisting to the pack. > James I'm more dilated to keep things way they are now. I'll stick to that at least with the first non-RFC version and hopefully get the tpm2-space.c part reviewed as I split that stuff to a separate commit. /Jarkko ------------------------------------------------------------------------------ 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-03 13:51 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 ` [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 [this message] 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=20170103135121.4kh3jld5gaq3ptj4@intel.com \ --to=jarkko.sakkinen@linux.intel.com \ --cc=James.Bottomley@HansenPartnership.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: linkBe 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.