Re: [PATCH v3 07/18] nitro_enclaves: Init misc device providing the ioctl interface

[Alexander Graf]

On 26.05.20 14:33, Greg KH wrote:
> On Tue, May 26, 2020 at 01:42:41PM +0200, Alexander Graf wrote:
> > On 26.05.20 08:51, Greg KH wrote:
> > > On Tue, May 26, 2020 at 01:13:23AM +0300, Andra Paraschiv wrote:
> > > > +#define NE "nitro_enclaves: "
> > >
> > > Again, no need for this.
> > >
> > > > +#define NE_DEV_NAME "nitro_enclaves"
> > >
> > > KBUILD_MODNAME?
> > >
> > > > +#define NE_IMAGE_LOAD_OFFSET (8 * 1024UL * 1024UL)
> > > > +
> > > > +static char *ne_cpus;
> > > > +module_param(ne_cpus, charp, 0644);
> > > > +MODULE_PARM_DESC(ne_cpus, "<cpu-list> - CPU pool used for Nitro Enclaves");
> > >
> > > Again, please do not do this.
> >
> > I actually asked her to put this one in specifically.
> >
> > The concept of this parameter is very similar to isolcpus= and maxcpus= in
> > that it takes CPUs away from Linux and instead donates them to the
> > underlying hypervisor, so that it can spawn enclaves using them.
> >
> >  From an admin's point of view, this is a setting I would like to keep
> > persisted across reboots. How would this work with sysfs?
>
> How about just as the "initial" ioctl command to set things up?  Don't
> grab any cpu pools until asked to.  Otherwise, what happens when you
> load this module on a system that can't support it?

That would give any user with access to the enclave device the ability 
to remove CPUs from the system. That's clearly a CAP_ADMIN task in my book.

Hence this whole split: The admin defines the CPU Pool, users can safely 
consume this pool to spawn enclaves from it.

So I really don't think an ioctl would be a great user experience. Same 
for a sysfs file - although that's probably slightly better than the ioctl.

Other options I can think of:

  * sysctl (for modules?)
  * module parameter (as implemented here)
  * proc file (deprecated FWIW)

The key is the tenant split: Admin sets the pool up, user consumes. This 
setup should happen (early) on boot, so that system services can spawn 
enclaves.

> module parameters are a major pain, you know this :)

I think in this case it's the least painful option ;). But I'm really 
happy to hear about an actually good alternative to it. Right now, I 
just can't think of any.


Alex



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879