Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

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)..

> If you want things like PCR sealed or time limited keys, you don't
> really have a choice on policy sessions either.

.. and advanced stuff like is what I was talking about giving up for
unpriv if it can't be allowed safely ...

> I think we've got to the point where arguing about our divergent use
> requirements shows the default should be 0600 and every command enabled
> so that whatever changes the device to 0666 also applies the command

Well, that is what we already have with /dev/tpm0.

I'm very surprised by this level of disagreement, so I'm inclined to
drop the idea that the kernel can directly support a 0666 cdev at all.

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.

So Jarkko's uapi is basically fine.. No need for a kernel white list/etc

I had really hoped we could have a secure default 0666 cdev that would
be able to support the basic use of your user space plugins without a
daemon :(

Jason

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot