ARM64 CPUs speculatively execute instructions after ERET

twitter.com

73 points·devhwrng··9 comments

Interesting that BSD [1] and Linux [2] have different patches. AFAICT Linux uses the speculation barrier and BSD has data+instruction barriers instead.

If you're returning from an exception handler, I'm guessing you don't care how hard you flush the pipeline? Is one of these more optimal / more safe or are they mostly equivalent?

[1] https://ftp.openbsd.org/pub/OpenBSD/patches/6.6/common/014_e...

[2] https://patchwork.kernel.org/patch/10700361/

Is there an actual thing as a “speculation barrier“ instruction on any real platform? Linux has it be ish/dsb because nothing seems to support it: https://github.com/torvalds/linux/blob/cef7298262e9af841fb70...

That looks like an "alternative" block, which means it's patched at runtime to use that instruction when it's available.

Right, it's there because future CPUs may have that instruction. Do you know of any that have it today?

The retconned VERW may qualify in some sense.

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...

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

Unrelated question: are you using PDF.js to render those?

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

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

And it does that quite well. Thanks for this!

Reply on news.ycombinator.com