[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8339d3c0-8e80-9cd5-948e-47733f7c29b7@intel.com>
Date: Sat, 14 Sep 2019 08:32:38 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
linux-sgx@...r.kernel.org, akpm@...ux-foundation.org,
sean.j.christopherson@...el.com, nhorman@...hat.com,
npmccallum@...hat.com, serge.ayoun@...el.com,
shay.katz-zamir@...el.com, haitao.huang@...el.com,
andriy.shevchenko@...ux.intel.com, tglx@...utronix.de,
kai.svahn@...el.com, bp@...en8.de, josh@...htriplett.org,
luto@...nel.org, kai.huang@...el.com, rientjes@...gle.com,
cedric.xing@...el.com
Subject: Re: [PATCH v22 00/24] Intel SGX foundations
On 9/14/19 6:41 AM, Jarkko Sakkinen wrote:
>
> The proposed LSM hooks give the granularity to make yes/no decision
> based on the
>
> * The origin of the source of the source for the enclave.
> * The requested permissions for the added or mapped peage.
>
> The hooks to do these checks are provided for mmap() and EADD
> operations.
>
> With just file permissions you can still limit mmap() by having a
> privileged process to build the enclaves and pass the file descriptor
> to the enclave user who can mmap() the enclave within the constraints
> set by the enclave pages (their permissions refine the roof that you
> can mmap() any memory range within an enclave).
The LSM hooks are presumably fixing a problem that these patches
introduce. What's that problem?
Powered by blists - more mailing lists