From: Pavel Machek <pavel@ucw.cz>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>,
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 23:44:55 +0100 [thread overview]
Message-ID: <20180104224455.GA22369@amd> (raw)
In-Reply-To: <CAPcyv4g0ZEP_LuXwsf1rJGaG65UHn5sj=DMyMdCnzKD9T-vnyg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2194 bytes --]
Hi!
> >> > What should one be looking for. Do you have a typical example?
> >> >
> >>
> >> See "Exploiting Conditional Branch Misprediction" from the paper [1].
> >>
> >> The typical example is an attacker controlled index used to trigger a
> >> dependent read near a branch. Where an example of "near" from the
> >> paper is "up to 188 simple instructions inserted in the source code
> >> between the ‘if’ statement and the line accessing array...".
> >>
> >> if (attacker_controlled_index < bound)
> >> val = array[attacker_controlled_index];
> >> else
> >> return error;
> >>
> >> ...when the cpu speculates that the 'index < bound' branch is taken it
> >> reads index and uses that value to read array[index]. The result of an
> >> 'array' relative read is potentially observable in the cache.
> >
> > You still need
> >
> > (void) array2[val];
> >
> > after that to get something observable, right?
>
> As far as I understand the presence of array2[val] discloses more
> information, but in terms of the cpu taking an action that it is
> observable in the cache that's already occurred when "val =
> array[attacker_controlled_index];" is speculated. Lets err on the
Well yes, attacker can observe val =
array[attacker_controlled_index]; . But that's not something he's
interested in. So the CPU cheats and attacker has a proof. But he knew
that before.
>side
> of caution and shut down all the observable actions that are already
> explicitly gated by an input validation check. In other words, a low
> bandwidth information leak is still a leak.
What did it leak? Nothing. Attacker had to know
array+attacker_controlled_index, and he now knows
(array+attacker_controlled_index)%CACHELINE_SIZE.
With (void) array2[val];, the attack gets interesting -- I now know
*(array+attacker_controlled_index) % CACHELINE_SIZE ... allowing me to
get information from arbitrary place in memory -- which is useful for
.. reading ssh keys, for example.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2018-01-04 22:44 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 [this message]
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=20180104224455.GA22369@amd \
--to=pavel@ucw.cz \
--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=julia.lawall@lip6.fr \
--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).