Hacker News Reader

Comment by patryn20 | Hacker News Reader

All these new hardware level physics exploits in software fascinate me. At the same time they make me wonder if the hardware will ever truly be able to be secure and perhaps we need to just move on to new methods and concepts in hardware design and maybe trade size for security.

It also brings to mind that Simpsons scene: "Stop stop! He's already dead!"

View on HN

How curious are you? Here's a whole class on exactly that from the authors of the OP [1] at ETH Zürich.

1. https://www.youtube.com/watch?v=AJBmIaUneB0&list=PL5Q2soXY2Z...

Onur Mutlu is a really good lecturer, to my eyes at least.

Some of his TAs are really funny too :)

It also makes me think of the phonograph in Godel Escher Bach. One character made a record player and the other made a record that always caused the record player to break. The crux was that a record player cannot be built that can play all records; it is impossible.

I think moving such complexity to hardware was a mistake (like branch predictor, etc). Perhaps exposing a very low level API to CPU functionality (like microcode level) and JIT compiling existing x86 to that could perhaps work? We have just enough problem managing complexity in software but at least it is fixable there.

(As for the possibility of such, there is already an x86 to x86 JIT compiler that increases performance)

What does any of this stuff have to do with Rowhammer, an attach that doesn't even target the CPU, which just so happens to have ECC on all its registers and cache lines?

Parent was talking about modern hardware in general, and it’s not like CPUs don’t get their own fair share of similar vulnerabilities. Also, a JIT compiler can probably realize that the same memory region gets rowhammered and may throttle execution of such thread.

I fully expect apples M1 chip to get a spectre type vulnerability at some point and then any improvements it had will disappear.

M1 is vulnerable to Spectre (some variants at least) as far as I'm aware.

Any speculation around memory accesses will yield this.

That why the solution is to only allow speculation when it's "ok". M1 is believed to have a number of Spectre-esq security mechanisms built into it to determine just that. For example: https://patents.google.com/patent/US20200192673A1

Also, In dougallj's code [1] the zero of registers should be superfluous so it is assumed the function below is needed to make the experiments run stably by claiming ownership of the registers as part of a general anti-speculation security mechanism.

static int add_prep(uint32_t *ibuf, int instr_type);

The M1 explainer [2] has lot of interesting ideas like this contained inside it.

[1] https://gist.github.com/dougallj/5bafb113492047c865c0c8cfbc9...

[2] https://news.ycombinator.com/item?id=28549954

Reply on news.ycombinator.com