3 ms·

Not sure what you are advocating here. If someone successfully injects code that perform a direct syscall they can successfully use this info leak despite a sa

• TheDong 6y ago
  > If someone successfully injects code that perform a direct syscall they can successfully use this info leak despite a safe and patched (g)libc. As Raymond Chen wrote, that's the other side of the airtight hatch (https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283 https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...). If someone is capable of directly running their own code that ignores libc (or other existing mitigations, such as may exist in javascript runtimes / go compiler) then cool, they can use spectre to perform a timing attack against their own code that they're running. Or they could just read their own memory. Spectre's main risk was for reading other program's memory or for doing so remotely with javascript. If you can already make the process you're attacking run arbitrary syscalls instead of use glibc, then you've already won and no amount of protection will help.
  • lxgr 6y ago
    > If you can already make the process you're attacking run arbitrary syscalls instead of use glibc, then you've already won and no amount of protection will help You're basically arguing that in a post-spectre world, native processes can fundamentally never be a security boundary again, right? I'm wondering if this is necessarily true. For the concrete example at hand, Linux could offer some opt-in mechanism, e.g. an argument to exec(), that restricts syscalls to glibc only. A sandboxing mechanism could then require all executed processes to go through glibc and instantiate them only using that option.