Messages in this thread | | | Date | Wed, 25 Apr 2018 16:03:15 +0100 | From | Mark Rutland <> | Subject | Re: 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.
| |