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: <eb696213-b066-0b6f-19ff-dd655b13209c@intel.com>
Date:   Tue, 18 Jan 2022 12:59:38 -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>,
        Nathaniel McCallum <nathaniel@profian.com>
CC:     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: <YeHwzwnfsUcxiNbw@iki.fi>
 <b0e5c1fc-aa6d-4e26-c18b-d93d93c2131a@intel.com> <YeIEKayEUidj0Dlb@iki.fi>
 <6e1cb295-b86e-ae09-2cf0-cfefd1a10e65@intel.com> <YeIU6e6wetrifn+b@iki.fi>
 <e2d675f7-319b-4816-ad5e-4154cbf69f2b@intel.com> <YeIgzLzPu0U8s0sh@iki.fi>
 <YeK2hFcy72tYL61S@iki.fi>
 <CAHAy0tT7+AwgQUtzndj1E99hVcHNmyk2xJ6wUSxa4oPYytAMzA@mail.gmail.com>
 <YeYe/gGQbtTAXxLe@iki.fi> <YeYkdUHt7/HsRsZq@iki.fi>
From:   Reinette Chatre <reinette.chatre@intel.com>
In-Reply-To: <YeYkdUHt7/HsRsZq@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?ME5zcnppeVlKaGdMS0diQU92ODRqQnAyTUFTdEdqdTVsVmk2bWpTazhIekVx?=
 =?utf-8?B?bWxNTDlGYS9ONzRaaklGZFZ3RGI4dG9JSGc3WmJycWI1U1FnLzRjUndhSVNK?=
 =?utf-8?B?Rk5KbGVvdzY5ZXR0WTdvcHc0OXFUcVlHL200bWpJdjBOWllkNEM0Qm8zUlNy?=
 =?utf-8?B?cDVXSlQwbUxTeXhQa1RpR3dkRGhXS2JrTUhSQnc5cGJWRFA1R1prSU9mZzZ6?=
 =?utf-8?B?R29TRGI3KytWY01veUJmdTQyN3J5VzVTYWRaNEFhYTRRb2EyMGc2UzUrVG5h?=
 =?utf-8?B?UmxBMVNHRG0wcFgxVUtvQlEyWFRHMnZDdVhBY01SVmdxNFJtc20wdjJKbWd1?=
 =?utf-8?B?T2Z1SEdTVjRtT3h2VVFpVVQ5S2xWN1VYeGFTRmhQZjlETzZObm1TVHdIUm84?=
 =?utf-8?B?YWloVlI4Mm9LS2lPa3JFUlJWWG10UldUa3g3RHhGZFllYzF2L2J6bzd0Ujd6?=
 =?utf-8?B?ZmRObTBWSDY3RmxsN0pLT3lxQUxsaWt4dXYyOHNtakdkTlhPUTNWN1hhdFFl?=
 =?utf-8?B?c2ZKYmVVRGttYyttSk5NdGJoc1lWbUdVRGRyVzhWVytQNzMyaHhCY1E3N2JC?=
 =?utf-8?B?bW45Zkt5V3VuRHplWjRCbERza0dMcXdaNHpBVnhOL0NqWW9veXkzT0J1Z00x?=
 =?utf-8?B?cjZMZlE5OFZYdTlXbkhtcXA0dHMvaDBhdUl4cFBlYVFRaHoyRTd1WCtGL1oz?=
 =?utf-8?B?ZVhMeFl3S1k4c2k4MlliK04wZktidjE0SldTS1B2aXNsbWhHM0VZeTFxNlBF?=
 =?utf-8?B?cHZqMkpFUXVNUDB1cGxsK2FNakdlcEZqVmJoTjBpS1dYeW9JWFpYbnlMOHR1?=
 =?utf-8?B?T0FhY1ZMU2ZWSjh6bFZjRTZaR29PSVBWREdhWHNWQlV2bXlpZGlDU1d6NFRv?=
 =?utf-8?B?NUtESVB4RkxhbTMxeE03U1lCRE1nUGxnbUVrWE5VT2hDUDJMQkJiNEwza25a?=
 =?utf-8?B?eXNOR2hRS2puWXdNSG12eFRmY3E1U3hOc2RuMUdnem4ya1M0MWlRWVFLaGVx?=
 =?utf-8?B?ZUxFSTdreFlReGxaRG1SVkNSZ1IrK2hHanlyNm1kZXFCQUl1UlFkYlNsOVBq?=
 =?utf-8?B?UklsQ2JaZnFTODNpSmNHeVZzVFVUcWMyc3FmQnpwbER4NldqUW5vYitvQWlV?=
 =?utf-8?B?OGV3MEtZOUVoTjZHaWlzOXh3UTFRVUlrOW95TGczVzlqb05OeXN2MmNZRGd6?=
 =?utf-8?B?WFMrUTZ1TGxvdGtVS1poY2lvclB6Sis5eWc0dXk4bXNYTEFrMmtTS1NZSU1P?=
 =?utf-8?B?VDllUFJaS3ZNcWtkcGdmNUN6UUJSTGw1dXpRZ1ZqaVlmWmJYdS9QL1hKOExk?=
 =?utf-8?B?QXk3RHI4N3VuWk9uczNYeTFrM0cyL1FoRW51VlRLMldDRGE3a0N3UHJES1Nx?=
 =?utf-8?B?Y2pOWGQ0SmpBUjk4cGg4eEo2WTdUY2VUZTFkMWRWRXhzTTQ1aUpIUk54NXdG?=
 =?utf-8?B?YmpxL1hBTDdLSjZORzhHWUpSNEdPMnpnSzlFWlBGVitCNEdTZUg1NjluWC9r?=
 =?utf-8?B?N0paK3dUQlFta2E5a0ExNGtTOGpJTkd6R0lrVDh6WXV4SFlDS2NRODRjVUpX?=
 =?utf-8?B?b0kxemZERHFOTHZRdGFvbjdGb1pjSHBDSmhXUDlSR3BmNEMzOGZnZWZyMXIr?=
 =?utf-8?B?YnArVXA3ak1NYlF4eDQ0Z1pmYm9tUGhRT29tR2ZpcXkxb2NJOWo2NVZzei80?=
 =?utf-8?B?V1k4MklDanVaL1RIcXdIZUUrdHd0T1htT0V1ckd6SzVadlVYNWI5cEovb2RT?=
 =?utf-8?B?MFYwaVhYb1ozMXIrcURGRGZzcGRaK0xKb0dKcjVudGQwUk9kR0xpRkF5VEll?=
 =?utf-8?B?WnZ4SXJPb2o3Q1p4OWNXVnRteTZMNmtOa2hwR01XY2tqRGp6YWdEK2ZzTzU2?=
 =?utf-8?B?eVVLV0ZNODk5MmlEbmREc1lJc2FTRjZzVUc0UFNoY0VZR2xnNEU5Z3NnTy8y?=
 =?utf-8?B?Y2tFVENpcG11bUdIOURnYlZmOGZXYXYwNzczVDZMOFVVdmJzR1U1MU9mSmhD?=
 =?utf-8?B?cWdCN3ZYcmhXdTA2TmxSRVliT1YvVGdDbGpZNnliUi9nQ3FuQUFnZm1Vc2tv?=
 =?utf-8?B?blkyV3pIc2NiamRzempReEFkNElKbjU0QThBbDVUR3RlYnpVWUtBOEZyRFFC?=
 =?utf-8?B?QUYxRjBHaHY3M1dmZ0dSY3hKc3FJcHV0NEprOUVPOExSVzZlZ2ViMlRkK05C?=
 =?utf-8?B?RDRsb2FTTzFDNG14KzF0RGxXTFlKRk50VStjMSs3eTJnSFVJcGJISkhoemhK?=
 =?utf-8?B?TmI3YWFzdm16ME9xTkR6amhBN3dRPT0=?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 88b56cb4-186a-4fdc-3b6b-08d9dac573a8
