On Sat, 08 Jan 2022 10:22:30 -0600, Jarkko Sakkinen <jarkko@xxxxxxxxxx>
wrote:
On Sat, Jan 08, 2022 at 05:51:46PM +0200, Jarkko Sakkinen wrote:
On Sat, Jan 08, 2022 at 05:45:44PM +0200, Jarkko Sakkinen wrote:
> On Fri, Jan 07, 2022 at 10:14:29AM -0600, Haitao Huang wrote:
> > > > > OK, so the question is: do we need both or would a mechanism
just
> > > > to extend
> > > > > permissions be sufficient?
> > > >
> > > > I do believe that we need both in order to support pages having
only
> > > > the permissions required to support their intended use during
the
> > > > time the
> > > > particular access is required. While technically it is possible
to grant
> > > > pages all permissions they may need during their lifetime it is
safer to
> > > > remove permissions when no longer required.
> > >
> > > So if we imagine a run-time: how EMODPR would be useful, and how
using it
> > > would make things safer?
> > >
> > In scenarios of JIT compilers, once code is generated into RW pages,
> > modifying both PTE and EPCM permissions to RX would be a good
defensive
> > measure. In that case, EMODPR is useful.
>
> What is the exact threat we are talking about?
To add: it should be *significantly* critical thread, given that not
supporting only EAUG would leave us only one complex call pattern with
EACCEPT involvement.
I'd even go to suggest to leave EMODPR out of the patch set, and
introduce
it when there is PoC code for any of the existing run-time that
demonstrates the demand for it. Right now this way too speculative.
Supporting EMODPE is IMHO by factors more critical.
At least it does not protected against enclave code because an enclave
can
always choose not to EACCEPT any of the EMODPR requests. I'm not only
confused here about the actual threat but also the potential adversary
and
target.
I'm not sure I follow your thoughts here. The sequence should be for
enclave to request EMODPR in the first place through runtime to kernel,
then to verify with EACCEPT that the OS indeed has done EMODPR.
If enclave does not verify with EACCEPT, then its own code has
vulnerability. But this does not justify OS not providing the mechanism to
request EMODPR.
Similar to how we don't want have RWX code pages for normal Linux
application, when an enclave loads code pages (either directly or JIT
compiled from high level code ) into EAUG'd page (which has RW), we do not
want leave pages to be RWX for code to be executable, hence the need of
EMODPR request OS to reduce the permissions to RX once the code is ready
to execute.
I believe this is needed for LibOS runtimes (e.g.,Gramine) loading
unmodified app binaries, or an enclave with JIT compiler (I think Enarx in
this category?). Experts from those project can confirm or contradict.
Intel SDK currently also has implementation to reduce permissions of RELRO
sections in ELF binaries to ReadOnly after relocation is done. In our new
EDMM user support[1] based on this patch series, we also support flows to
reduce permissions using EMODPR in a generic way.
[1]https://github.com/intel/linux-sgx/pull/751
