Received-SPF: pass (google.com: domain of linux-kernel+bounces-180099-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <149a736f-8817-400b-93e7-0059b71af9f0@intel.com>
Date: Wed, 15 May 2024 08:58:34 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/2] x86/sgx: Resolve EAUG race where losing thread
 returns SIGBUS
To: Dmitrii Kuvaiskii <dmitrii.kuvaiskii@intel.com>,
	<dave.hansen@linux.intel.com>, <jarkko@kernel.org>, <kai.huang@intel.com>,
	<haitao.huang@linux.intel.com>, <linux-sgx@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
CC: <mona.vij@intel.com>, <kailun.qin@intel.com>, <stable@vger.kernel.org>,
	=?UTF-8?Q?Marcelina_Ko=C5=9Bcielnicka?= <mwk@invisiblethingslab.com>
References: <20240515131240.1304824-1-dmitrii.kuvaiskii@intel.com>
 <20240515131240.1304824-2-dmitrii.kuvaiskii@intel.com>
Content-Language: en-US
From: Reinette Chatre <reinette.chatre@intel.com>
In-Reply-To: <20240515131240.1304824-2-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?cWJJUkR0Q1hQTit4dnBRVGFVRnI3akFGbHdwcXlGNGhqd2xCUmc3TXgrcDNW?=
 =?utf-8?B?VXlGVk56UUZNTjRYdjV5TURydnhSNmVBQzIwSUhPYjRneWRxOXlxNjR0QXcw?=
 =?utf-8?B?Z2hNUzVHT1Z5TC8rQi9wVmxwSUxHb2E1REpIQlh6RTE5ejNWcG8ydXRZTmxu?=
 =?utf-8?B?Q2tYaWhQL1BxVGhyU1gvNU15SHpiU0lOL0xlOWpPanl5Q01DSlBwbmxRaDlJ?=
 =?utf-8?B?L1lYZnFwNUFicFAzTFdSOVVSZmNWOHRlVEo1bHRZQTZ5Zm9hOTFhUkx2c0NO?=
 =?utf-8?B?elJubzNIRUlab0c0UWdmWmUzZWhQOHlIYThuZDdEdjFMUUN2eG1NVVN1WkRD?=
 =?utf-8?B?YUhOdXk2UnZVdW1qRjJpTFB2ZjJaZzNoQ0ZvcTNsaUxoRWZxVGc4QXoxb1ht?=
 =?utf-8?B?dWdobEZOazlKOHRvUGc1eWViSkFybmJGdjZ0dkJUL1JPOHNCOUJ3SURGaDEw?=
 =?utf-8?B?TVBoU1R1QnB0RDI1cXBCeC92MEpmWlhCV0ZrM3hJL2VGdmxXRmN1bExMMVBI?=
 =?utf-8?B?KytUYkRXb0VIVjBJVy9Jbnc1QzhNYzlHdm1NYXBxWExha2Y4azNHN0xMRWlE?=
 =?utf-8?B?OU1DU3FKaG84RXlUWkpiOUdnU0R1S2RCODVjNSsxeUhzN0wxeGJJY2VQbEg1?=
 =?utf-8?B?UFVRM3V0ZysvOFUxT0NFZmZEemhGUjhVUXZMaUVGS1BVUnpGTDdxbHM3bndL?=
 =?utf-8?B?Y0tRMkl3MEJDVlJYaEJhWmlRL2ZOU0JmZ0h0QURwNmVORkNtSnJEd1NuV0Qy?=
 =?utf-8?B?MEFvY0I0VTlPUlo5NFIxbUwyYWl1dHZLbThENkM1bVM5RFA1YnZSaDVrQlZQ?=
 =?utf-8?B?R1ltbm9rTHhsMHhqdE9Ca00waGJBcFA5dFNFWGc4ZUxEZndFS3lib2R3dng0?=
 =?utf-8?B?TXRUV2pDUStOOHdQVHVDMUVyajBQeWFvZ0wzNUtXV0dqTlp6U08xSkNXR05P?=
 =?utf-8?B?L3YrNGFSYkhiQ0I4KzhFS2dqeVphTHF5UXBwbHJsaUU0QmFFdDEzS2c2WC9q?=
 =?utf-8?B?bUpWR2Q1M0M1Y1VheVdZclN1d1YybUF4Vlc2MFIraHBxSVpZRGV0YTJyMTVo?=
 =?utf-8?B?aiswMUZkQm9VYUhrUXdVM3lUODhYN0FJTGJpaGFicUpoeDlYZUR0RDVXb2NW?=
 =?utf-8?B?R3k2WE90d1h5cUFaRDhXcExjRVl0UlQ2WFhHY3h5V3RGOU5aQStqQjJvbWxY?=
 =?utf-8?B?ZzFBYk1xR1hnaUp0ZDJ4WWNSL21iSWYxd1RtZUtMK0V5OWx3WTJhZlJ5SjhG?=
 =?utf-8?B?YUozeHBuaElmaEdZOFU3bzhDWmQybTMyNWFjSGhJaWdxTnZ0UzVmdUh0L1No?=
 =?utf-8?B?aittUVdnYVZSTmh4Vmc1MmYzUWxWRldHZ3gzNHJzbnVKR0xvRzVqSm0rOUhi?=
 =?utf-8?B?VGlVSmhFRHhObFFtMjcxekFmWHR3UXdVMXBWSTBTQ3FKZUhydEc1S0FNZTBz?=
 =?utf-8?B?QzdPZ3JQdXhVcER6aXp2bDd5U1ZmUnRTcnU2WlFBd1pjSjRTRTB2V0NmYkRX?=
 =?utf-8?B?OTN6WjRVcXV6NnI0YzYyWGZCRVFCVDhxMHVpbU14Z2VKUDJqSk1nWW9WVllp?=
 =?utf-8?B?NzN1VGxXRVBxc0Fac3BJWE1senppeWoxR1c4a245RkJRVE91eUFXQ0hBRDJt?=
 =?utf-8?B?WGlFdjFFRFFiZC9YLzdNbmRTa004ZjZIZC9BVldLQ1JsZ1NkZ2grWTNTV2R3?=
 =?utf-8?B?dGsvczdyVGwzQ3VEcnAvcFQ0TnI0RnE3djd2Mjg2NDhGSms2Zmg5Y3hWSUVh?=
 =?utf-8?B?WFJBY0w3aTdzQWJXeEVOcWUrUmprMjlweGxSZ1h2MVZvN3dza00vc0QweU9l?=
 =?utf-8?B?NU5qU0E1YVZlakxmUzYrZHlMWlhFVTduVUVOOGU4TjNSQTI4cXBVaWtvcC9h?=
 =?utf-8?B?L0hWdE9wcGc5dVZXSFRidlBycjFjZHBPTjl5cXdkR0VaSno4a3U0SFp0WlZW?=
 =?utf-8?B?OW5wL2R1Z3JEZ1ZBVC83ZmdOUk9BbnoyUENSR1pLSmxadmZVcWpnM1k3Z25D?=
 =?utf-8?B?ZGxaakNXZW9VVzRtVzhPeXoxR281NVJ2TERIU0Q0d0QrSFgzWmlPZ05oVEtN?=
 =?utf-8?B?Z1dZRmVEWXluRng3QUVNUmFFWXdmdkpmKzE2RXYvZjZGczdoZXB0bENpQjV0?=
 =?utf-8?B?eGFkcGl5bjZFbUlsNUpXbjVRVnpEQS9UVVQ0UllCa1l2c3hmUnNKK1hjaGVl?=
 =?utf-8?B?aEE9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 4a8988c7-6255-4dfe-3e0d-08dc74f7e178
