[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <D0WN15R16S1S.PRG8LSXA8470@kernel.org>
Date: Mon, 29 Apr 2024 16:24:04 +0300
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Jarkko Sakkinen" <jarkko@...nel.org>, "Dmitrii Kuvaiskii"
<dmitrii.kuvaiskii@...el.com>, <dave.hansen@...ux.intel.com>,
<kai.huang@...el.com>, <haitao.huang@...ux.intel.com>,
<reinette.chatre@...el.com>, <linux-sgx@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Cc: <mona.vij@...el.com>, <kailun.qin@...el.com>, <stable@...r.kernel.org>,
Marcelina KoĆcielnicka <mwk@...isiblethingslab.com>
Subject: Re: [PATCH 1/2] x86/sgx: Resolve EAUG race where losing thread
returns SIGBUS
On Mon Apr 29, 2024 at 4:22 PM EEST, Jarkko Sakkinen wrote:
> On Mon Apr 29, 2024 at 4:04 PM EEST, Jarkko Sakkinen wrote:
> > > Fix these two bugs (1) by returning VM_FAULT_NOPAGE to the generic Linux
> > > fault handler so that no signal is sent to userspace, and (2) by
> > > replacing sgx_encl_free_epc_page() with sgx_free_epc_page() so that no
> > > EREMOVE is performed.
> >
> > What is the collateral damage caused by ENCLS[EREMOVE]?
>
> Have you measured cost of eremove on an empty page?
>
> I tried to lookup for a thread from lore because I have a faint memory
> that it was concluded that its cost irrelevant. Please correct if I'm
> wrong.
Also pseudocode for EREMOVE supports this as it just returns without
actually doing anything.
BR, Jarkko
Powered by blists - more mailing lists