Received-SPF: pass (google.com: domain of linux-kernel+bounces-176302-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <4422e302-5802-451b-9daf-09d7668099e3@intel.com>
Date: Fri, 10 May 2024 16:47:23 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/2] x86/sgx: Resolve EAUG race where losing thread
 returns SIGBUS
To: Dmitrii Kuvaiskii <dmitrii.kuvaiskii@intel.com>, <jarkko@kernel.org>
CC: <dave.hansen@linux.intel.com>, <haitao.huang@linux.intel.com>,
	<kai.huang@intel.com>, <kailun.qin@intel.com>,
	<linux-kernel@vger.kernel.org>, <linux-sgx@vger.kernel.org>,
	<mona.vij@intel.com>, <mwk@invisiblethingslab.com>, <stable@vger.kernel.org>
References: <D0WMM3MYQODE.3A89L7D6OVG3E@kernel.org>
 <20240430143701.902597-1-dmitrii.kuvaiskii@intel.com>
Content-Language: en-US
From: Reinette Chatre <reinette.chatre@intel.com>
In-Reply-To: <20240430143701.902597-1-dmitrii.kuvaiskii@intel.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?R0IzVWdMWkR5cHUwVUJtbzFNNXFDUHFpYmttOHlQK1V0Smd4cEJmOUlIQnpo?=
 =?utf-8?B?Y0JqM3hUWDRKUFR4eUpXRDk5eml3M2VRVFIzVFVENi8xQWFvQ0NBdFREeG15?=
 =?utf-8?B?MmhXeEhhUEtVTHpJSmY5K2FKNzhtSzYwcERxcjFTZWErWHVPMUVoN3RKM0NX?=
 =?utf-8?B?YmVjU0ZMWHlFVmdNT2p6U2wvQmpzQmwwaC9NVmdaZEtSMW5MbjdZV0tqM0Zl?=
 =?utf-8?B?S1c0THJJZnlkY3dkdmxmOGkwMkxZM21kNC8vcHZ6SWdxYmN3QkpHSk5GbTV1?=
 =?utf-8?B?N1FZL21GTEQyR1ovOFUyWWV6VVRjbGxFY2NGR3NLby9JcjhBRXFOWjE1Y2xO?=
 =?utf-8?B?Yk5mUHVjYjhVUHN3ZTY4d2ZTMlZYd2U5SVZPeXFlT1BSZllaZ2FIOUpDcHdx?=
 =?utf-8?B?eWNoMUFNVFZPQWx1bHpKTk9YUk13S2xRVXhZdy9QSStjU3RrQ0lJN1duV05x?=
 =?utf-8?B?Q0VlZUdaaHl0SmZWOXFsblI0MXh6d3hYK09ML2hhL2hWRVJibnJHMlNDN3o0?=
 =?utf-8?B?OWxRRHhLNGxXMjJvSDlkZ0NFMldhMCsxVUllN09RNHBPQ2VteWtFZ3FxS1Zt?=
 =?utf-8?B?S1N0Q3drbHVhajVSY3p2M3JIbVJMRmtxeWgrSW9Ibmg0V0o4SGFiaFUwTURj?=
 =?utf-8?B?d0RQWUcxMWJheHdFYnJ3K0drS0RKQVRvYk9rTUVIUTNXZzI5YlVFaWxXSTNX?=
 =?utf-8?B?WHZ3T3VnSEJLVEsxdVBQeGdleDlZZzRsQkR6SElGRFpibENKZlRXUjJxK2ZY?=
 =?utf-8?B?M1I5L2F1TURnNDR5TDU2VTVTRi8xeHQyWWc2Y1pNdlJMMzNLVXR5RitweFQ2?=
 =?utf-8?B?aDIyRFhTbUc5dENpM2FVamQ0SUZuU0hFb3pLUXhSZVR0Z1pacXI4Nzc4ckpa?=
 =?utf-8?B?YmFQbHlVU0wxVG11Wk9FMEgwK2pTdFlmK2pacUxwWFk0TURub0hvQTI4NFNl?=
 =?utf-8?B?TVRrVjJZMld4TWlKZWZUL1dmRWpISkNBNEQ4dHdwNWdzdTlCNHhiRUlrQ0Yr?=
 =?utf-8?B?T0E4TThFZVR4NFNxblpxVmQxMkVxOXVYa0Q2YkhMa2VMMDF1N1NYT0YxU1NC?=
 =?utf-8?B?QXc2djVXWldUL2NkVkZjcnl6c3pPendDcmIycjhnYmVvdTRwN2xxRjZycGFj?=
 =?utf-8?B?V3d1aXFBNFByZmpUUlRXM3hmK2gzaUhoeW80c2ZlMHBzVWtkR1dXL0ZoOWhx?=
 =?utf-8?B?Yk5ZRjJqR050Nk5QTlo3YzlvdmR6dXhzQjVwdTFaWEowWks1bVFiV0RzR2dt?=
 =?utf-8?B?M3l5QTRlYzU0NGhYU3ltS09aOXpWNy9za0ZBK0pIZ2h3UE83VGdFcitrYnJV?=
 =?utf-8?B?bTJiaU1hN0dBbmtGYUtZMEozMUFwak1UV25oQVJNQ3F4ZW5OOU1zM3BKNHAz?=
 =?utf-8?B?Kzk2c1B3ZVVvSXh5SDRLZFY4K2dBRnk2VmIrbU9MYmxHdUlkN3hDL2U3c2NZ?=
 =?utf-8?B?UnlmTjNxM0xYNXNQcWVtY0pwRmFCQUprNXlXOW5sbTcrVmZYaVk3cDRKcmlB?=
 =?utf-8?B?Y0QzSlRMd3EwNkdNTUU1L09yUEl2YlBYWmRCODE1YmVSSkhTRDdRYlRsdmFP?=
 =?utf-8?B?c2ZaYitRYWhCeG0rT25WenlNMTdVUS82MUE5UnJYRWpCUG5FN2xkcDYwZXJF?=
 =?utf-8?B?TDZhSURuUUFrRHAzMlJIMU0rV1MyZDQrNjFJQ0FvSmRIMXR6OGpHTVU5WU1I?=
 =?utf-8?B?Um9GemY0ckpEaS9qRytLYVI3cC9JNUhFRWtscytJZ1FKdGZQWFdHWFFKSWgy?=
 =?utf-8?B?Y0dhUmlMRmRMYlV5elM2dFU0cG5STGFIV3dmOEMyQ1RzblNrd05DYzZ2Z0dX?=
 =?utf-8?B?YTBtZzBtWGx4L0pqQys4L3NGQXUyU25kTFlFZmtXdXRBbnJQRFc2YnphdjhX?=
 =?utf-8?B?ZTAzL2tFWkk4cTVYSHhkYTh6ZG9WUDA2ZHdDYXcrY2xsaUlzdEFRc0JzM3la?=
 =?utf-8?B?dGdzUWE4TTI2V3I0c3RlL28zejgyNTc0Vnc3bVlOWTJQNVVXQ0EwYXJ0SElu?=
 =?utf-8?B?UWF2NTY4SVBQVXRYSEtKeTZJRXJ3V2lDY1B2UllSVE9Uck9wb01EN1J4Mk9z?=
 =?utf-8?B?MFlteGh3bEhMVUlPS3pjQ0Y3d1ZmZ215WThNdy9vK0hVOFpIUHdoWU9NWXFR?=
 =?utf-8?B?REc2NjZsV0NVUHNXQkx1bzMyT29hYS9sZDlRV2ZRSlBFMVlyTW9LcllpRktC?=
 =?utf-8?B?b2c9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: a5436d15-02c9-4f7b-81b5-08dc714b8bb8
