[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c566b89cc3ef6c164160cc56a820abac3fd70839.camel@linux.intel.com>
Date: Sat, 16 May 2020 12:50:23 +0300
From: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To: Sasha Levin <sashal@...nel.org>
Cc: linux-kernel@...r.kernel.org, tglx@...utronix.de, bp@...en8.de,
luto@...nel.org, hpa@...or.com, dave.hansen@...el.com,
tony.luck@...el.com, ak@...ux.intel.com, ravi.v.shankar@...el.com,
chang.seok.bae@...el.com
Subject: Re: [PATCH v12 00/18] Enable FSGSBASE instructions
On Fri, 2020-05-15 at 12:40 -0400, Sasha Levin wrote:
> > Can you put me to the CC-loop for this patches. Some SGX-enabled
>
> Sure!
>
> > frameworks such as Graphene use out-of-tree changes to achieve this.
> > That's where the interest to possibly test this comes from.
>
> Indeed, we've seen a few hacks that basically just enable FSGSBASE:
>
> - https://github.com/oscarlab/graphene-sgx-driver
> - https://github.com/occlum/enable_rdfsbase
>
> And would very much like to get rid of them...
Yes, for SGX this is functional feature because enclave entry points,
thread control structures (aka TCS's), reset FSBASE and GSBASE registers
to fixed (albeit user defined) values. And syscall's can be done only
outside of enclave.
This is a required feature for fancier runtimes (such as Graphene).
I'll try the next version by patching Graphene to use this instead of the
out-of-tree drive. That should give at least fairly realistic
workload (an arbitrary dynamically linked executable running inside an
enclave) for this patch set.
/Jarkko
Powered by blists - more mailing lists