mdriley

ECC is not a total solution.

https://www.vusec.net/projects/eccploit/

I am. The goal was to create permalinks to specific sections of CPU reference PDFs.

https://github.com/mmdriley/cpu.fyi

An actual speculation barrier (SB) instruction was added in later releases of ARMv8.0:

- https://cpu.fyi/d/047#G6.11222648

- https://cpu.fyi/d/047#E9.CHDHDDBE

along with the Consumption of Speculative Data Barrier (CSDB): https://cpu.fyi/d/047#G9.10257993

But, as noted elsewhere in this thread, the canonical choice in most systems is DSB/ISB. Just one or the other isn't sufficient because they synchronize different things.

The canonical barriers on other platforms are LFENCE (x86) and SYNC (PowerPC).

For more references, see:

- https://github.com/google/safeside/blob/5fb6f00f/demos/asm/m...

- https://github.com/google/safeside/blob/5fb6f00f/demos/asm/m...

- https://github.com/google/safeside/blob/5fb6f00f/demos/asm/m...

[disclosure: I work on the Safeside project and wrote cpu.fyi as a side project]

For more on the x86 emulation and tracing tech that powers this, see: "Framework for Instruction-level Tracing and Analysis of Program Executions" (2006) https://www.usenix.org/legacy/events/vee06/full_papers/p154-...

They're comparable features. In both cases, a simple but hardened filter is placed in front of some part of the kernel attack surface. Vulnerable processes (e.g. renderers) opt in to these protections so that, in the event of compromise, they're less likely to be vectors for a successful escalation of privilege attack against the kernel syscall interface.

This doesn't "bypass all Windows security measures". As of Windows 8, processes can disable win32k syscalls using SetProcessMitigationPolicy with ProcessSystemCallDisablePolicy.

https://msdn.microsoft.com/en-us/library/windows/desktop/hh7...

This is a bug in NSS. Here's the corresponding bug I filed against Chromium: https://code.google.com/p/chromium/issues/detail?id=349775