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 for Android: free password hash cracker in your pocket

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

Date:   Sun, 7 Nov 2021 22:34:02 -0800
From:   Dave Hansen <dave.hansen@...el.com>
To:     Jarkko Sakkinen <jarkko@...nel.org>
Cc:     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>,
        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/7/21 2:28 PM, Jarkko Sakkinen wrote:
>> When you place PCMD in a page, you do a get_page().  The refcount goes
>> up by one.  So, a PCMD page with one PCMD will (I think) have a refcount
>> of 3.  If you totally fill it up with 31 *more* PCMD entries, it will
>> have a refcount of 34.  You do *not* do a put_page() on the PCMD page at
>> the end of the allocation phase.
>>
>> When the backing storage is freed, you drop the refcount.  So, going
>> from 32 PCMD entries to 31 entries in a page, you go from 34->33.
>>
>> When that refcount drops to 2, you know there is no more data in the
>> page that's useful.  At that point you can truncate it out of the
>> backing storage.
>>
>> There's no reason to scan the page, or a boatload of other metadata.
>> Just keep a refcount.  Just use the *existing* 'struct page' refcount.
> Right! Thank you, I'll use this approach, and check that the refcount
> actually behaves that way you described.

Thinking about this a bit more...  We don't want to use the normal
get/put_page() refcount for this.  If we do, it will pin the page while
there is any data in it, preventing it from being reclaimed (swapped).

That isn't to say that we can't keep *a* refcount, just that we can't
use the page refcount for this.

I still like the idea of just scanning the whole page for zeros.