[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YihqwiU3Dr5mvMQx@iki.fi>
Date: Wed, 9 Mar 2022 10:52:18 +0200
From: Jarkko Sakkinen <jarkko@...nel.org>
To: linux-sgx@...r.kernel.org
Cc: Nathaniel McCallum <nathaniel@...fian.com>,
Reinette Chatre <reinette.chatre@...el.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v2.1 14/30] x86/sgx: Support restricting of enclave
page permissions
On Fri, Mar 04, 2022 at 11:35:08AM +0200, Jarkko Sakkinen wrote:
> +#define SGX_IOC_ENCLAVE_RESTRICT_PERMISSIONS \
> + _IOWR(SGX_MAGIC, 0x05, struct sgx_enclave_restrict_perm)
What if this was replaced with just SGX_IOC_ENCLAVE_RESET_PAGES, which
would simply do EMODPR with PROT_NONE? The main ingredient of EMODPR is to
flush out the TLB's, and move a page to pending state, which cannot be done
from inside the enclave.
It's there because of microarchitecture constraints, and less so to work as
a reasonable permission control mechanism (actually it does terrible job on
that side and only confuses).
Once you have this magic TLB reset button in place you can just do one
EACCEPT and EMODPE inside the enclave and you're done.
This is also kind of atomic in the sense that EACCEPT free's a page with no
rights so no misuse can happend before EMODPE has tuned EPCM.
BR, Jarkko
Powered by blists - more mailing lists