linux-kernel - Re: [PATCH 10/25] x86/sgx: Support enclave page permission changes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4960c8f9-72e4-0f40-64e4-4384a76d1e69@kernel.org>
Date:   Fri, 3 Dec 2021 11:38:47 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     Reinette Chatre <reinette.chatre@...el.com>,
        dave.hansen@...ux.intel.com, jarkko@...nel.org, tglx@...utronix.de,
        bp@...en8.de, mingo@...hat.com, linux-sgx@...r.kernel.org,
        x86@...nel.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, hpa@...or.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 10/25] x86/sgx: Support enclave page permission changes

On 12/1/21 11:23, 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 two functions that can be used to modify the enclave page
> permissions of regular enclave pages within an initialized enclave.
> ENCLS[EMODPR] is run from the OS and used to restrict enclave page
> permissions while ENCLU[EMODPE] is run from within the enclave to
> extend enclave page permissions.
> 
> Enclave page permission changes need to be approached with care and
> for this reason this initial support is to allow enclave page
> permission changes _only_ if the new permissions are the same or
> more restrictive that the permissions originally vetted at the time the
> pages were added to the enclave. Support for extending enclave page
> permissions beyond what was originally vetted is deferred.
> 

I may well be missing something, but off the top of my head, literally 
the only reason that EMODPR needs CPL0 (i.e. ENCLS) is that it requires 
a TLB flush IPI to take effect.  (Score one for AMD for being having 
superior hardware in this regard.)

Given that, I don't see any reason for the EMODPR operation to be 
treated as security sensitive -- it just needs to be implemented 
correctly.  I don't even see why the host should (or even can!) do any 
useful tracking of the EPCM state.

(But I am confused about one thing: to the extent an enclave actually 
needs EMODPR, is there anything in the hardware or anything that the 
enclave can do short of actually poking the page from all threads and 
confirming that a fault occurs to make sure the OS actually flushed the 
TLB?  ISTM a malicious host could attack an enclave by omitting the TLB 
flush and then exploiting an enclave but that would have been mitigated 
if the flush occurred.)

--Andy