From: Dan Williams <dan.j.williams@intel.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: "torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"alan@linux.intel.com" <alan@linux.intel.com>,
"Reshetova, Elena" <elena.reshetova@intel.com>,
"gnomes@lxorguk.ukuu.org.uk" <gnomes@lxorguk.ukuu.org.uk>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"jikos@kernel.org" <jikos@kernel.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>
Subject: Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier
Date: Thu, 4 Jan 2018 14:09:52 -0800 [thread overview]
Message-ID: <CAPcyv4iPg0y0+QNO9h9qkfuDZ2xo769hfzOqTOcrjPi2mFS3Jw@mail.gmail.com> (raw)
In-Reply-To: <20180104114732.utkixumxt7rfuf3g@salmiak>
On Thu, Jan 4, 2018 at 3:47 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> Hi Dan,
>
> Thanks for these examples.
>
> On Thu, Jan 04, 2018 at 03:10:51AM +0000, Williams, Dan J wrote:
>> Note, the following is Elena's work, I'm just helping poke the upstream
>> discussion along while she's offline.
>>
>> Elena audited the static analysis reports down to the following
>> locations where userspace provides a value for a conditional branch and
>> then later creates a dependent load on that same userspace controlled
>> value.
>>
>> 'osb()', observable memory barrier, resolves to an lfence on x86. My
>> concern with these changes is that it is not clear what content within
>> the branch block is of concern. Peter's 'if_nospec' proposal combined
>> with Mark's 'nospec_load' would seem to clear that up, from a self
>> documenting code perspective, and let archs optionally protect entire
>> conditional blocks or individual loads within those blocks.
>
> I'm a little concerned by having to use two helpers that need to be paired. It
> means that we have to duplicate the bounds information, and I suspect in
> practice that they'll often be paired improperly.
Hmm, will they be often mispaired? All of the examples to date the
load occurs in the same code block as the bound checking if()
statement.
> I think that we can avoid those problems if we use nospec_ptr() on its own. It
> returns NULL if the pointer would be out-of-bounds, so we can use it in the
> if-statement.
>
> On x86, that can contain the bounds checks followed be an OSB / lfence, like
> if_nospec(). On arm we can use our architected sequence. In either case,
> nospec_ptr() returns NULL if the pointer would be out-of-bounds.
>
> Then, rather than sequences like:
>
> if_nospec(idx < max) {
> val = nospec_array_load(array, idx, max);
> ...
> }
>
> ... we could have:
>
> if ((elem_ptr = nospec_array_ptr(array, idx, max)) {
> val = *elem_ptr;
> ...
> }
>
> ... which also means we don't have to annotate every single load in the branch
> if the element is a structure with multiple fields.
We wouldn't need to annotate each load in that case, right? Just the
instance that uses idx to calculate an address.
if_nospec (idx < max_idx) {
elem_ptr = nospec_array_ptr(array, idx, max);
val = elem_ptr->val;
val2 = elem_ptr->val2;
}
> Does that sound workable to you?
Relative to the urgency of getting fixes upstream I'm ok with whatever
approach generates the least debate from sub-system maintainers.
One concern is that on x86 the:
if ((elem_ptr = nospec_array_ptr(array, idx, max)) {
...approach produces two conditional branches whereas:
if_nospec (idx < max_idx) {
elem_ptr = nospec_array_ptr(array, idx, max);
....can be optimized to one conditional with the barrier.
Is that convincing enough to proceed with if_nospec + nospec_* combination?
next prev parent reply other threads:[~2018-01-04 22:09 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
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 [this message]
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=CAPcyv4iPg0y0+QNO9h9qkfuDZ2xo769hfzOqTOcrjPi2mFS3Jw@mail.gmail.com \
--to=dan.j.williams@intel.com \
--cc=alan@linux.intel.com \
--cc=elena.reshetova@intel.com \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=gregkh@linuxfoundation.org \
--cc=jikos@kernel.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).