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]

Date:   Tue, 26 May 2020 14:44:18 +0200
From:   Alexander Graf <graf@...zon.de>
To:     Greg KH <gregkh@...uxfoundation.org>
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 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