linux-kernel - Re: [PATCH V2] x86/sgx: Fix free page accounting

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, 11 Nov 2021 04:55:14 +0200
From:   Jarkko Sakkinen <jarkko@...nel.org>
To:     Reinette Chatre <reinette.chatre@...el.com>,
        dave.hansen@...ux.intel.com, tglx@...utronix.de, bp@...en8.de,
        mingo@...hat.com, linux-sgx@...r.kernel.org, x86@...nel.org
Cc:     seanjc@...gle.com, tony.luck@...el.com, hpa@...or.com,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH V2] x86/sgx: Fix free page accounting

On Wed, 2021-11-10 at 10:51 -0800, Reinette Chatre wrote:
> sgx_should_reclaim() would only succeed when sgx_nr_free_pages goes 
> below the watermark. Once sgx_nr_free_pages becomes corrupted there is 
> no clear way in which it can correct itself since it is only ever 
> incremented or decremented.

So one scenario would be:

1. CPU A does a READ of sgx_nr_free_pages.
2. CPU B does a READ of sgx_nr_free_pages.
3. CPU A does a STORE of sgx_nr_free_pages.
4. CPU B does a STORE of sgx_nr_free_pages.

?

That does corrupt the value, yes, but I don't see anything like this
in the commit message, so I'll have to check.

I think the commit message is lacking a concurrency scenario, and the
current transcripts are a bit useless.

/Jarkko