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

From: Alexander Graf
Date: Tue May 26 2020 - 08:44:32 EST

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


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