Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1971913pxb; Thu, 28 Oct 2021 13:39:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxrlnH7RQfu7QOtJZeI/tFas5u5wmgSO6JmMuLQxCJKkNJ4ZpmnvdCEkp3bX650hV6LIDal X-Received: by 2002:a63:7017:: with SMTP id l23mr4908903pgc.395.1635453561242; Thu, 28 Oct 2021 13:39:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635453561; cv=none; d=google.com; s=arc-20160816; b=0jGCo21xJHnA30AXd5sZVkajzLxnW2D8kq+giiJWznCvHC5PRrULGt1KuH7PpTohh2 /Ham8V+Wt4t68obftJvSDbIEPyZTb3PS+ba97iIXUlzs/ebSh3M8Lx0iCYZrafb/xr3O 8z33pb4Nd2ax1nWpSKqw0V1B0rUcXi8az2pHYF/XWUOumzmZU5Ktz/DHs83R2ADHMi0h guwL3/7SLmIzQ0jaxtJo6gsMftK7jCHNleskb60n8Va54uixOMlOVjHAifEmYkMmc73H s7MUU+qeztBSt5A8Z9dxIahf+Ueo0JX7cuhUEr6JUaYFg0vmzebe19l0bMyU8145HCyu musg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=2W9bWsI35iOHeizTmwTbWn0tyXX0HojWsD7bALb0Pe8=; b=pAarBDavQrtoueK09c24GQxF6cHJzr85nRp95kZBxGNHb76wgeaNw9nb/9ORr4GlpB dXOjITuDCrRgQ3LTkJWMw6vexLfrZD0z1c80QMHPRE5jvsuo8YYzM1Wsm1p90MfEpW2I G8KJoe/Q2qeoZQJYP16Zf2cOmvUxfbmFKKCC+AJQ+7ptDlBHxO5XFiI89qpnA3YqeR1u 8h/AIxnwY8SFeAfVRZt7r0gCnLwTOFGQVV2FcgVJOsTeNUIfqFFowPPee0HFnXmpcHKM pso7SO2Wjt43WZODkAAzgiVIydpMEWw2dc++wLYOoaVwA+SSJAvhJD/no4WEuB74otuA eang== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t13si6057742pgu.411.2021.10.28.13.39.09; Thu, 28 Oct 2021 13:39:21 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231517AbhJ1UkT (ORCPT + 99 others); Thu, 28 Oct 2021 16:40:19 -0400 Received: from mga14.intel.com ([192.55.52.115]:25710 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231313AbhJ1UkB (ORCPT ); Thu, 28 Oct 2021 16:40:01 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10151"; a="230775405" X-IronPort-AV: E=Sophos;i="5.87,190,1631602800"; d="scan'208";a="230775405" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Oct 2021 13:37:31 -0700 X-IronPort-AV: E=Sophos;i="5.87,190,1631602800"; d="scan'208";a="498563004" Received: from rchatre-ws.ostc.intel.com ([10.54.69.144]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Oct 2021 13:37:30 -0700 From: Reinette Chatre To: jarkko@kernel.org, linux-sgx@vger.kernel.org, shuah@kernel.org, dave.hansen@linux.intel.com Cc: seanjc@google.com, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH V2 14/15] selftests/sgx: Enable multiple thread support Date: Thu, 28 Oct 2021 13:37:39 -0700 Message-Id: <0312e1e1b5896a5d73d09acef56906e4c5148aa1.1635447301.git.reinette.chatre@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Each thread executing in an enclave is associated with a Thread Control Structure (TCS). The test enclave contains two hardcoded TCS. Each TCS contains meta-data used by the hardware to save and restore thread specific information when entering/exiting the enclave. The two TCS structures within the test enclave share their SSA (State Save Area) resulting in the threads clobbering each other's data. Fix this by providing each TCS their own SSA area. Additionally, there is an 8K stack space and its address is computed from the enclave entry point which is correctly done for TCS #1 that starts on the first address inside the enclave but results in out of bounds memory when entering as TCS #2. Split 8K stack space into two separate pages with offset symbol between to ensure the current enclave entry calculation can continue to be used for both threads. While using the enclave with multiple threads requires these fixes the impact is not apparent because every test up to this point enters the enclave from the first TCS. More detail about the stack fix: ------------------------------- Before this change the test enclave (test_encl) looks as follows: .tcs (2 pages): (page 1) TCS #1 (page 2) TCS #2 .text (1 page) One page of code .data (5 pages) (page 1) encl_buffer (page 2) encl_buffer (page 3) SSA (page 4 and 5) STACK encl_stack: As shown above there is a symbol, encl_stack, that points to the end of the .data segment (pointing to the end of page 5 in .data) which is also the end of the enclave. The enclave entry code computes the stack address by adding encl_stack to the pointer to the TCS that entered the enclave. When entering at TCS #1 the stack is computed correctly but when entering at TCS #2 the stack pointer would point to one page beyond the end of the enclave and a #PF would result when TCS #2 attempts to enter the enclave. The fix involves moving the encl_stack symbol between the two stack pages. Doing so enables the stack address computation in the entry code to compute the correct stack address for each TCS. Reviewed-by: Jarkko Sakkinen Acked-by: Dave Hansen Signed-off-by: Reinette Chatre --- Changes since V1: - Add Jarkko and Dave's signatures. .../selftests/sgx/test_encl_bootstrap.S | 21 ++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/tools/testing/selftests/sgx/test_encl_bootstrap.S b/tools/testing/selftests/sgx/test_encl_bootstrap.S index 5d5680d4ea39..82fb0dfcbd23 100644 --- a/tools/testing/selftests/sgx/test_encl_bootstrap.S +++ b/tools/testing/selftests/sgx/test_encl_bootstrap.S @@ -12,7 +12,7 @@ .fill 1, 8, 0 # STATE (set by CPU) .fill 1, 8, 0 # FLAGS - .quad encl_ssa # OSSA + .quad encl_ssa_tcs1 # OSSA .fill 1, 4, 0 # CSSA (set by CPU) .fill 1, 4, 1 # NSSA .quad encl_entry # OENTRY @@ -23,10 +23,10 @@ .fill 1, 4, 0xFFFFFFFF # GSLIMIT .fill 4024, 1, 0 # Reserved - # Identical to the previous TCS. + # TCS2 .fill 1, 8, 0 # STATE (set by CPU) .fill 1, 8, 0 # FLAGS - .quad encl_ssa # OSSA + .quad encl_ssa_tcs2 # OSSA .fill 1, 4, 0 # CSSA (set by CPU) .fill 1, 4, 1 # NSSA .quad encl_entry # OENTRY @@ -40,8 +40,9 @@ .text encl_entry: - # RBX contains the base address for TCS, which is also the first address - # inside the enclave. By adding the value of le_stack_end to it, we get + # RBX contains the base address for TCS, which is the first address + # inside the enclave for TCS #1 and one page into the enclave for + # TCS #2. By adding the value of encl_stack to it, we get # the absolute address for the stack. lea (encl_stack)(%rbx), %rax xchg %rsp, %rax @@ -81,9 +82,15 @@ encl_entry: .section ".data", "aw" -encl_ssa: +encl_ssa_tcs1: + .space 4096 +encl_ssa_tcs2: .space 4096 .balign 4096 - .space 8192 + # Stack of TCS #1 + .space 4096 encl_stack: + .balign 4096 + # Stack of TCS #2 + .space 4096 -- 2.25.1