From: Reinette Chatre <reinette.chatre@intel.com>
To: Dave Hansen <dave.hansen@intel.com>, <jarkko@kernel.org>,
<dave.hansen@linux.intel.com>, <linux-sgx@vger.kernel.org>,
<shuah@kernel.org>
Cc: <linux-kselftest@vger.kernel.org>
Subject: Re: [PATCH 1/4] selftests/sgx: Fix segfault upon early test failure
Date: Fri, 28 Jan 2022 12:08:05 -0800 [thread overview]
Message-ID: <d2a34b98-3a81-fa59-1fed-cf7d0069d220@intel.com> (raw)
In-Reply-To: <35d888c6-ffed-fb89-d02d-8c7ef15cd902@intel.com>
Hi Dave,
On 1/28/2022 11:26 AM, Dave Hansen wrote:
> On 1/28/22 11:22, Reinette Chatre wrote:
>> if (encl->segment_tbl) {
>> + /*
>> + * Most segments form part of the enclave binary
>> + * and have their mappings deleted with earlier
>> + * munmap() of encl->bin.
>> + * As a mapping of anonymous memory the heap
>> + * segment is separate from the enclave
>> + * binary and needs its mapping deleted separately.
>> + */
>> heap_seg = &encl->segment_tbl[encl->nr_segments - 1];
>> munmap(heap_seg->src, heap_seg->size);
>
> I was more wondering why the status of heap_seg->src is tied to
> encl->segment_tbl.
Apologies but it is not clear to me what the concern is. Please bear
with me as I first try to create some context and then I hope to
navigate to the issue.
The test creates an SGX enclave from a binary, in the test it is
named test_encl.elf. To create the enclave the test loads the data
from the binary and populates the enclave with it. In order to create
the enclave correctly the binary needs to be loaded via its distinct
segments, initially this is: TCS, TEXT, DATA. This is done to ensure
when the enclave is created it is done with the correct page types
and permissions. For example, the pages from the TCS segment needs
to be loaded in to enclave pages of type TCS with RW permission, the
pages from the TEXT segment needs to be loaded into regular enclave
pages with RX permission, etc.
To ensure the enclave is created correctly the test thus initializes
the data for each segment that will be loaded into the enclave into
that enclave's "segment_tbl".
struct encl {
...
struct encl_segment *segment_tbl;
...
};
/*
* struct encl_segment - parameters that needed for
* SGX_IOC_ENCLAVE_ADD_PAGES ioctl()
*/
struct encl_segment {
void *src;
off_t offset;
size_t size;
unsigned int prot;
unsigned int flags;
bool measure;
};
Commit 3200505d4de6 ("selftests/sgx: Create a heap for the test
enclave") introduced a new segment, the heap, in support of more
testing. While not loaded from the original binary it is
considered a segment of the enclave and needs all fields in
struct encl_segment in order to add its pages to the enclave
with appropriate page permissions and flags.
This is thus how heap_seg->src ended up connected to
encl->segment_tbl.
Apologies for being long winded here but I hope with this we could
narrow down where your concerns are.
Reinette
next prev parent reply other threads:[~2022-01-28 20:08 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-28 18:23 [PATCH 0/4] selftests/sgx: Early enclave loading error path fixes Reinette Chatre
2022-01-28 18:23 ` [PATCH 1/4] selftests/sgx: Fix segfault upon early test failure Reinette Chatre
2022-01-28 18:43 ` Dave Hansen
2022-01-28 19:22 ` Reinette Chatre
2022-01-28 19:26 ` Dave Hansen
2022-01-28 20:08 ` Reinette Chatre [this message]
2022-02-15 19:39 ` Jarkko Sakkinen
2022-01-28 18:23 ` [PATCH 2/4] selftests/sgx: Do not attempt enclave build without valid enclave Reinette Chatre
2022-01-28 19:03 ` Dave Hansen
2022-01-28 19:23 ` Reinette Chatre
2022-02-15 19:35 ` Jarkko Sakkinen
2022-01-28 18:23 ` [PATCH 3/4] selftests/sgx: Ensure enclave data available during debug print Reinette Chatre
2022-01-28 19:06 ` Dave Hansen
2022-01-28 19:40 ` Reinette Chatre
2022-02-15 19:35 ` Jarkko Sakkinen
2022-01-28 18:23 ` [PATCH 4/4] selftests/sgx: Remove extra newlines in test output Reinette Chatre
2022-01-28 19:07 ` Dave Hansen
2022-02-15 19:34 ` Jarkko Sakkinen
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=d2a34b98-3a81-fa59-1fed-cf7d0069d220@intel.com \
--to=reinette.chatre@intel.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=jarkko@kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-sgx@vger.kernel.org \
--cc=shuah@kernel.org \
/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