lkml.org 
[lkml]   [2018]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] kernel: sys: fix potential Spectre v1
On Wed, May 23, 2018 at 04:07:37PM +0100, Mark Rutland wrote:
> I think that either way, we have a potential problem if the compiler
> generates a branch dependent on the result of validate_index_nospec().
>
> In that case, we could end up with codegen approximating:
>
> bool safe = false;
>
> if (idx < bound) {
> idx = array_index_nospec(idx, bound);
> safe = true;
> }
>
> // this branch can be mispredicted
> if (safe) {
> foo = array[idx];
> }
>
> ... and thus we lose the nospec protection.

I was assuming the compiler would not do that, that's pretty stupid
code-gen. But you're right in calling that out, because I think it's
entirely in it's right to do that :/

> I also suspect that compiler transformations mean that this might
> already be the case for patterns like:
>
> if (idx < bound) {
> safe_idx = array_index_nospec(idx, bound)];
> ...
> foo = array[safe_idx];
> }
>
> ... if the compiler can transform that to something like:
>
> if (idx < bound) {
> idx = array_index_nospec(idx, bound);
> }
>
> // can be mispredicted
> if (idx < bound) {
> foo = array[idx];
> }
>
> ... which I think a compiler might be capable of, depending on the rest
> of the function body (e.g. if there's a common portion shared with the
> else case).
>
> I'll see if I can trigger that in a test case. :/

*groan*...

\
 
 \ /
  Last update: 2018-05-23 18:28    [W:0.086 / U:22.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site