>CVSROOT: /cvs >Module name: src >Changes by: [email protected] 2020/02/18 05:19:11 > >Modified files: > lib/csu/aarch64: md_init.h > lib/libc/arch/aarch64: SYS.h > libexec/ld.so/aarch64: SYS.h rtld_machine.c > >Log message: >Now that the kernel skips the two instructions immediately following >a syscall, replace the double nop with a dsb nsh; isb; sequence which >stops the CPU from speculating any further. This fix was suggested >by Anthony Steinhauser.
Nope. Anthony provided solutions for the kernel-side issues (ERET and friends), but had no proposal for the userland-side variation (SYSC). Philip Guenther came up with the idea of changing the ABI so the kernel jumps over the speculation-blocking instructions. We don't actually need to skip over them they are fine to execute, however these are cache-related instructions and cause a performance loss (depending on cpu model). In related news, Philip also made a version for amd64 with a retpoline-like construct right after syscall (as that is an infinite loop, it needs a jump-over). This demonstrates we can take the same approach if another architecture is found to have a similar spectre issue. I've seen a few misunderstandings about how bad this speculation problem is. In my view, the risk is if program does a syscall which rapidly reaches tsleep and the kernel context switches to another program operating as shared-text (but tweaked perhaps intentionally running shellcode) which can now observe what has made it into caches, and can then intuit some data of the original program (or addresses of such data, in essence performing a form of de-aslr). This presumes some cache behaviours and is more convoluted than most published attack methods, but why not get ahead of the game and neuter the simple problem with a simple solution? Attacks only get better, and someone is surely playing with this problem already...
