public inbox for linux-sgx@vger.kernel.org
 help / color / mirror / Atom feed
From: "Huang, Kai" <kai.huang@intel.com>
To: "linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>,
	"jarkko@kernel.org" <jarkko@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Van Bulck, Jo" <jo.vanbulck@cs.kuleuven.be>
Cc: "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>
Subject: Re: [PATCH v3 3/9] selftests/sgx: Handle relocations in test enclave
Date: Tue, 22 Aug 2023 01:11:37 +0000	[thread overview]
Message-ID: <90ad8638bc1c26505e33b3f436fdbc22c8d74ba9.camel@intel.com> (raw)
In-Reply-To: <20230819094332.8535-4-jo.vanbulck@cs.kuleuven.be>

On Sat, 2023-08-19 at 11:43 +0200, Jo Van Bulck wrote:
> Static-pie binaries normally include a startup routine to perform any ELF
> relocations from .rela.dyn. Since the enclave loading process is different
> and glibc is not included, do the necessary relocation for encl_op_array
> entries manually at runtime relative to the enclave base to ensure correct
> function pointers.
> 
> Signed-off-by: Jo Van Bulck <jo.vanbulck@cs.kuleuven.be>
> ---
>  tools/testing/selftests/sgx/test_encl.c   | 49 ++++++++++++++++-------
>  tools/testing/selftests/sgx/test_encl.lds |  2 +
>  2 files changed, 36 insertions(+), 15 deletions(-)
> 
> diff --git a/tools/testing/selftests/sgx/test_encl.c b/tools/testing/selftests/sgx/test_encl.c
> index c0d639729..7633fb7cb 100644
> --- a/tools/testing/selftests/sgx/test_encl.c
> +++ b/tools/testing/selftests/sgx/test_encl.c
> @@ -119,21 +119,40 @@ static void do_encl_op_nop(void *_op)
>  
>  }
>  
> +/*
> + * Symbol placed at the start of the enclave image by the linker script.
> + * Declare this extern symbol with visibility "hidden" to ensure the
> + * compiler does not access it through the GOT.
> + */
> +extern const uint8_t __attribute__((visibility("hidden"))) __encl_base;
> +static const uint64_t encl_base = (uint64_t)&__encl_base;

I had hard time to understand this.  The __encl_base is a symbol which is a
fixed value set by the compiler/linker.  encl_base has the real storage in the
.data section, but the value is also build-time fixed.  IIUC we need some code
to explicitly override it, but I don't see where it's done.  Perhaps I missed
something?

> +
> +typedef void (*encl_op_t)(void *);
> +const encl_op_t encl_op_array[ENCL_OP_MAX] = {
> +	do_encl_op_put_to_buf,
> +	do_encl_op_get_from_buf,
> +	do_encl_op_put_to_addr,
> +	do_encl_op_get_from_addr,
> +	do_encl_op_nop,
> +	do_encl_eaccept,
> +	do_encl_emodpe,
> +	do_encl_init_tcs_page,
> +};

Any reason it cannot be 'static'?

> +
>  void encl_body(void *rdi,  void *rsi)
>  {
> -	const void (*encl_op_array[ENCL_OP_MAX])(void *) = {
> -		do_encl_op_put_to_buf,
> -		do_encl_op_get_from_buf,
> -		do_encl_op_put_to_addr,
> -		do_encl_op_get_from_addr,
> -		do_encl_op_nop,
> -		do_encl_eaccept,
> -		do_encl_emodpe,
> -		do_encl_init_tcs_page,
> -	};
> -
> -	struct encl_op_header *op = (struct encl_op_header *)rdi;
> -
> -	if (op->type < ENCL_OP_MAX)
> -		(*encl_op_array[op->type])(op);
> +	struct encl_op_header *header = (struct encl_op_header *)rdi;
> +	encl_op_t op;
> +
> +	if (header->type >= ENCL_OP_MAX)
> +		return;
> +
> +	/*
> +	 * "encl_base" needs to be added, as this call site *cannot be*
> +	 * made rip-relative by the compiler, or fixed up by any other
> +	 * possible means.
> +	 */
> +	op = encl_base + encl_op_array[header->type];
> +
> +	(*op)(header);
>  }
> diff --git a/tools/testing/selftests/sgx/test_encl.lds b/tools/testing/selftests/sgx/test_encl.lds
> index 62d37160f..b86c86060 100644
> --- a/tools/testing/selftests/sgx/test_encl.lds
> +++ b/tools/testing/selftests/sgx/test_encl.lds
> @@ -32,6 +32,8 @@ SECTIONS
>  		*(.note*)
>  		*(.debug*)
>  		*(.eh_frame*)
> +		*(.dyn*)
> +		*(.gnu.hash)

