lkml.org 
[lkml]   [2018]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Smatch check for Spectre stuff
On Wed, Apr 25, 2018 at 03:48:52PM +0100, Alan Cox wrote:
> > 2) Compiler transformations can elide binary operations, so we cannot
> > rely on source level AND (&) or MOD (%) operations to narrow the
> > range of an expression, regardless of the types of either operand.
> >
> > This means that source-level AND and MOD operations cannot be relied
> > upon under speculation.
>
> You need to use volatiles and memory barriers if trying to do it
> explicitly in C. The compilers will do some really quite insanely
> brilliant things otherwise. That's one reason that not using fences is
> really tricky and belongs wrapped in helpers.

Sure thing -- the point is that source-level analysis tools must take
that into account.

> > I suspect this means *many* more potential spectre gadgets. :(
>
> I expect so as well as probably a lot of false positives - the tools in
> the space are all pretty new.
>
> Array access isn't always needed either. Remember that something as
> simple as
>
> x = size_table[user];
> memset(buf, 0, x);
>
> can speculatively reveal things, as can 'classical' side channels such as
> variable length instruction timings.

As discussed in the other sub-thread, the plan is to kill sequences at
the first load, which should prevent the leak via a subsequent
value-dependent sequence.

i.e. the above would be:

user_nospec = array_index_nospec(user, ARRAY_SIZE(size_table));
x = size_table[user_nospec];
memset(buf, 0, x);

... which IIUC avoids the leak in this particular case.

Mark.

\
 
 \ /
  Last update: 2018-04-25 17:03    [W:0.059 / U:6.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site