X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB7573.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 May 2024 23:47:26.2085
 (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: cK+4U5HtEukMafK7/7y9OWEAGsOxmfV1C8cwlIwehKgZCs4YpNF+wO9eBvk5ibkEKSDo8SS0oR5eLWpg9FtsohNjF0QRy7KMko/m+7wyWNY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4881
X-OriginatorOrg: intel.com

Hi Dmitrii,

Thank you so much for finding as well as fixing this issue.

On 4/30/2024 7:37 AM, Dmitrii Kuvaiskii wrote:
> On Mon, Apr 29, 2024 at 04:04:24PM +0300, Jarkko Sakkinen wrote:
>> On Mon Apr 29, 2024 at 1:43 PM EEST, Dmitrii Kuvaiskii wrote:
>>> Two enclave threads may try to access the same non-present enclave page
>>> simultaneously (e.g., if the SGX runtime supports lazy allocation). The
>>> threads will end up in sgx_encl_eaug_page(), racing to acquire the
>>> enclave lock. The winning thread will perform EAUG, set up the page
>>> table entry, and insert the page into encl->page_array. The losing
>>> thread will then get -EBUSY on xa_insert(&encl->page_array) and proceed
>>> to error handling path.
>>
>> And that path removes page. Not sure I got gist of this tbh.
> 
> Well, this is not about a redundant EREMOVE performed. This is about the
> enclave page becoming inaccessible due to a bug triggered with a data race.
> 
> Consider some enclave page not yet added to the enclave. The enclave
> performs a memory access to it at the same time on CPU1 and CPU2. Since the
> page does not yet have a corresponding PTE, the #PF handler on both CPUs
> calls sgx_vma_fault(). Scenario proceeds as follows:
> 
> /*
>  * Fault on CPU1
>  */
> sgx_vma_fault() {
> 
>   xa_load(&encl->page_array) == NULL ->
> 
>   sgx_encl_eaug_page() {
> 
>     ...                            /*
>                                     * Fault on CPU2
>                                     */
>                                    sgx_vma_fault() {
> 
>                                      xa_load(&encl->page_array) == NULL ->
> 
>                                      sgx_encl_eaug_page() {
> 
>                                        ...
> 

Up to here it may be helpful to have the CPU1 and CPU2 code run concurrently
to highlight the race. First one to get the mutex "wins".

>                                        mutex_lock(&encl->lock);
>                                        /*
>                                         * alloc encl_page
>                                         */

Please note that encl_page is allocated before mutex is obtained.

>                                        /*
>                                         * alloc EPC page
>                                         */
>                                        epc_page = sgx_alloc_epc_page(...);
>                                        /*
>                                         * add page_to enclave's xarray

"page_to" -> "page to" ?

>                                         */
>                                        xa_insert(&encl->page_array, ...);
>                                        /*
>                                         * add page to enclave via EAUG
>                                         * (page is in pending state)
>                                         */
>                                        /*
>                                         * add PTE entry
>                                         */
>                                        vmf_insert_pfn(...);
> 
>                                        mutex_unlock(&encl->lock);
>                                        return VM_FAULT_NOPAGE;
>                                      }
>                                    }

A brief comment under CPU2 essentially stating that this is a "good"
flow may help. Something like: "All good up to here. Enclave page successfully
added to enclave, ready for EACCEPT from user space". (please feel free to
improve)

>      mutex_lock(&encl->lock);
>      /*
>       * alloc encl_page
>       */

This should be outside mutex_lock(). It can even be shown earlier how
CPU1 and CPU2 can allocate encl_page concurrently (which is fine to do).

>      /*
>       * alloc EPC page
>       */
>      epc_page = sgx_alloc_epc_page(...);
>      /*
>       * add page_to enclave's xarray,

hmmm ... is page_to actually intended?

>       * this fails with -EBUSY

It may help to highlight that this failure is because CPU1 and CPU2 are both
attempting to access the same page thus the page was already added in CPU2 flow.

>       */
>      xa_insert(&encl->page_array, ...);
> 
>    err_out_shrink:
>      sgx_encl_free_epc_page(epc_page) {
>        /*
>         * remove page via EREMOVE
>         */

This needs emphasis that this is *BAD*. Something like:
"BUG: Enclave page added from CPU2 is yanked (via EREMOVE)
from enclave while it remains "accessible" from OS perspective 
PTE installed with entry in OS's page_array)."

(please feel free to improve)

>        /*
>         * free EPC page
>         */
>        sgx_free_epc_page(epc_page);
>      }
> 
>       mutex_unlock(&encl->lock);
>       return VM_FAULT_SIGBUS;

This needs emphasis that this is *BAD*. "BUG: SIGBUS is
returned for a valid enclave page."  (please feel free to
improve)

>     }
>   }
> 
> CPU2 added the enclave page (in pending state) to the enclave and installed
> the PTE. The kernel gives control back to the user space, without raising a
> signal. The user space on CPU2 retries the memory access and induces a page
> fault, but now with the SGX bit set in the #PF error code. The #PF handler
> calls do_user_addr_fault(), which calls access_error() and ultimately
> raises a SIGSEGV. The userspace SIGSEGV handler is supposed to perform
> EACCEPT, after which point the enclave page becomes accessible.
> 
> CPU1 however jumps to the error handling path because the page was already
> inserted into the enclave's xarray. This error handling path EREMOVEs the
> page and also raises a SIGBUS signal to user space. The PTE entry is not
> removed.
> 
> After CPU1 performs EREMOVE, this enclave page becomes perpetually
> inaccessible (until an SGX_IOC_ENCLAVE_REMOVE_PAGES ioctl). This is because
> the page is marked accessible in the PTE entry but is not EAUGed. Because
> of this combination, the #PF handler sees the SGX bit set in the #PF error

