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;
Message-ID: <6e249d49-eb03-e435-697d-8006c308b8ba@intel.com>
Date:   Tue, 18 Jan 2022 13:18:14 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 Thunderbird/91.5.0
Subject: Re: [PATCH 05/25] x86/sgx: Introduce runtime protection bits
Content-Language: en-US
To:     Jarkko Sakkinen <jarkko@kernel.org>
CC:     Nathaniel McCallum <nathaniel@profian.com>,
        Haitao Huang <haitao.huang@linux.intel.com>,
        Andy Lutomirski <luto@kernel.org>,
        <dave.hansen@linux.intel.com>, <tglx@linutronix.de>,
        <bp@alien8.de>, <mingo@redhat.com>, <linux-sgx@vger.kernel.org>,
        <x86@kernel.org>, <seanjc@google.com>, <kai.huang@intel.com>,
        <cathy.zhang@intel.com>, <cedric.xing@intel.com>,
        <haitao.huang@intel.com>, <mark.shanahan@intel.com>,
        <hpa@zytor.com>, <linux-kernel@vger.kernel.org>
References: <op.1fsvkfiwwjvjmi@hhuan26-mobl1.mshome.net>
 <YdzjEzjF0YKn+pZ6@iki.fi> <4195402f-cbf9-bc75-719d-22cea8e36e60@intel.com>
 <Yd9pMq4lUy56B+50@iki.fi> <Yd9qmMx7NO450mzZ@iki.fi>
 <CAHAy0tRi2q+wG+yBttq0FYeK-5wUAoK_=ZCtWsfQf0m8oPc1-w@mail.gmail.com>
 <168fb2c9-de3f-384a-bb17-ab84db2cf533@intel.com> <YeHwzwnfsUcxiNbw@iki.fi>
 <b0e5c1fc-aa6d-4e26-c18b-d93d93c2131a@intel.com> <YeIEKayEUidj0Dlb@iki.fi>
 <YeL7ID70Wg22MGCY@iki.fi>
