Messages in this thread | | | Subject | Re: [PATCH v3 07/18] nitro_enclaves: Init misc device providing the ioctl interface | From | Alexander Graf <> | Date | Tue, 26 May 2020 14:44:18 +0200 |
| |
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
| |