From: "jarkko@kernel.org" <jarkko@kernel.org>
To: "Dhanraj, Vijay" <vijay.dhanraj@intel.com>
Cc: "Chatre, Reinette" <reinette.chatre@intel.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>,
"Huang, Haitao" <haitao.huang@intel.com>
Subject: Re: Support SGX2 V5: Seg-fault with EACCEPT for large number of EPC pages
Date: Wed, 3 Aug 2022 20:28:43 +0300 [thread overview]
Message-ID: <YuqwSw3enyOUTdON@kernel.org> (raw)
In-Reply-To: <DM8PR11MB55912A7F47A84EC9913A6352F6999@DM8PR11MB5591.namprd11.prod.outlook.com>
On Fri, Jul 29, 2022 at 04:01:04PM +0000, Dhanraj, Vijay wrote:
> Hi All,
>
> I recently tested the V5 version of the patch with Gramine and ran into a seg-fault during EPC allocation that is `EAUG`ing via `EACCEPT`. Allocation worked fine for smaller requests and even up to 2GBs. But when I tried with 4GB allocation I got a seg-fault.
> Huang, Haitao and I created a simple patch to repro this issue using the SGX selftests and we do see the issue when using V5 (5.18.0-rc5) but cannot repro the issue in V4 (5.18.0-rc2). Not sure if this is a driver issue or kernel, can you please check?
>
> Results with V5 using modified `augment_via_eaccept` test:
> # RUN enclave.augment_via_eaccept ...
> # main.c:1135:augment_via_eaccept:test enclave: total_size = 8192, seg->size = 8192
> # main.c:1135:augment_via_eaccept:test enclave: total_size = 12288, seg->size = 4096
> # main.c:1135:augment_via_eaccept:test enclave: total_size = 36864, seg->size = 24576
> # main.c:1135:augment_via_eaccept:test enclave: total_size = 40960, seg->size = 4096
> # main.c:1153:augment_via_eaccept:mmaping pages at end of enclave...
> # main.c:1167:augment_via_eaccept:Entering enclave to run EACCEPT for each page of 8589934592 bytes may take a while ...
> # main.c:1184:augment_via_eaccept:Expected self->run.exception_vector (14) == 0 (0)
> # main.c:1185:augment_via_eaccept:Expected self->run.exception_error_code (4) == 0 (0)
> # main.c:1186:augment_via_eaccept:Expected self->run.exception_addr (140106113478656) == 0 (0)
> # main.c:1188:augment_via_eaccept:Expected self->run.function (3) == EEXIT (4)
> # augment_via_eaccept: Test terminated by assertion
>
> Results with V4 using modified `augment_via_eaccept` test:
> # RUN enclave.augment_via_eaccept ...
> # main.c:1135:augment_via_eaccept:test enclave: total_size = 8192, seg->size = 8192
> # main.c:1135:augment_via_eaccept:test enclave: total_size = 12288, seg->size = 4096
> # main.c:1135:augment_via_eaccept:test enclave: total_size = 36864, seg->size = 24576
> # main.c:1135:augment_via_eaccept:test enclave: total_size = 40960, seg->size = 4096
> # main.c:1153:augment_via_eaccept:mmaping pages at end of enclave...
> # main.c:1167:augment_via_eaccept:Entering enclave to run EACCEPT for each page of 8589934592 bytes may take a while ...
> # OK enclave.augment_via_eaccept
>
>
> Test Patch:
> diff --git a/tools/testing/selftests/sgx/load.c b/tools/testing/selftests/sgx/load.c
> index 94bdeac1cf04..7de1b15c90b1 100644
> --- a/tools/testing/selftests/sgx/load.c
> +++ b/tools/testing/selftests/sgx/load.c
> @@ -171,7 +171,8 @@ uint64_t encl_get_entry(struct encl *encl, const char *symbol)
> return 0;
> }
>
> -bool encl_load(const char *path, struct encl *encl, unsigned long heap_size)
> +bool encl_load(const char *path, struct encl *encl, unsigned long heap_size,
> + unsigned long edmm_size)
> {
> const char device_path[] = "/dev/sgx_enclave";
> struct encl_segment *seg;
> @@ -300,7 +301,7 @@ bool encl_load(const char *path, struct encl *encl, unsigned long heap_size)
>
> encl->src_size = encl->segment_tbl[j].offset + encl->segment_tbl[j].size;
>
> - for (encl->encl_size = 4096; encl->encl_size < encl->src_size; )
> + for (encl->encl_size = 4096; encl->encl_size < encl->src_size + edmm_size;)
> encl->encl_size <<= 1;
>
> return true;
> diff --git a/tools/testing/selftests/sgx/main.c b/tools/testing/selftests/sgx/main.c
> index 9820b3809c69..8d7ce9389c8f 100644
> --- a/tools/testing/selftests/sgx/main.c
> +++ b/tools/testing/selftests/sgx/main.c
> @@ -25,6 +25,8 @@ static const uint64_t MAGIC = 0x1122334455667788ULL;
> static const uint64_t MAGIC2 = 0x8877665544332211ULL;
> vdso_sgx_enter_enclave_t vdso_sgx_enter_enclave;
>
> +static const unsigned long edmm_size = 8589934592; //8G
> +
> /*
> * Security Information (SECINFO) data structure needed by a few SGX
> * instructions (eg. ENCLU[EACCEPT] and ENCLU[EMODPE]) holds meta-data
> @@ -183,7 +185,7 @@ static bool setup_test_encl(unsigned long heap_size, struct encl *encl,
> unsigned int i;
> void *addr;
>
> - if (!encl_load("test_encl.elf", encl, heap_size)) {
> + if (!encl_load("test_encl.elf", encl, heap_size, edmm_size)) {
> encl_delete(encl);
> TH_LOG("Failed to load the test enclave.");
> return false;
> @@ -1104,14 +1106,19 @@ TEST_F(enclave, augment)
> * Test for the addition of pages to an initialized enclave via a
> * pre-emptive run of EACCEPT on page to be added.
> */
> -TEST_F(enclave, augment_via_eaccept)
> +/*
> + * Test for the addition of pages to an initialized enclave via a
> + * pre-emptive run of EACCEPT on page to be added.
> + */
> +/*TEST_F(enclave, augment_via_eaccept)*/
> +TEST_F_TIMEOUT(enclave, augment_via_eaccept, 900)
Could you make this a proper patch for kselftest?
It looks fine. Only thing you need to do is to add instead a new test add a
new test called augment_via_eaccept_long. Please, also define this before
TEST_F's:
#define TIMEOUT_LONG 900 /* seconds */
Then we can test against a commit instead of attachment and we obviously
want a test case for this, after the issue has been fixed. And I can easily
build a kernel for Geminilake, XPS-20 and Icelake server, and run the
equivalent test.
BR, Jarkko
next prev parent reply other threads:[~2022-08-03 17:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-29 16:01 Support SGX2 V5: Seg-fault with EACCEPT for large number of EPC pages Dhanraj, Vijay
2022-07-29 16:37 ` Dave Hansen
2022-07-29 19:14 ` Dhanraj, Vijay
2022-07-29 19:37 ` Haitao Huang
2022-08-01 18:00 ` Haitao Huang
2022-08-01 16:46 ` jarkko
2022-08-01 17:47 ` Dhanraj, Vijay
2022-08-03 17:28 ` jarkko [this message]
2022-08-04 0:38 ` Dhanraj, Vijay
2022-08-04 0:57 ` jarkko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YuqwSw3enyOUTdON@kernel.org \
--to=jarkko@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=haitao.huang@intel.com \
--cc=linux-sgx@vger.kernel.org \
--cc=reinette.chatre@intel.com \
--cc=vijay.dhanraj@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).