Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: ZJxFfgJt1AZkClFw3ZY2WYtqsW/2tgXRj/umqXjSX38xkaG3I8QJbXMb/HXO+uedk0djCO/fao
 3yySW1m/9wzg==
Subject: Re: [PATCH v3 07/18] nitro_enclaves: Init misc device providing the
 ioctl interface
To:     Greg KH <gregkh@linuxfoundation.org>
CC:     Andra Paraschiv <andraprs@amazon.com>,
        <linux-kernel@vger.kernel.org>,
        Anthony Liguori <aliguori@amazon.com>,
        Benjamin Herrenschmidt <benh@kernel.crashing.org>,
        Colm MacCarthaigh <colmmacc@amazon.com>,
        "Bjoern Doebel" <doebel@amazon.de>,
        David Woodhouse <dwmw@amazon.co.uk>,
        "Frank van der Linden" <fllinden@amazon.com>,
        Martin Pohlack <mpohlack@amazon.de>,
        "Matt Wilson" <msw@amazon.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Balbir Singh <sblbir@amazon.com>,
        Stefano Garzarella <sgarzare@redhat.com>,
        "Stefan Hajnoczi" <stefanha@redhat.com>,
        Stewart Smith <trawets@amazon.com>,
        "Uwe Dannowski" <uwed@amazon.de>, <kvm@vger.kernel.org>,
        <ne-devel-upstream@amazon.com>
References: <20200525221334.62966-1-andraprs@amazon.com>
 <20200525221334.62966-8-andraprs@amazon.com>
 <20200526065133.GD2580530@kroah.com>
 <72647fa4-79d9-7754-9843-a254487703ea@amazon.de>
 <20200526123300.GA2798@kroah.com>
From:   Alexander Graf <graf@amazon.de>
Message-ID: <59007eb9-fad3-9655-a856-f5989fa9fdb3@amazon.de>
Date:   Tue, 26 May 2020 14:44:18 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <20200526123300.GA2798@kroah.com>
Content-Language: en-US
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


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 Encla=
ves");
>>>
>>> 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=3D and maxcpus=
=3D 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