Which #PF handler are you referring to here?

> code and does not call sgx_vma_fault() but instead raises a SIGSEGV. The
> userspace SIGSEGV handler cannot perform EACCEPT because the page was not
> EAUGed. Thus, the user space is stuck with the inaccessible page.
> 
> Also note that in the scenario, CPU1 raises a SIGBUS signal to user space
> unnecessarily. This signal is spurious because a page-access retry on CPU2
> will also raise the SIGBUS signal. That said, this side effect is less
> severe because it affects only user space. Therefore, it could be
> circumvented in user space alone, but it seems reasonable to fix it in this
> patch.

The variety of the signals and how they could/should be handled by userspace
are not completely clear to me but the bugs are clear to me and needs to be
fixed.

>>> This error handling path contains two bugs: (1) SIGBUS is sent to
>>> userspace even though the enclave page is correctly installed by another
>>> thread, and (2) sgx_encl_free_epc_page() is called that performs EREMOVE
>>> even though the enclave page was never intended to be removed. The first
>>> bug is less severe because it impacts only the user space; the second
>>> bug is more severe because it also impacts the OS state by ripping the
>>> page (added by the winning thread) from the enclave.
>>>
>>> Fix these two bugs (1) by returning VM_FAULT_NOPAGE to the generic Linux
>>> fault handler so that no signal is sent to userspace, and (2) by
>>> replacing sgx_encl_free_epc_page() with sgx_free_epc_page() so that no
>>> EREMOVE is performed.
>>
>> What is the collateral damage caused by ENCLS[EREMOVE]?
> 
> As explained above, the damage is that the SGX driver leaves the enclave
> page metadata in an inconsistent state: on the one hand, the PTE entry is
> installed which forces the generic Linux fault handler to raise SIGSEGV,
> and on the other hand, the page is not in a correct state to be EACCEPTed
> (i.e., EAUG was not performed on this page).
> 
>>> Fixes: 5a90d2c3f5ef ("x86/sgx: Support adding of pages to an initialized enclave")
>>> Cc: stable@vger.kernel.org
>>> Reported-by: Marcelina Kościelnicka <mwk@invisiblethingslab.com>
>>> Suggested-by: Reinette Chatre <reinette.chatre@intel.com>
>>> Signed-off-by: Dmitrii Kuvaiskii <dmitrii.kuvaiskii@intel.com>
>>> ---
>>>  arch/x86/kernel/cpu/sgx/encl.c | 7 +++++--
>>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
>>> index 279148e72459..41f14b1a3025 100644
>>> --- a/arch/x86/kernel/cpu/sgx/encl.c
>>> +++ b/arch/x86/kernel/cpu/sgx/encl.c
>>> @@ -382,8 +382,11 @@ static vm_fault_t sgx_encl_eaug_page(struct vm_area_struct *vma,
>>>  	 * If ret == -EBUSY then page was created in another flow while
>>>  	 * running without encl->lock
>>>  	 */
>>> -	if (ret)
>>> +	if (ret) {
>>> +		if (ret == -EBUSY)
>>> +			vmret = VM_FAULT_NOPAGE;
>>>  		goto err_out_shrink;
>>> +	}
>>>  
>>>  	pginfo.secs = (unsigned long)sgx_get_epc_virt_addr(encl->secs.epc_page);
>>>  	pginfo.addr = encl_page->desc & PAGE_MASK;
>>> @@ -419,7 +422,7 @@ static vm_fault_t sgx_encl_eaug_page(struct vm_area_struct *vma,
>>>  err_out_shrink:
>>>  	sgx_encl_shrink(encl, va_page);
>>>  err_out_epc:
>>> -	sgx_encl_free_epc_page(epc_page);
>>> +	sgx_free_epc_page(epc_page);
>>
>> This ignores check for the page being reclaimer tracked, i.e. it does
>> changes that have been ignored in the commit message.
> 
> Indeed, sgx_encl_free_epc_page() performs the following check:
> 
>   WARN_ON_ONCE(page->flags & SGX_EPC_PAGE_RECLAIMER_TRACKED);
> 
> However, the EPC page is allocated in sgx_encl_eaug_page() and has
> zeroed-out flags in all error-handling paths. In other words, the page is
> marked as reclaimable only in the happy path of sgx_encl_eaug_page().
> Therefore, in the particular code path that I changed this "page reclaimer
> tracked" condition is always false, and the warning is never printed.
> 
> Do you want me to explain this in the commit message?

Since original commit did prompt this question I do think it would
be helpful to add a snippet about this, yes.

The fix looks good to me. I assume that you will add the "CPU1 vs CPU2"
race description in the next version, that will help a lot to make the
bugs easier to spot. 

Thanks again for this. Great catch.

Reinette