linux-kernel - Re: [PATCH] x86/sgx: Free backing memory after faulting the enclave page

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]

Date:   Thu, 4 Nov 2021 06:50:24 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Jarkko Sakkinen <jarkko@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
        Jethro Beekman <jethro@...tanix.com>,
        Sean Christopherson <seanjc@...gle.com>
Cc:     reinette.chatre@...el.com, tony.luck@...el.com,
        nathaniel@...fian.com, stable@...r.kernel.org,
        Borislav Petkov <bp@...e.de>, linux-sgx@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/sgx: Free backing memory after faulting the enclave
 page

On 11/3/21 4:22 PM, Jarkko Sakkinen wrote:
> The backing memory was not freed, after loading it back to the SGX
> reserved memory. This problem was not prevalent with the systems that
> were available at the time when SGX was first upstreamed, as the swapped
> memory could grow only up to 128 MB.  However, Icelake Server can have
> gigabytes of SGX memory, and thus this has become a real bottleneck.
> 
> Free the swap space for other use by calling shmem_truncate_range(),
> when a page is faulted back.

This needs a _bit_ more context.  Could you include a few sentences
about what backing memory is?

It's also not a big deal but it is nice to include something like:

	This was found by inspection.

and:

	Reported-by: Dave Hansen <dave.hansen@...ux.intel.com>

Also, what is the end-user-visible effect of this bug?  What would a
user see if they were impacted by this?  How did you determine that this
fixed the issue?  This memory will be recovered when the enclave is torn
down, right?

Do we also need to deal with truncating the PCMD?  (For those watching
along at home, there are two things SGX swaps to RAM: the actual page
data and also some metadata that ensures page integrity and helps
prevent things like rolling back to old versions of swapped pages)