On 31/01/18 13:17, Martin Vaeth wrote:
Nikos Chantziaras <rea...@gmail.com> wrote:
Well, if you're running a local process that is trying to attack you,
you've been compromised already, imo.
By your definition, you are compromised if you surf to the
wrong webpage with enabled javascript.
That's not what was said.
What was said is that software that executes untrusted code inside a
trusted container is affected. You trust the container mechanism, you
don't trust the code executing inside of it. So the container needs to
be protected.
For example, if you don't trust Firefox, don't install Firefox. But you
*do* trust Firefox. What you don't trust is the JS code Firefox is
executing. So Firefox needs protection.
You misunderstand: For the packages which run the code, the mitigations
like retpoline do not help much. It is the packages which _somehow_
react (or can be called) by such a code which need the protection by
retpoline built-in.
And this is an awful lot of packages since it includes also all libraries
which are possibly used by these packages, language interpreters used by
these packages, etc. If in doubt, I would re-emerge the
full -e @world with corresponding compiler switches enabled.
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.
What am I missing here? :-P
