1 |
On Wed, Jan 31, 2018 at 7:07 AM, Nikos Chantziaras <realnc@×××××.com> wrote: |
2 |
> |
3 |
> I was under the impression that it's the function that performs the call |
4 |
> that needs protection. The called function doesn't need protection, because |
5 |
> if it ends up being actually called, then it's too late already. |
6 |
> |
7 |
> For example, if sandboxed, untrusted code wants to speculatively execute a |
8 |
> memcpy(), then the sandbox would need to call it on behalf of the untrusted |
9 |
> code. But if the sandbox is protected, the memcpy() call would never be made |
10 |
> speculatively, since retpoline will trap it. So memcpy() itself doesn't need |
11 |
> protection. If memcpy() ends up being called, then it's too late. Protecting |
12 |
> memcpy() doesn't do anything to prevent memcpy() from being called, as it's |
13 |
> been called already. |
14 |
> |
15 |
|
16 |
I think there is some confusion here because in your scenario there |
17 |
are actually 3 calls being made, and the sandbox is both being called, |
18 |
and issuing a call. |
19 |
|
20 |
In your scenario the code executing inside the sandbox calls an API in |
21 |
the sandbox which in turn calls memcpy. |
22 |
|
23 |
Code can be vulnerable to Spectre even if it doesn't call anything at |
24 |
all (variant 2 of Spectre in particular does require a call, variant 1 |
25 |
does not, and who knows what other variants will be discovered in the |
26 |
future). |
27 |
|
28 |
In any case, the issue is that your untrusted code inside the sandbox |
29 |
is calling trusted code via the sandbox API, and it is the sandbox API |
30 |
that requires protection, as this is where there is a privilege |
31 |
boundary. |
32 |
|
33 |
Again, Spectre is not limited to code running in sandboxes. Your ssh |
34 |
server could be vulnerable to an incoming ssh client connection if the |
35 |
client is colluding with another process on the same physical CPU, |
36 |
assuming your ssh server contains vulnerable code. Sandboxes are just |
37 |
a particularly nasty and obvious target of this attack since they |
38 |
routinely execute untrusted code on the same hardware as the software |
39 |
being protected from the code. |
40 |
|
41 |
However, this isn't a reason to just go rebuilding everything with |
42 |
gcc-7.3 and assuming all is fine. The maintainers of the upstream |
43 |
projects really need to assess their code for vulnerabilities, and |
44 |
treat gcc as a tool that might help solve things. |
45 |
|
46 |
|
47 |
-- |
48 |
Rich |