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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200526131708.GA9296@kroah.com>
Date:   Tue, 26 May 2020 15:17:08 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Alexander Graf <graf@...zon.de>
Cc:     Andra Paraschiv <andraprs@...zon.com>,
        linux-kernel@...r.kernel.org,
        Anthony Liguori <aliguori@...zon.com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Colm MacCarthaigh <colmmacc@...zon.com>,
        Bjoern Doebel <doebel@...zon.de>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Frank van der Linden <fllinden@...zon.com>,
        Martin Pohlack <mpohlack@...zon.de>,
        Matt Wilson <msw@...zon.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Balbir Singh <sblbir@...zon.com>,
        Stefano Garzarella <sgarzare@...hat.com>,
        Stefan Hajnoczi <stefanha@...hat.com>,
        Stewart Smith <trawets@...zon.com>,
        Uwe Dannowski <uwed@...zon.de>, kvm@...r.kernel.org,
        ne-devel-upstream@...zon.com
Subject: Re: [PATCH v3 07/18] nitro_enclaves: Init misc device providing the
 ioctl interface

On Tue, May 26, 2020 at 02:44:18PM +0200, Alexander Graf wrote:
> 
> 
> 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.

Ok, what's wrong with that?

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

But having the admin define that at module load / boot time, is a major
pain.  What tools do they have that allow them to do that easily?

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

You already are using ioctls to control this thing, right?  What's wrong
with "one more"? :)

> Other options I can think of:
> 
>   * sysctl (for modules?)

Ick.

>   * module parameter (as implemented here)

Ick.

>   * proc file (deprecated FWIW)

Ick.

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

But it takes more than jus this initial "split up" to set the pool up,
right?  Why not make this part of that initial process?  What makes this
so special you have to do this at module load time only?

thanks,

greg k-h