From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: James Bottomley <jejb@linux.vnet.ibm.com>
Cc: "tpmdd-devel@lists.sourceforge.net"
<tpmdd-devel@lists.sourceforge.net>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager
Date: Thu, 5 Jan 2017 16:50:46 -0700 [thread overview]
Message-ID: <20170105235046.GA4670@obsidianresearch.com> (raw)
In-Reply-To: <1483657126.2515.107.camel@linux.vnet.ibm.com>
On Thu, Jan 05, 2017 at 02:58:46PM -0800, James Bottomley wrote:
> On Thu, 2017-01-05 at 15:21 -0700, Jason Gunthorpe wrote:
> > On Thu, Jan 05, 2017 at 11:55:49AM -0800, James Bottomley wrote:
> >
> > > We don't really have that choice: Keys require authorization, so
> > > you have to have an auth session.
> >
> > I know, this is why I suggested a combo op (kernel level atomicity
> > is clearly DOS safe)..
>
> Transactions are a hard thing to guarantee to be DoS safe and the more
> complex they get, the more difficult they are to police within the
> kernel. Plus we have to keep the R/W interface for backwards
> compatibility now that we have it and I just don't see how we could
> layer transactions into it without having some sort of in-kernel
> emulator.
Again, this was only to make the unpriv FD usable and safe against
session DOS and that FD wouldn't use the legacy r/w interface. I don't
care if root can DOS the TPM via /dev/tpm0. combo ops would need to be
simple enough to reason about. (in my TPM libaries API calls are
combo'd with session anyhow, and that works quite well for my use
models)
> > Lets stick with the user space broker process and just introduce
> > enough kernel RM to enable co-existance with kernel users and clean
> > -up on crash. This should be enough to make a user space broker much
> > simpler.
>
> I wouldn't go that far. I'm still planning a userspace tss2 without
> any access broker daemon, but let's see how far I get on top of the RM.
> I think building in stages is a good way to get actual use experience
> to guide the next stage.
I'm sure you can implement what you are doing on top of the RM -
that isn't a question in my mind.
My question has always been how does your plugin deliver messages to
the kernel RM in a way that does not compromise the security of the
TPM system.
> > So Jarkko's uapi is basically fine.. No need for a kernel white
> > list/etc
>
> I suspect we'll eventually get to needing one, but I'm happy to
> begin
IMHO the problem with trousers as a broker is just how horribly
complex it was.
With the kernel RM this problem becomes very simple:
- 1:1 relationship between incoming clients and kernel fds (Jarkko's
existing design allows a broker to safely create many RM fds)
- Trivial inspection of messages to determine op and check whitelist
(just the first couple bytes give you the opcode, easy to deep
inspect things like get capability)
- No marshal/demarshal, no virtualization, no crypto.
(kernel does virtualization, client does marshal and crypto)
I'm not sure what reason would be big enough to put it in the kernel
when we seem to have irreconcilable use models for the security policy
it needs to implement...
Maybe that is OK, but it isn't what I was hoping for at the start :)
Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
To: James Bottomley <jejb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Cc: "linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@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: Thu, 5 Jan 2017 16:50:46 -0700 [thread overview]
Message-ID: <20170105235046.GA4670@obsidianresearch.com> (raw)
In-Reply-To: <1483657126.2515.107.camel-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On Thu, Jan 05, 2017 at 02:58:46PM -0800, James Bottomley wrote:
> On Thu, 2017-01-05 at 15:21 -0700, Jason Gunthorpe wrote:
> > On Thu, Jan 05, 2017 at 11:55:49AM -0800, James Bottomley wrote:
> >
> > > We don't really have that choice: Keys require authorization, so
> > > you have to have an auth session.
> >
> > I know, this is why I suggested a combo op (kernel level atomicity
> > is clearly DOS safe)..
>
> Transactions are a hard thing to guarantee to be DoS safe and the more
> complex they get, the more difficult they are to police within the
> kernel. Plus we have to keep the R/W interface for backwards
> compatibility now that we have it and I just don't see how we could
> layer transactions into it without having some sort of in-kernel
> emulator.
Again, this was only to make the unpriv FD usable and safe against
session DOS and that FD wouldn't use the legacy r/w interface. I don't
care if root can DOS the TPM via /dev/tpm0. combo ops would need to be
simple enough to reason about. (in my TPM libaries API calls are
combo'd with session anyhow, and that works quite well for my use
models)
> > Lets stick with the user space broker process and just introduce
> > enough kernel RM to enable co-existance with kernel users and clean
> > -up on crash. This should be enough to make a user space broker much
> > simpler.
>
> I wouldn't go that far. I'm still planning a userspace tss2 without
> any access broker daemon, but let's see how far I get on top of the RM.
> I think building in stages is a good way to get actual use experience
> to guide the next stage.
I'm sure you can implement what you are doing on top of the RM -
that isn't a question in my mind.
My question has always been how does your plugin deliver messages to
the kernel RM in a way that does not compromise the security of the
TPM system.
> > So Jarkko's uapi is basically fine.. No need for a kernel white
> > list/etc
>
> I suspect we'll eventually get to needing one, but I'm happy to
> begin
IMHO the problem with trousers as a broker is just how horribly
complex it was.
With the kernel RM this problem becomes very simple:
- 1:1 relationship between incoming clients and kernel fds (Jarkko's
existing design allows a broker to safely create many RM fds)
- Trivial inspection of messages to determine op and check whitelist
(just the first couple bytes give you the opcode, easy to deep
inspect things like get capability)
- No marshal/demarshal, no virtualization, no crypto.
(kernel does virtualization, client does marshal and crypto)
I'm not sure what reason would be big enough to put it in the kernel
when we seem to have irreconcilable use models for the security policy
it needs to implement...
Maybe that is OK, but it isn't what I was hoping for at the start :)
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-05 23: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
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 ` Jason Gunthorpe [this message]
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=20170105235046.GA4670@obsidianresearch.com \
--to=jgunthorpe@obsidianresearch.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.