linux-sgx.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).