[PATCH v19 17/27] x86/sgx: Add provisioning

[Jarkko Sakkinen]

On Fri, Apr 05, 2019 at 04:34:46PM +0200, Greg KH wrote:
> On Fri, Apr 05, 2019 at 05:20:06PM +0300, Jarkko Sakkinen wrote:
> > On Fri, Apr 05, 2019 at 06:53:57AM -0700, Andy Lutomirski wrote:
> > > On Fri, Apr 5, 2019 at 3:18 AM Jarkko Sakkinen
> > > <jarkko.sakkinen at linux.intel.com> wrote:
> > > >
> > > > On Mon, Mar 25, 2019 at 04:55:03PM +0200, Jarkko Sakkinen wrote:
> > > > > > > Hmm.. on 2nd thought the LSM policy or even DAC policy  would restrict
> > > > > > > that the container manager can only access specific files inside
> > > > > > > securityfs. With this conclusion I still think it is probably the best
> > > > > > > place for seurity policy like things even for SGX. It is meant for that
> > > > > > > anyway.
> > > > > > >
> > > > > >
> > > > > > LSM or DAC policy can certainly *restrict* it, but I suspect that most
> > > > > > container runtimes don't mount securityfs at all.  OTOH, the runtime
> > > > > > definitely needs to have a way to pass /dev/sgx/enclave (or whatever
> > > > > > it's called) through, so using another device node will definitely
> > > > > > work.
> > > > >
> > > > > OK, I can cope with this argument. I go with the device names above for
> > > > > v20.
> > > >
> > > > In v20 the refactoring would be with corresponding modes:
> > > >
> > > > /dev/sgx 0755
> > > > /dev/sgx/enclave 0666
> > > > /dev/sgx/provision 0600
> > > >
> > > > The problem that I'm facing is that with devnode callback of struct
> > > > device_type I can easily give the defaut mode for any of the files but
> > > > not for the /dev/sgx directory itself. How do I get the appropriate
> > > > mode for it?
> > > >
> > > 
> > > Hi Greg-
> > > 
> > > Do you know this one?
> > 
> > I guess one option is to not do anything with the mode but instead
> > contribute rules to udev? I'm not too familiar with this but maybe
> > that is even recommended way?
> 
> Why do you care about the directory permissions?  They should not
> matter, only the permissions on the device nodes themselves, right?

OK, based on your response to Andy I don't :-)

Thanks.

/Jarkko