[lkml]   [2020]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v3 07/18] nitro_enclaves: Init misc device providing the ioctl interface

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"
>>>> +#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

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


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

 \ /
  Last update: 2020-05-26 14:44    [W:0.175 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site