linux-kernel.vger.kernel.org archive mirror
 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 v4 03/13] selftests/sgx: Handle relocations in test enclave
Date: Mon, 28 Aug 2023 13:15:47 +0000	[thread overview]
Message-ID: <06f20425546aa13310a9fc25f081b8d70a6f1f44.camel@intel.com> (raw)
In-Reply-To: <20230825133252.9056-4-jo.vanbulck@cs.kuleuven.be>

On Fri, 2023-08-25 at 15:32 +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.

Sorry for late reply.

I am wondering is this the right justification for _this_ particular patch?

Even above paragraph is true, the existing code w/o this patch can work because
the generated asm code uses "lea (-xxx)(%rip), %<reg>" to get the right address
and store it to the array on the stack.

It stops to work because you want to use -Os, in which case the generated asm
code instead initializes the array by copying an array (which has function
addresses starting from 0) generated by the compiler/linker.

So to me the true justification should be "using -Os breaks the code".  Or do
you think "the compiler generating code to initialize the array on the stack
using RIP-relative addressing to get the function address" is completely a lucky
thing?

Anyway, it will be very helpful to include the assembly code generated both w/
and w/o using -Os here to the changelog to demonstrate the problem and we need
this patch to fixup.

Without those information, it's basically very hard for people to understand why
this is needed.  This will save maintainer's time, and make git blamer's life
easy in the future.

> 
> Signed-off-by: Jo Van Bulck <jo.vanbulck@cs.kuleuven.be>
> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
> ---
>  tools/testing/selftests/sgx/test_encl.c | 48 +++++++++++++++++--------
>  1 file changed, 33 insertions(+), 15 deletions(-)
> 
> diff --git a/tools/testing/selftests/sgx/test_encl.c b/tools/testing/selftests/sgx/test_encl.c
> index c0d6397295e3..706c1f7260ff 100644
> --- a/tools/testing/selftests/sgx/test_encl.c
> +++ b/tools/testing/selftests/sgx/test_encl.c
> @@ -119,21 +119,39 @@ 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;
> +
> +typedef void (*encl_op_t)(void *);
> +static 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,
> +};
> +
>  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;
> +
> +	/*
> +	 * The enclave base address needs to be added, as this call site
> +	 * *cannot be* made rip-relative by the compiler, or fixed up by
> +	 * any other possible means.
> +	 */

Is it better to explicitly call out the compiler generates RIP-relative
addressing code to get the address associated with '__encl_base' symbol, so we
can get the actual enclave base during runtime?

Maybe it's obvious, but I am not sure :-)

> +	op = ((uint64_t)&__encl_base) + encl_op_array[header->type];
> +
> +	(*op)(header);
>  }



  reply	other threads:[~2023-08-28 13:21 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-25 13:32 [PATCH v4 00/13] selftests/sgx: Fix compilation errors Jo Van Bulck
2023-08-25 13:32 ` [PATCH v4 01/13] selftests/sgx: Fix uninitialized pointer dereference in error path Jo Van Bulck
2023-08-25 13:32 ` [PATCH v4 02/13] selftests/sgx: Produce static-pie executable for test enclave Jo Van Bulck
2023-08-29 10:55   ` Huang, Kai
2023-08-31  8:49     ` Jo Van Bulck
2023-08-25 13:32 ` [PATCH v4 03/13] selftests/sgx: Handle relocations in " Jo Van Bulck
2023-08-28 13:15   ` Huang, Kai [this message]
2023-08-31 12:48     ` Jo Van Bulck
2023-08-25 13:32 ` [PATCH v4 04/13] selftests/sgx: Fix linker script asserts Jo Van Bulck
2023-08-25 13:32 ` [PATCH v4 05/13] selftests/sgx: Include memory clobber for inline asm in test enclave Jo Van Bulck
2023-08-29 11:07   ` Huang, Kai
2023-08-31  8:31     ` Jo Van Bulck
2023-08-25 13:32 ` [PATCH v4 06/13] selftests/sgx: Ensure test enclave buffer is entirely preserved Jo Van Bulck
2023-08-25 13:32 ` [PATCH v4 07/13] selftests/sgx: Ensure expected location of test enclave buffer Jo Van Bulck
2023-08-25 13:32 ` [PATCH v4 08/13] selftests/sgx: Separate linker options Jo Van Bulck
2023-08-25 13:32 ` [PATCH v4 09/13] selftests/sgx: Specify freestanding environment for enclave compilation Jo Van Bulck
2023-08-27 18:35   ` Jarkko Sakkinen
2023-08-25 13:32 ` [PATCH v4 10/13] selftests/sgx: Fix uninitialized pointer dereferences Jo Van Bulck
2023-08-27 18:36   ` Jarkko Sakkinen
2023-08-31  8:12     ` Jo Van Bulck
2023-08-25 13:32 ` [PATCH v4 11/13] selftests/sgx: Discard unsupported ELF sections Jo Van Bulck
2023-08-25 13:32 ` [PATCH v4 12/13] selftests/sgx: Remove redundant enclave base address save/restore Jo Van Bulck
2023-08-29 11:00   ` Huang, Kai
2023-08-31  8:25     ` Jo Van Bulck
2023-08-25 13:32 ` [PATCH v4 13/13] selftests/sgx: Remove incomplete ABI sanitization code in test enclave Jo Van Bulck

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=06f20425546aa13310a9fc25f081b8d70a6f1f44.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;
as well as URLs for NNTP newsgroup(s).