[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dfeb01252e0c4280be507a6580ad1202c363330d.camel@intel.com>
Date: Wed, 21 Aug 2024 11:15:31 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "Kuvaiskii, Dmitrii" <dmitrii.kuvaiskii@...el.com>,
"linux-sgx@...r.kernel.org" <linux-sgx@...r.kernel.org>, "Chatre, Reinette"
<reinette.chatre@...el.com>, "jarkko@...nel.org" <jarkko@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"haitao.huang@...ux.intel.com" <haitao.huang@...ux.intel.com>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>
CC: "stable@...r.kernel.org" <stable@...r.kernel.org>,
"mwk@...isiblethingslab.com" <mwk@...isiblethingslab.com>, "Vij, Mona"
<mona.vij@...el.com>, "Qin, Kailun" <kailun.qin@...el.com>
Subject: Re: [PATCH v5 2/3] x86/sgx: Resolve EAUG race where losing thread
returns SIGBUS
On Wed, 2024-08-21 at 03:02 -0700, Dmitrii Kuvaiskii wrote:
> Imagine an mmap()'d file. Two threads touch the same address at the same
> time and fault. Both allocate a physical page and race to install a PTE
> for that page. Only one will win the race. The loser frees its page, but
> still continues handling the fault as a success and returns
> VM_FAULT_NOPAGE from the fault handler.
>
> The same race can happen with SGX. But there's a bug: the loser in the
> SGX steers into a failure path. The loser EREMOVE's the winner's EPC
> page, then returns SIGBUS, likely killing the app.
>
> Fix the SGX loser's behavior. Check whether another thread already
> allocated the page and if yes, return with VM_FAULT_NOPAGE.
>
[...]
> Fixes: 5a90d2c3f5ef ("x86/sgx: Support adding of pages to an initialized enclave")
> Cc: stable@...r.kernel.org
> Reported-by: Marcelina KoĆcielnicka <mwk@...isiblethingslab.com>
> Suggested-by: Kai Huang <kai.huang@...el.com>
> Signed-off-by: Dmitrii Kuvaiskii <dmitrii.kuvaiskii@...el.com>
>
Reviewed-by: Kai Huang <kai.huang@...el.com>
Powered by blists - more mailing lists