On Wed, Jan 31, 2018 at 7:07 AM, Nikos Chantziaras <rea...@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