X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB7573.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 May 2024 15:58:36.9392
 (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: X280jvhSVqK+Of8qSdsovWvM0ryZiws4bTLEaSUovpTKtbL0dKdheeaak6XHKxOYHJcU8opZsF5ePuk93lgkPgVjO+7De9i+mGkH62lwAYA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR11MB8407
X-OriginatorOrg: intel.com

Hi Dmitrii,

On 5/15/2024 6:12 AM, 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.
> 
> This race condition can be illustrated as follows:
> 
> /*                             /*
>  * Fault on CPU1                * Fault on CPU2
>  * on enclave page X            * on enclave page X
>  */                             */
> sgx_vma_fault() {              sgx_vma_fault() {
> 
>   xa_load(&encl->page_array)     xa_load(&encl->page_array)
>       == NULL -->                    == NULL -->
> 
>   sgx_encl_eaug_page() {         sgx_encl_eaug_page() {
> 
>     ...                            ...
> 
>     /*                             /*
>      * alloc encl_page              * alloc encl_page
>      */                             */
>                                    mutex_lock(&encl->lock);
>                                    /*
>                                     * alloc EPC page
>                                     */
>                                    epc_page = sgx_alloc_epc_page(...);
>                                    /*
>                                     * add page to enclave's xarray
>                                     */
>                                    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;
>                                  }
>                                }
>                                /*
>                                 * All good up to here: enclave page
>                                 * successfully added to enclave,
>                                 * ready for EACCEPT from user space
>                                 */
>     mutex_lock(&encl->lock);
>     /*
>      * alloc EPC page
>      */
>     epc_page = sgx_alloc_epc_page(...);
>     /*
>      * add page to enclave's xarray,
>      * this fails with -EBUSY as this
>      * page was already added by CPU2
>      */
>     xa_insert(&encl->page_array, ...);
> 
>   err_out_shrink:
>     sgx_encl_free_epc_page(epc_page) {
>       /*
>        * remove page via EREMOVE
>        *
>        * *BUG*: page added by CPU2 is
>        * yanked from enclave while it
>        * remains accessible from OS
>        * perspective (PTE installed)
>        */
>       /*
>        * free EPC page
>        */
>       sgx_free_epc_page(epc_page);
>     }
> 
>     mutex_unlock(&encl->lock);
>     /*
>      * *BUG*: SIGBUS is returned
>      * for a valid enclave page
>      */
>     return VM_FAULT_SIGBUS;
>   }
> }
> 
> The err_out_shrink error handling path contains two bugs: (1) function
> sgx_encl_free_epc_page() is called that performs EREMOVE even though the
> enclave page was never intended to be removed, and (2) SIGBUS is sent to
> userspace even though the enclave page is correctly installed by another
> thread.
> 
> The first bug renders the enclave page perpetually inaccessible (until
> another SGX_IOC_ENCLAVE_REMOVE_PAGES ioctl). This is because the page is
> marked accessible in the PTE entry but is not EAUGed, and any subsequent
> access to this page raises a fault: with the kernel believing there to
> be a valid VMA, the unlikely error code X86_PF_SGX encountered by code
> path do_user_addr_fault() -> access_error() causes the SGX driver's
> sgx_vma_fault() to be skipped and user space receives a SIGSEGV instead.
> The userspace SIGSEGV handler cannot perform EACCEPT because the page
> was not EAUGed. Thus, the user space is stuck with the inaccessible
> page. The second bug is less severe: a spurious SIGBUS signal is
> unnecessarily sent to user space.
> 
> 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.
> 
> Note that sgx_encl_free_epc_page() performs an additional WARN_ON_ONCE
> check in comparison to sgx_free_epc_page(): whether the EPC page is
> being 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 affected in this commit, the "page reclaimer tracked" condition is
> always false and the warning is never printed. Thus, it is safe to
> replace sgx_encl_free_epc_page() with sgx_free_epc_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);
>  err_out_unlock:
>  	mutex_unlock(&encl->lock);
>  	kfree(encl_page);

Thank you very much. I understand the changelog is still being discussed
and those changes look good to me, to which you can add:

Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>

Reinette