Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed

[Rich Freeman <rich0@gentoo.org>]

On Wed, Jan 31, 2018 at 7:07 AM, Nikos Chantziaras <realnc@gmail.com> wrote:
>
> I was under the impression that it's the function that performs the call
> that needs protection. The called function doesn't need protection, because
> if it ends up being actually called, then it's too late already.
>
> For example, if sandboxed, untrusted code wants to speculatively execute a
> memcpy(), then the sandbox would need to call it on behalf of the untrusted
> code. But if the sandbox is protected, the memcpy() call would never be made
> speculatively, since retpoline will trap it. So memcpy() itself doesn't need
> protection. If memcpy() ends up being called, then it's too late. Protecting
> memcpy() doesn't do anything to prevent memcpy() from being called, as it's
> been called already.
>

I think there is some confusion here because in your scenario there
are actually 3 calls being made, and the sandbox is both being called,
and issuing a call.

In your scenario the code executing inside the sandbox calls an API in
the sandbox which in turn calls memcpy.

Code can be vulnerable to Spectre even if it doesn't call anything at
all (variant 2 of Spectre in particular does require a call, variant 1
does not, and who knows what other variants will be discovered in the
future).

In any case, the issue is that your untrusted code inside the sandbox
is calling trusted code via the sandbox API, and it is the sandbox API
that requires protection, as this is where there is a privilege
boundary.

Again, Spectre is not limited to code running in sandboxes.  Your ssh
server could be vulnerable to an incoming ssh client connection if the
client is colluding with another process on the same physical CPU,
assuming your ssh server contains vulnerable code.  Sandboxes are just
a particularly nasty and obvious target of this attack since they
routinely execute untrusted code on the same hardware as the software
being protected from the code.

However, this isn't a reason to just go rebuilding everything with
gcc-7.3 and assuming all is fine.  The maintainers of the upstream
projects really need to assess their code for vulnerabilities, and
treat gcc as a tool that might help solve things.


-- 
Rich