From: Jarkko Sakkinen <jarkko@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: linux-sgx@vger.kernel.org, dave.hansen@intel.com,
kai.huang@intel.com, haitao.huang@intel.com, seanjc@google.com,
stable@vger.kernel.org,
Haitao Huang <haitao.huang@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Jethro Beekman <jethro@fortanix.com>
Subject: Re: [PATCH v4] x86/sgx: Fix the call order of synchronize_srcu() in sgx_release()
Date: Sat, 16 Jan 2021 07:12:54 +0200 [thread overview]
Message-ID: <YAJ11v5tuS2uMuNm@kernel.org> (raw)
In-Reply-To: <20210115071809.GA9138@zn.tnic>
On Fri, Jan 15, 2021 at 08:18:09AM +0100, Borislav Petkov wrote:
> On Fri, Jan 15, 2021 at 03:46:38AM +0200, jarkko@kernel.org wrote:
> > From: Jarkko Sakkinen <jarkko@kernel.org>
> >
> > The most trivial example of a race condition can be demonstrated with this
> > example where mm_list contains just one entry:
> >
> > CPU A CPU B
> > sgx_release()
> > sgx_mmu_notifier_release()
> > list_del_rcu()
> > sgx_encl_release()
> > synchronize_srcu()
> > cleanup_srcu_struct()
> >
> > To fix this, call synchronize_srcu() before checking whether mm_list is
> > empty in sgx_release().
>
> To fix what?
>
> Lemme explain one more time: a commit message for a race condition
> fix needs to explain in *detail* what the race condition is. And that
> explanation needs to be understandable months and years from now.
>
> You have the function call order above, now you have to explain what can
> happen. Just how you did here:
>
> https://lkml.kernel.org/r/X/zoarV7gd/LNo4A@kernel.org
OK, I could recall the race that from but that must be partly because I've
been proactively working on it, i.e. getting your point.
So let's say I add this after the sequence:
"The sequence demonstrates a scenario where CPU B starts a new
grace period, which goes unnoticed by CPU A in sgx_release(),
because it did not remove the final entry from the enclave's
mm list."
Would this be sufficient or not?
> > Cc: stable@vger.kernel.org
> > Fixes: 1728ab54b4be ("x86/sgx: Add a page reclaimer")
> > Suggested-by: Sean Christopherson <seanjc@google.com>
> > Suggested-by: Haitao Huang <haitao.huang@linux.intel.com>
> > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
> > ---
> > v4:
> > - Rewrite the commit message.
> > - Just change the call order. *_expedited() is out of scope for this
> > bug fix.
> > v3: Fine-tuned tags, and added missing change log for v2.
> > v2: Switch to synchronize_srcu_expedited().
> > arch/x86/kernel/cpu/sgx/driver.c | 7 ++++++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kernel/cpu/sgx/driver.c b/arch/x86/kernel/cpu/sgx/driver.c
> > index f2eac41bb4ff..53056345f5f8 100644
> > --- a/arch/x86/kernel/cpu/sgx/driver.c
> > +++ b/arch/x86/kernel/cpu/sgx/driver.c
> > @@ -65,11 +65,16 @@ static int sgx_release(struct inode *inode, struct file *file)
> >
> > spin_unlock(&encl->mm_lock);
> >
> > + /*
> > + * The call is need even if the list empty, because sgx_encl_mmu_notifier_release()
>
> "The call is need"?
>
>
> $ git grep sgx_encl_mmu_notifier_release
> $
>
> WTF?
>
> Please be more careful.
Note taken.
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
/Jarkko
next prev parent reply other threads:[~2021-01-16 5:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-15 1:46 [PATCH v4] x86/sgx: Fix the call order of synchronize_srcu() in sgx_release() jarkko
2021-01-15 7:18 ` Borislav Petkov
2021-01-16 5:12 ` Jarkko Sakkinen [this message]
2021-01-18 18:57 ` Borislav Petkov
2021-01-20 14:43 ` Jarkko Sakkinen
2021-01-20 17:34 ` Dave Hansen
2021-01-21 0:26 ` Jarkko Sakkinen
2021-01-22 18:20 ` Haitao Huang
2021-01-20 17:35 ` Sean Christopherson
2021-01-21 0:29 ` Jarkko Sakkinen
2021-01-21 1:19 ` Dave Hansen
2021-01-21 12:55 ` Jarkko Sakkinen
2021-01-21 18:19 ` Dave Hansen
2021-01-22 16:56 ` Dave Hansen
2021-01-23 8:58 ` Jarkko Sakkinen
2021-01-25 15:49 ` Dave Hansen
2021-01-27 17:31 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YAJ11v5tuS2uMuNm@kernel.org \
--to=jarkko@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=haitao.huang@intel.com \
--cc=haitao.huang@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jethro@fortanix.com \
--cc=kai.huang@intel.com \
--cc=linux-sgx@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=seanjc@google.com \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.