From:   Reinette Chatre <reinette.chatre@intel.com>
In-Reply-To: <YeL7ID70Wg22MGCY@iki.fi>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RlIrOGJwaVRUQUR6QmRyZnVPUWR6QTMyYzZhVFFMMjFaTzJ2c3EweGMrWVFv?=
 =?utf-8?B?clE3eUsvVDBxaS9Qb202OWV5UDJoZmN0SEdFd0pOaVFXSkNOamtSSW5FWkpq?=
 =?utf-8?B?RVdsaVV2elBDZUUyU1R1SExaeVVJU0xTa2ZZemF6amx4VkZ0ZU1SZXAwZ3FY?=
 =?utf-8?B?Yzd5S1dKVDdYMHNFcTZpaTJIZWFLcWtxM1NEWGJuRXpTUyt1aU5TNkZsN1RM?=
 =?utf-8?B?dDI4UjJ3bmk0WnpZYTdVYnluN01YMzFNUWdRS0FqSUZ4UWpXaC9EVXlpS09M?=
 =?utf-8?B?ZHpLNVY0elpMR0Jpb3RmZWluNG5XNVgwby9EUkxCRUhpYmJUSWFYN1BEcVlz?=
 =?utf-8?B?NkxwMllRMHkrbk11emlIbDJ0YkNPVkgralpOQ2FscmJ0REQyQkVJMDJOZzFG?=
 =?utf-8?B?MU9nMTlVbCt2V3oxdmdhMFRHckhqYmhXQldaeVR4bFg5NXNoK1FEdDdxS0dR?=
 =?utf-8?B?amJGMEoxOUdzV0grMERsK0xDQTJScFM1M0FjZ1huenIzTnN2Vk9oYUVWTkpS?=
 =?utf-8?B?Ulg1NkxKUDZFNTNPTUdTMXhTUktLYzFpWUhRanJadWtDbDRrNi9uS3dmcFVi?=
 =?utf-8?B?cEVWc2tScTZmOHZVNUd2dXZDVE5iZVBFRnUxNGlUaTAvcnlubUJ1UVJxSFE0?=
 =?utf-8?B?U3VHQXdtMnpkS0txZE93VUlzL3FmaG1nK1AzdmZheWNKV3JPWGZMTWQzNTlW?=
 =?utf-8?B?M2gwV2xnNDlmM1ZXN1VCTFFKSUMwYmhVcFV3aDN1VlA1STFVK01Fekp2OU9L?=
 =?utf-8?B?NUd5UDB2ayttMjRrZTNvQnJ2VUV6QklQMjBkenpOK2MxN08zK3pwTGs0bndO?=
 =?utf-8?B?N1VGSmFPT2dWa2FoUnJpckRHUlRHejNjTkZkL0lDbmJXT2RWN0tBYkJTcThE?=
 =?utf-8?B?T2hsUktBTW1LcW1yVTNoSjFzMHZjVlJlZGx3S21pTWprUitoU2VMUU9yYkpn?=
 =?utf-8?B?bjlkYmhKZ3VPUFV1YWF6LytxM0wxWjhXLzRVVnYzREJSelRnNzBJSmErVGFT?=
 =?utf-8?B?eG1oZmRFV3dZd0JaZGQyZTNHU0dXT2xMNUs5MWI5RlNySTFQeEZCcVcrakxH?=
 =?utf-8?B?SEFhajZyYVY3OVllWkw4TFMvdzFwUFdiejh4dVVwbGRRbDkwSUQzbDQycTQz?=
 =?utf-8?B?Uy90cFhIMWZKVUJkeGhVQTNxOFR0S1ROOVEwRmhZSnR2YUhhdEVpRUxrcGtC?=
 =?utf-8?B?cHpDaXpwK3FUVlJNSEU3MnZERWt2dkRDeko3eGl1QW1YYXo0QVo2L3pGWGwz?=
 =?utf-8?B?M2NRanVaYmZtUnNFejJRY0Vtczh1YWw5ellJNG1LaGx6S3RZYTJqNi90Qk9l?=
 =?utf-8?B?TC82NnlxWWE5bFRwZi9Ib1dUbFlBYmJ2dVBrZHNwcEs5MVdjcDMwbG9OdU5t?=
 =?utf-8?B?VjM5c3UvYlE0QTdMSTcyTThxaEYybk1xUEhHbkt3RHViSjhkU0luWjlVY3dt?=
 =?utf-8?B?UjN2bDQrQjJoSWJGSy80ODdqK0dVNXI2eVpLMllXL1dJK1JMSU51enRDTkpC?=
 =?utf-8?B?SzRMYkJVR0U1d01WOFVnMlZpM1RqSGtmdms4M0dGdTB6cUpFSHhXNXBQRERj?=
 =?utf-8?B?Mlk0TWdvOGZmMEhxMTlvUkFVRUhqeVNpbGhEcmYwblVCUFBDRHk4MUgxbHlL?=
 =?utf-8?B?L3VFdmRCa1FCMGl6WC9tVWx6d3dlV05VVFBGTklQaHVuNTNWTEUycEw0UlYr?=
 =?utf-8?B?Q01iWmhHVXplbHUrOUVDdldicWcvckNjeUpEZlpWQytreWp1T1ZjeEpxZUVS?=
 =?utf-8?B?NlVYanJCNUo0MnphejErTVIwN0NKaE93Si9sZWRoSHRTMTJFdjBlTWxLOTB6?=
 =?utf-8?B?eTl1REczR0k5ZldsOThVSnYyakZvMVMvY2xXRzJIanpJQ0FQanpZNERQamZi?=
 =?utf-8?B?NWh0RVhBaUpDb0gyUkpRdkJEcFZvRzBSNndtS2ZhbWlVSVRMRGNTVmNySUR4?=
 =?utf-8?B?TE1aOEtBbzRNWVJFSXU5c3F2UUZHN1MxV01PejlSRXhWSEtRaXRKOWZGWERh?=
 =?utf-8?B?Y0ZONmVtMytZT1hTbHBMTkpjUElyWGpwNE1NTm9DVkV5RUdrWDZOZ2t5cXRR?=
 =?utf-8?B?WnBOT0pkNkRHN1RzVTNQZjlqekpPc2wraFR6R3VCL3dOL2RudVZKWHZOWFJU?=
 =?utf-8?B?aEVFUVptMG1UWU9TQUR4bHA4YW5JekZsY0grZTdFVHliNzlHR1JMMEM3d3RM?=
 =?utf-8?B?OEV2L2h2MkRMMXkxVFpHb21sQ1dqNElPaFJZN0NPczRjM0hzS2g0d1RYRWx1?=
 =?utf-8?Q?T6TAu/rgqNkQ77/5NDQfgDCAUavM18My6CUpO6f5Cg=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 16335d59-0a76-473c-fca2-08d9dac80cf8
X-MS-Exchange-CrossTenant-AuthSource: BN0PR11MB5744.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2022 21:18:19.9656
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: e7BqNPQ5kCB8ulDv9nvMiWTFxm4XbBocF3p1a9NCk9PwvCw+eWYyL18eo8n3rElxJbxtqjZPkPnAU/FQzTknFXkWak561iOykO6Z6SWpqXk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1101MB2168
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Jarkko,

On 1/15/2022 8:49 AM, Jarkko Sakkinen wrote:
> On Sat, Jan 15, 2022 at 01:15:53AM +0200, Jarkko Sakkinen wrote:
>>> After running ENCLU[EMODPE] user space uses SGX_IOC_ENCLAVE_MOD_PROTECTIONS
>>
>> OK, great.
>>
>> A minor nit: please call it SGX_IOC_ENCLAVE_MODIFY_PROTECTIONS. 
> 
> I'm not confident after looking through the test case and ioctl
> about EMODPE support but I do not want disturb this anymore. Bunch
> of things have been nailed and I'm now running the code, which is
> great.
> 
> The obviously wrong implementation choice in this ioctl is that
> it is multi-function. It should be just split it into two ioctls:
> sgx_restrict_page_permissions and sgx_extend_page_permissions.

Sure, I can move it to two ioctls.

To keep the naming consistent, what do you think of:
SGX_IOC_ENCLAVE_RESTRICT_PERMISSIONS
SGX_IOC_ENCLAVE_RELAX_PERMISSIONS

Please refer to message below as motivation for the "relax" term:
https://lore.kernel.org/lkml/24447a03-139a-c7e0-9ad5-34e2019c4df5@intel.com/

> 
> They are conceptually different flows and I'm also basing this on earlier
> discussion in this mailing list from which I conclude that it is also
> consensus to not have such ioctls.
> 
> Might sound clanky but it is much easier to comprehend what is going
> on "in the blackbox" by doing that split.

Reinette