Hacker News Reader

Comment by yjftsjthsd-h | Hacker News Reader

> One day we were chatting in a group meeting and he said he was working on a TPC-C benchmark that was spending too much time in the SCSI disk driver, so he wrote a 10-line awk script running against kernel memory to look at the SPARC machine code execution path and find which branches were being predicted wrong, then wrote another awk script to flip the branch prediction bits in memory and it showed a significant speedup.

SPARC exposed read and write access to branch prediction!? That's... fascinating. Here I thought branch prediction was always a completely opaque thing that the CPU did internally and maybe if you were lucky it might let the program be able to know that it was happening after the fact. Hm... I wonder if it's easier to perform Spectre type attacks if you can just ask the CPU about that kind of behavior? No need to do timing attacks if the CPU will just tell you

View on HN

SPARC had instructions (BP, Branch with Prediction) which hinted the branch predictor whether the branch was likely or unlikely. Presumably this script just edited the opcodes in memory to avoid needing to figure out how to change the generated code from the compiler, recompile, and replace the kernel.

IIRC you specified the likely path in assembly code, but not all SPARCs had those opcodes. They were some sort of extention. By default they had simple fixed prediction (branch would not be taken, backwards branch would be taken etc).

Some of the pentium series also had settable branch prediction bias flags.

These were simpler RISC implementations in those days, the compiler optimizer stage was in charge of deciding whether to set the branch bit or not, and the prefetch would do what the bit said, and stall if it got it wrong.

It would seem more likely to be a scsi/kex timing issue and there are direct hacks into that when you have a loose dev/kmem philsophy.

If you are/can directly hack the pipeline, Adrian better have included that script in the bmark publish. Probably not, because then directors would be calling him at 2am because XYZ corps workload was slow and “could we have your nop script?”

Most processors have hint instructions that let you tell it which branch you think will be likely.

I would assume you have to be root to do this branch predictor stuff. If you're root, why do you need Spectre? If you're attacking some trusted execution thing, then I assume you wouldn't be able to do the branch predictor stuff.

Because you might be root in one VM or container, and you are trying to access another VM or container.

Oh, interesting. I wonder if the hypervisor would be able to prevent the VM from using those features of the CPU.

it usually does not. reason why you run security analysts of untrusted code first in a qemu without virtualization.

While your hypervisor may not implement it, ARM allows you to configure this kind of operations.

See for example

https://developer.arm.com/documentation/ddi0595/2020-12/AArc...

oh qemu supports this alright, since 8.x

but good luck 1. having a cpu with it (can't wait for arm laptops and needing caniuse.org for my assembly code), and 2. figuring out how to use it

Reply on news.ycombinator.com