This looks can be in a separate patch, because it's not directly related to what
you are trying to fix.  

But I don't want to make things unnecessarily complicated for selftests, so fine
to me if you still want to keep it.  But if you do, perhaps you can add some
justification to the changelog saying something like: opportunistically discard
".dyn*" and ".gnu.hash" which the enclave loader cannot handle.  Anyway, still
better to make a separate patch for such purpose IMHO.

  reply	other threads:[~2023-08-22  1:12 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-19  9:43 [PATCH v3 0/9] selftests/sgx: Fix compilation errors Jo Van Bulck
2023-08-19  9:43 ` [PATCH v3 1/9] selftests/sgx: Fix uninitialized pointer dereference in error path Jo Van Bulck
2023-08-19  9:43 ` [PATCH v3 2/9] selftests/sgx: Produce static-pie executable for test enclave Jo Van Bulck
2023-08-22  0:26   ` Huang, Kai
2023-08-23 13:19     ` Jo Van Bulck
2023-08-19  9:43 ` [PATCH v3 3/9] selftests/sgx: Handle relocations in " Jo Van Bulck
2023-08-22  1:11   ` Huang, Kai [this message]
2023-08-25 13:27     ` Jo Van Bulck
2023-08-22 10:08   ` Jarkko Sakkinen
2023-08-19  9:43 ` [PATCH v3 4/9] selftests/sgx: Fix linker script asserts Jo Van Bulck
2023-08-22 10:09   ` Jarkko Sakkinen
2023-08-19  9:43 ` [PATCH v3 5/9] selftests/sgx: Include memory clobber for inline asm in test enclave Jo Van Bulck
2023-08-22 10:10   ` Jarkko Sakkinen
2023-08-19  9:43 ` [PATCH v3 6/9] selftests/sgx: Ensure test enclave buffer is entirely preserved Jo Van Bulck
2023-08-21 11:10   ` Huang, Kai
2023-08-22 10:10   ` Jarkko Sakkinen
2023-08-19  9:43 ` [PATCH v3 7/9] selftests/sgx: Ensure expected location of test enclave buffer Jo Van Bulck
2023-08-21 11:10   ` Huang, Kai
2023-08-22 10:11   ` Jarkko Sakkinen
2023-08-19  9:43 ` [PATCH v3 8/9] selftests/sgx: Separate linker options Jo Van Bulck
2023-08-22 10:11   ` Jarkko Sakkinen
2023-08-19  9:43 ` [PATCH v3 9/9] selftests/sgx: Specify freestanding environment for enclave compilation Jo Van Bulck
2023-08-22 10:14   ` Jarkko Sakkinen
2023-08-23 12:57     ` Jo Van Bulck
2023-08-23 17:31       ` Jarkko Sakkinen
2023-08-22 10:31 ` [PATCH v3 0/9] selftests/sgx: Fix compilation errors 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=90ad8638bc1c26505e33b3f436fdbc22c8d74ba9.camel@intel.com \
    --to=kai.huang@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=jarkko@kernel.org \
    --cc=jo.vanbulck@cs.kuleuven.be \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sgx@vger.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