X-MS-Exchange-CrossTenant-AuthSource: BN0PR11MB5744.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2022 20:59:43.7983
 (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: JnubZ56jKRWwerY/aaAzZThY4zTijFBf6s6ZsDUGGqdDBUU7g0+HHDVz2FAKxfrxCFoiuuArSlKAIOrtMGNpk/8ghJcIIQvBHSOJHGzXlJg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3550
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/17/2022 6:22 PM, Jarkko Sakkinen wrote:
> On Tue, Jan 18, 2022 at 03:59:29AM +0200, Jarkko Sakkinen wrote:
>> On Mon, Jan 17, 2022 at 08:13:32AM -0500, Nathaniel McCallum wrote:
>>> On Sat, Jan 15, 2022 at 6:57 AM Jarkko Sakkinen <jarkko@kernel.org> wrote:
>>>>
>>>> On Sat, Jan 15, 2022 at 03:18:04AM +0200, Jarkko Sakkinen wrote:
>>>>> On Fri, Jan 14, 2022 at 04:41:59PM -0800, Reinette Chatre wrote:
>>>>>> Hi Jarkko,
>>>>>>
>>>>>> On 1/14/2022 4:27 PM, Jarkko Sakkinen wrote:
>>>>>>> On Fri, Jan 14, 2022 at 04:01:33PM -0800, Reinette Chatre wrote:
>>>>>>>> Hi Jarkko,
>>>>>>>>
>>>>>>>> On 1/14/2022 3:15 PM, Jarkko Sakkinen wrote:
>>>>>>>>> On Fri, Jan 14, 2022 at 03:05:21PM -0800, Reinette Chatre wrote:
>>>>>>>>>> Hi Jarkko,
>>>>>>>>>
>>>>>>>>> How enclave can check a page range that EPCM has the expected permissions?
>>>>>>>>
>>>>>>>> Only way to change EPCM permissions from outside enclave is to run ENCLS[EMODPR]
>>>>>>>> that needs to be accepted from within the enclave via ENCLU[EACCEPT]. At that
>>>>>>>> time the enclave provides the expected permissions and that will fail
>>>>>>>> if there is a mismatch with the EPCM permissions (SGX_PAGE_ATTRIBUTES_MISMATCH).
>>>>>>>
>>>>>>> This is a very valid point but that does make the introspection possible
>>>>>>> only at the time of EACCEPT.
>>>>>>>
>>>>>>> It does not give tools for enclave to make sure that EMODPR-ETRACK dance
>>>>>>> was ever exercised.
>>>>>>
>>>>>> Could you please elaborate? EACCEPT is available to the enclave as a tool
>>>>>> and it would fail if ETRACK was not completed (error SGX_NOT_TRACKED).
>>>>>>
>>>>>> Here is the relevant snippet from the SDM from the section where it
>>>>>> describes EACCEPT:
>>>>>>
>>>>>> IF (Tracking not correct)
>>>>>>     THEN
>>>>>>         RFLAGS.ZF := 1;
>>>>>>         RAX := SGX_NOT_TRACKED;
>>>>>>         GOTO DONE;
>>>>>> FI;
>>>>>>
>>>>>> Reinette
>>>>>
>>>>> Yes, if enclave calls EACCEPT it does the necessary introspection and makes
>>>>> sure that ETRACK is completed. I have trouble understanding how enclave
>>>>> makes sure that EACCEPT was called.
>>>>
>>>> I'm not concerned of anything going wrong once EMODPR has been started.
>>>>
>>>> The problem nails down to that the whole EMODPR process is spawned by
>>>> the entity that is not trusted so maybe that should further broke down
>>>> to three roles:
>>>>
>>>> 1. Build process B
>>>> 2. Runner process R.
>>>> 3. Enclave E.
>>>>
>>>> And to the costraint that we trust B *more* than R. Once B has done all the
>>>> needed EMODPR calls it would send the file descriptor to R. Even if R would
>>>> have full access to /dev/sgx_enclave, it would not matter, since B has done
>>>> EMODPR-EACCEPT dance with E.
>>>>
>>>> So what you can achieve with EMODPR is not protection against mistrusted
>>>> *OS*. There's absolutely no chance you could use it for that purpose
>>>> because mistrusted OS controls the whole process.
>>>>
>>>> EMODPR is to help to protect enclave against mistrusted *process*, i.e.
>>>> in the above scenario R.
>>>
>>> There are two general cases that I can see. Both are valid.
>>>
>>> 1. The OS moves from a trusted to an untrusted state. This could be
>>> the multi-process system you've described. But it could also be that
>>> the kernel becomes compromised after the enclave is fully initialized.
>>>
>>> 2. The OS is untrustworthy from the start.
>>>
>>> The second case is the stronger one and if you can solve it, the first
>>> one is solved implicitly. And our end goal is that if the OS does
>>> anything malicious we will crash in a controlled way.
>>>
>>> A defensive enclave will always want to have the least number of
>>> privileges for the maximum protection. Therefore, the enclave will
>>> want the OS to call EMODPR. If that were it, the host could just lie.
>>> But the enclave also verifies that the EMODPR operation was, in fact,
>>> executed by doing EACCEPT. When the enclave calls EACCEPT, if the
>>> kernel hasn't restricted permissions then we get a controlled crash.
>>> Therefore, we have solved the second case.
>>
>> So you're referring to this part of the SDM pseude code in the SDM:
>>
>> (* Check the destination EPC page for concurrency *)
>> IF ( EPC page in use )
>>     THEN #GP(0); FI;
>>
>> I wonder does "EPC page in use" unconditionally trigger when EACCEPT
>> is invoked for a page for which all of these conditions hold:
>>
>> - .PR := 0 (no EMODPR in progress)
>> - .MODIFIED := 0 (no EMODT in progress)
>> - .PENDING := 0 (no EMODPR in progress)
>>
>> I don't know the exact scope and scale of "EPC page in use".
>>
>> Then, yes, EACCEPT could be at least used to validate that one of the
>> three operations above was requested. However, enclave thread cannot say
>> which one was it, so it is guesswork.
> 
> OK, I got it, and this last paragraph is not true. SECINFO given EACCEPT
> will lock in rest of the details and make the operation deterministic.

Indeed - so the SDM pseudo code that is relevant here can be found under
the "(* Verify that accept request matches current EPC page settings *)"
comment where the enclave can verify that all EPCM values are as they should
and would fail with SGX_PAGE_ATTRIBUTES_MISMATCH if there is anything
amiss.

> 
> The only question mark then is the condition when no requests are active.

Could you please elaborate what you mean with this question? If no request
is active then I understand that to mean that no request has started. 

Reinette