[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YeMZJ7gZi8JzTYYd@iki.fi>
Date: Sat, 15 Jan 2022 20:57:43 +0200
From: Jarkko Sakkinen <jarkko.sakkinen@....fi>
To: Kristen Carlson Accardi <kristen@...ux.intel.com>
Cc: linux-sgx@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/2] x86/sgx: Limit EPC overcommit
On Fri, Jan 07, 2022 at 10:16:15AM -0800, Kristen Carlson Accardi wrote:
> SGX currently allows EPC pages to be overcommitted. If the system is
> out of enclave memory, EPC pages are swapped to normal RAM via
> a per enclave shared memory area. This shared memory is not charged
> to the enclave or the task mapping it, making it hard to account
> for using normal methods. Since SGX will allow EPC pages to be
> overcommitted without limits, enclaves can consume system memory
> for these backing pages without limits.
>
> In order to prevent this, set a cap on the amount of overcommit SGX
> allows. Whenever a backing page is requested by an enclave, track
> the total amount of shared memory pages used across all enclaves and
> return an error if the overcommit limit has been reached. This will
> restrict the total amount of backing pages that all enclaves can
> consume to a maximum amount, and prevent enclaves from consuming
> all the system RAM for backing pages.
>
> The overcommit percentage has a value of 150, which limits shared
> memory page consumption to 1.5x the number of EPC pages in the system.
>
> Changes from v1
> ----------------
> * removed module parameter and disable boolean
> * increased over commit percentage to 150% from 100%
>
> Kristen Carlson Accardi (2):
> x86/sgx: Add accounting for tracking overcommit
> x86/sgx: account backing pages
>
> arch/x86/kernel/cpu/sgx/encl.c | 76 ++++++++++++++++++++++++++++++++--
> arch/x86/kernel/cpu/sgx/encl.h | 6 ++-
> arch/x86/kernel/cpu/sgx/main.c | 52 +++++++++++++++++++++--
> arch/x86/kernel/cpu/sgx/sgx.h | 2 +
> 4 files changed, 128 insertions(+), 8 deletions(-)
>
> --
> 2.20.1
>
I've tested also these. Looking at the feedback, there's
nothing game changing, so you could add for the next
version:
Tested-by: Jarkko Sakkinen <jarkko@...nel.org>
/Jarkko
Powered by blists - more mailing lists