[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9abbecc124d61843c27217bf183d7447a281c297.camel@kernel.org>
Date: Thu, 14 Apr 2022 14:19:00 +0300
From: Jarkko Sakkinen <jarkko@...nel.org>
To: Reinette Chatre <reinette.chatre@...el.com>,
dave.hansen@...ux.intel.com, tglx@...utronix.de, bp@...en8.de,
luto@...nel.org, mingo@...hat.com, linux-sgx@...r.kernel.org,
x86@...nel.org, shuah@...nel.org, linux-kselftest@...r.kernel.org
Cc: seanjc@...gle.com, kai.huang@...el.com, cathy.zhang@...el.com,
cedric.xing@...el.com, haitao.huang@...el.com,
mark.shanahan@...el.com, vijay.dhanraj@...el.com, hpa@...or.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH V4 15/31] x86/sgx: Support restricting of enclave page
permissions
On Wed, 2022-04-13 at 14:10 -0700, Reinette Chatre wrote:
> In the initial (SGX1) version of SGX, pages in an enclave need to be
> created with permissions that support all usages of the pages, from the
> time the enclave is initialized until it is unloaded. For example,
> pages used by a JIT compiler or when code needs to otherwise be
> relocated need to always have RWX permissions.
>
> SGX2 includes a new function ENCLS[EMODPR] that is run from the kernel
> and can be used to restrict the EPCM permissions of regular enclave
> pages within an initialized enclave.
>
> Introduce ioctl() SGX_IOC_ENCLAVE_RESTRICT_PERMISSIONS to support
> restricting EPCM permissions. With this ioctl() the user specifies
> a page range and the EPCM permissions to be applied to all pages in
> the provided range. ENCLS[EMODPR] is run to restrict the EPCM
> permissions followed by the ENCLS[ETRACK] flow that will ensure
> no cached linear-to-physical address mappings to the changed
> pages remain.
>
> It is possible for the permission change request to fail on any
> page within the provided range, either with an error encountered
> by the kernel or by the SGX hardware while running
> ENCLS[EMODPR]. To support partial success the ioctl() returns an
> error code based on failures encountered by the kernel as well
> as two result output parameters: one for the number of pages
> that were successfully changed and one for the SGX return code.
>
> The page table entry permissions are not impacted by the EPCM
> permission changes. VMAs and PTEs will continue to allow the
> maximum vetted permissions determined at the time the pages
> are added to the enclave. The SGX error code in a page fault
> will indicate if it was an EPCM permission check that prevented
> an access attempt.
>
> No checking is done to ensure that the permissions are actually
> being restricted. This is because the enclave may have relaxed
> the EPCM permissions from within the enclave without the kernel
> knowing. An attempt to relax permissions using this call will
> be ignored by the hardware.
>
> Signed-off-by: Reinette Chatre <reinette.chatre@...el.com>
Reviewed-by: Jarkko Sakkinen <jarkko@...nel.org>
BR, Jarkko
Powered by blists - more mailing lists