From: Julia Lawall <julia.lawall@lip6.fr>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>,
Linus Torvalds <torvalds@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
linux-arch@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
Greg KH <gregkh@linuxfoundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Elena Reshetova <elena.reshetova@intel.com>,
Alan Cox <alan@linux.intel.com>,
Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier
Date: Thu, 4 Jan 2018 07:28:41 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.20.1801040728140.2148@hadrien> (raw)
In-Reply-To: <CAPcyv4ge14OPyfoQvXHLyXwqX7cjWvm4DouUOc=WrNo1Lr9Qyw@mail.gmail.com>
On Wed, 3 Jan 2018, Dan Williams wrote:
> [ adding Julia and Dan ]
>
> On Wed, Jan 3, 2018 at 5:07 PM, Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote:
> > On Wed, 3 Jan 2018 16:39:31 -0800
> > Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >
> >> On Wed, Jan 3, 2018 at 4:15 PM, Dan Williams <dan.j.williams@intel.com> wrote:
> >> > The 'if_nospec' primitive marks locations where the kernel is disabling
> >> > speculative execution that could potentially access privileged data. It
> >> > is expected to be paired with a 'nospec_{ptr,load}' where the user
> >> > controlled value is actually consumed.
> >>
> >> I'm much less worried about these "nospec_load/if" macros, than I am
> >> about having a sane way to determine when they should be needed.
> >>
> >> Is there such a sane model right now, or are we talking "people will
> >> randomly add these based on strong feelings"?
> >
> > There are people trying to tune coverity and other tool rules to identify
> > cases, and some of the work so far was done that way. For x86 we didn't
> > find too many so far so either the needed pattern is uncommon or .... 8)
> >
> > Given you can execute over a hundred basic instructions in a speculation
> > window it does need to be a tool that can explore not just in function
> > but across functions. That's really tough for the compiler itself to do
> > without help.
> >
> > What remains to be seen is if there are other patterns that affect
> > different processors.
> >
> > In the longer term the compiler itself needs to know what is and isn't
> > safe (ie you need to be able to write things like
> >
> > void foo(tainted __user int *x)
> >
> > and have the compiler figure out what level of speculation it can do and
> > (on processors with those features like IA64) when it can and can't do
> > various kinds of non-trapping loads.
> >
>
> It would be great if coccinelle and/or smatch could be taught to catch
> some of these case at least as a first pass "please audit this code
> block" type of notification.
>
What should one be looking for. Do you have a typical example?
julia
next prev parent reply other threads:[~2018-01-04 6:28 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-03 22:38 [RFC PATCH 0/4] API for inhibiting speculative arbitrary read primitives Mark Rutland
2018-01-03 22:38 ` [RFC PATCH 1/4] asm-generic/barrier: add generic nospec helpers Mark Rutland
2018-01-03 22:38 ` Mark Rutland
2018-01-04 12:00 ` Mark Rutland
2018-01-05 4:21 ` Dan Williams
2018-01-05 9:15 ` Mark Rutland
2018-01-03 22:38 ` [RFC PATCH 2/4] Documentation: document " Mark Rutland
2018-01-03 22:38 ` Mark Rutland
2018-01-03 22:38 ` [RFC PATCH 3/4] arm64: implement nospec_{load,ptr}() Mark Rutland
2018-01-03 22:38 ` Mark Rutland
2018-01-03 22:38 ` [RFC PATCH 4/4] bpf: inhibit speculated out-of-bounds pointers Mark Rutland
2018-01-03 22:38 ` Mark Rutland
2018-01-03 23:45 ` Peter Zijlstra
2018-01-03 23:45 ` Peter Zijlstra
2018-01-04 10:59 ` Mark Rutland
2018-01-04 0:15 ` [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier Dan Williams
2018-01-04 0:15 ` Dan Williams
2018-01-04 0:39 ` Linus Torvalds
2018-01-04 1:07 ` Alan Cox
2018-01-04 1:13 ` Dan Williams
2018-01-04 1:13 ` Dan Williams
2018-01-04 6:28 ` Julia Lawall [this message]
2018-01-04 17:58 ` Dan Williams
2018-01-04 19:26 ` Pavel Machek
2018-01-04 19:26 ` Pavel Machek
2018-01-04 21:43 ` Dan Williams
2018-01-04 22:20 ` Linus Torvalds
2018-01-04 22:23 ` Linus Torvalds
2018-01-04 22:55 ` Alan Cox
2018-01-04 23:06 ` Linus Torvalds
2018-01-04 23:11 ` Alan Cox
2018-01-04 23:11 ` Alan Cox
2018-01-05 0:24 ` Dan Williams
2018-01-04 22:44 ` Pavel Machek
2018-01-04 23:12 ` Dan Williams
2018-01-04 23:12 ` Dan Williams
2018-01-04 23:21 ` Alan Cox
2018-01-04 23:33 ` Pavel Machek
2018-01-05 8:11 ` Julia Lawall
2018-01-04 1:27 ` Jiri Kosina
2018-01-04 1:27 ` Jiri Kosina
2018-01-04 1:41 ` Alan Cox
2018-01-04 1:47 ` Jiri Kosina
2018-01-04 1:47 ` Jiri Kosina
2018-01-04 19:39 ` Pavel Machek
2018-01-04 20:32 ` Alan Cox
2018-01-04 20:32 ` Alan Cox
2018-01-04 20:39 ` Jiri Kosina
2018-01-04 21:23 ` Alan Cox
2018-01-04 21:23 ` Alan Cox
2018-01-04 21:48 ` Pavel Machek
2018-01-04 1:51 ` Dan Williams
2018-01-04 1:51 ` Dan Williams
2018-01-04 1:54 ` Linus Torvalds
2018-01-04 1:54 ` Linus Torvalds
2018-01-04 3:10 ` Williams, Dan J
2018-01-04 4:44 ` Al Viro
2018-01-04 5:44 ` Dan Williams
2018-01-04 5:49 ` Dave Hansen
2018-01-04 5:49 ` Dave Hansen
2018-01-04 5:50 ` Al Viro
2018-01-04 5:55 ` Al Viro
2018-01-04 6:42 ` Dan Williams
2018-01-04 5:01 ` Eric W. Biederman
2018-01-04 6:32 ` Dan Williams
2018-01-04 14:54 ` Eric W. Biederman
2018-01-04 16:39 ` Mark Rutland
2018-01-04 20:56 ` Pavel Machek
2018-01-04 20:56 ` Pavel Machek
2018-01-04 11:47 ` Mark Rutland
2018-01-04 11:47 ` Mark Rutland
2018-01-04 22:09 ` Dan Williams
2018-01-05 14:40 ` Mark Rutland
2018-01-05 16:44 ` Dan Williams
2018-01-05 18:05 ` Dan Williams
2018-01-04 1:59 ` Jiri Kosina
2018-01-04 1:59 ` Jiri Kosina
2018-01-04 2:15 ` Alan Cox
2018-01-04 3:12 ` Alexei Starovoitov
2018-01-04 9:16 ` Reshetova, Elena
2018-01-04 9:16 ` Reshetova, Elena
2018-01-04 20:40 ` Pavel Machek
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=alpine.DEB.2.20.1801040728140.2148@hadrien \
--to=julia.lawall@lip6.fr \
--cc=alan@linux.intel.com \
--cc=dan.carpenter@oracle.com \
--cc=dan.j.williams@intel.com \
--cc=elena.reshetova@intel.com \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).