6 ms·

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 secur

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!"

cout 5y ago
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.
thinkingemote 5y ago
I fully expect apples M1 chip to get a spectre type vulnerability at some point and then any improvements it had will disappear.
- mhh__ 5y ago
  M1 is vulnerable to Spectre (some variants at least) as far as I'm aware. Any speculation around memory accesses will yield this.
  - zsmi 5y ago
    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 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/5bafb113492047c865c0c8cfbc930155 https://gist.github.com/dougallj/5bafb113492047c865c0c8cfbc9... [2] https://news.ycombinator.com/item?id=28549954 https://news.ycombinator.com/item?id=28549954
guerrilla 5y ago
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=PL5Q2soXY2Zi_FRrloMa2fUYWPGiZUBQo2&index=1 https://www.youtube.com/watch?v=AJBmIaUneB0&list=PL5Q2soXY2Z...
- mhh__ 5y ago
  Onur Mutlu is a really good lecturer, to my eyes at least.
  - guerrilla 5y ago
    Some of his TAs are really funny too :)
kaba0 5y ago
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)
- notriddle 5y ago
  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?
  - kaba0 5y ago
    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.

cout 5y ago

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.

thinkingemote 5y ago

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

mhh__ 5y ago
M1 is vulnerable to Spectre (some variants at least) as far as I'm aware. Any speculation around memory accesses will yield this.
- zsmi 5y ago
  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 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/5bafb113492047c865c0c8cfbc930155 https://gist.github.com/dougallj/5bafb113492047c865c0c8cfbc9... [2] https://news.ycombinator.com/item?id=28549954 https://news.ycombinator.com/item?id=28549954

guerrilla 5y ago

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=PL5Q2soXY2Zi_FRrloMa2fUYWPGiZUBQo2&index=1 https://www.youtube.com/watch?v=AJBmIaUneB0&list=PL5Q2soXY2Z...

mhh__ 5y ago
Onur Mutlu is a really good lecturer, to my eyes at least.
- guerrilla 5y ago
  Some of his TAs are really funny too :)

kaba0 5y ago

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)

notriddle 5y ago
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?
- kaba0 5y ago
  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.