4 ms·

I think this is too dark a post, but it shows a useful shock: Computer Science likes to live in proximity to pure mathematics, but it lives between EE and mathe

I think this is too dark a post, but it shows a useful shock: Computer Science likes to live in proximity to pure mathematics, but it lives between EE and mathematics. And neglecting the EE side is dangerous - which not only Spectre showed, but which should have been obvious at the latest when Rowhammer hit. There's actual physics happening, and we need to be aware of it. If you want to prove something about code, you probably have to prove microop semantics upward from verilog, otherwise you're proving on a possibly broken model of reality. Second-order effects are complicated.

SomeHacker44 9y ago
"There's actual physics happening, and we need to be aware of it." Yes, maybe abstractly. However, the Spectre flaw is well above the level of physics. There may be physics flaws as well (e.g., Rowhammer), but Spectre is an architectural flaw in the design of some microprocessors, in that it leaks information by e.g. cache timing attacks and non-program-state data (e.g., branch prediction tables). These can be redesigned above the physics layer.
- mannykannot 9y ago
  I can't speak for the author of that quote, but cache timing appears to be as much a physics phenomenon as is the behavior that allows rowhammer to work. I cannot see any point where the author implied that the solution can only be found in the physics layer.
  - SomeHacker44 9y ago
    The cache timing is not a physics phenomenon. It's an isolation phenomenon. Speculative execution is loading data into the cache, exactly as designed. The instructions that used the speculatively loaded cached data were not retired, exactly as designed. Requesting that cached data later (in actually retired instructions) is faster assuming it's still cached, which is a reasonable likelihood given the locality of the access. That's the timing attack vector. There's no physics here - it's all architecturally operating as designed. That's why the design has a security flaw, and there is no physics problem here. (There may be others, elsewhere, of course, but none in Spectre or Meltdown that I am aware of.)
    - mst 9y ago
      From my POV "the locality of the access" making a speed difference is a physics phenomenon.
    - mannykannot 9y ago
      The fact that is working as designed has no bearing on the question of whether it is a physics problem. You could just as well say (as Intel's press release seemed to to be trying to imply) that there isn't a fault at all, whether physical or not, because it is working as designed. But your own description of it working as designed is within the context of a state-machine model, and in that model, there is no attack vector; that only appears when you take the physics of the implementation into account. There wouldn't even be a cache except for the temporal physics of memory access. That it works as designed is beside the point because the design did not take the physics into account. Looking at it from the other direction, how do you conclude that rowhammer does exploit a physical phenomenon, without being inconsistent about what that means?
chias 9y ago
This is a bit of a nitpick, but when you say Computer Science I think you mean Software Engineering and/or Computer Engineering. These are very different fields, and Computer Science is by-and-large agnostic of any actual physics. As an anecdote: my Computer Science PhD dissertation contained all of about 12 lines of pseudocode, and these are only to provide a more direct description of an idea than I was able to provide with several paragraphs of prose. Hardware / architecture / physics is entirely irrelevant to it -- while any implementation of the ideas therein should be aware of hardware / physics / etc., we are solidly entering the realm of engineering at that point.
ddellacosta 9y ago
Rowhammer I can understand, but how do you come to that conclusion--"neglecting the EE side is dangerous"--from analyzing Spectre? Does speculative execution rely somehow on physical effects? I can't find anything ( for example here: https://en.wikipedia.org/wiki/Spectre_(security_vulnerability) https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit... ) that suggests there is a physical component to this vulnerability.
- mst 9y ago
  I'd argue that using timing differences due to physical limitations of the hardware that to exfiltrate data based on whether or not it's cached is very definitely 'relying on physical effects'
  - ddellacosta 9y ago
    > timing differences due to physical limitations of the hardware I see; so you're talking about step two as described here, do I have that right? https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)#Detailed_explanation https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit... This seems like a failure of algorithm design to me, in the sense of not starting with a better model that more accurately encodes the possibility of timing attacks. That being the case it appears to me to be a problem still firmly residing in the domain of computer science. But, I'm a programmer, not a chip designer, and I have very little knowledge of this field, so I'm probably biased and not thinking about this correctly or with enough nuance.
    - mst 9y ago
      Quoting the thread root: > Computer Science likes to live in proximity to pure mathematics, but it lives between EE and mathematics which doesn't disagree with "firmly residing in the domain of computer science" - it's merely a question of nobody having factored the right bit of EE into the right bit of math to get the right model.
Qwertious 9y ago
>There's actual physics happening, and we need to be aware of it. More specifically, we're not running software on physics, software is physics - CPUs are simply physical structures designed in such a way as to be extremely easily mathematically modeled. Software is nothing more than runtime configuration of hardware.
zbentley 9y ago
> If you want to prove something about code, you probably have to prove microop semantics upward from verilog What if your chip fab doesn't obey the HDL's instructions? You're always "trusting trust" at some level. See also this horror story: https://www.teamten.com/lawrence/writings/coding-machines/ https://www.teamten.com/lawrence/writings/coding-machines/.
qznc 9y ago
> The "abstractions" we manipulate are not, in point of fact, abstract. They are backed by real pieces of code, running on real machines, consuming real energy, and taking up real space. [...] What is possible is to temporarily set aside concern for some (or even all) of the laws of physics. – Gregor Kiczales, 1992

SomeHacker44 9y ago

"There's actual physics happening, and we need to be aware of it." Yes, maybe abstractly. However, the Spectre flaw is well above the level of physics. There may be physics flaws as well (e.g., Rowhammer), but Spectre is an architectural flaw in the design of some microprocessors, in that it leaks information by e.g. cache timing attacks and non-program-state data (e.g., branch prediction tables). These can be redesigned above the physics layer.

mannykannot 9y ago
I can't speak for the author of that quote, but cache timing appears to be as much a physics phenomenon as is the behavior that allows rowhammer to work. I cannot see any point where the author implied that the solution can only be found in the physics layer.
- SomeHacker44 9y ago
  The cache timing is not a physics phenomenon. It's an isolation phenomenon. Speculative execution is loading data into the cache, exactly as designed. The instructions that used the speculatively loaded cached data were not retired, exactly as designed. Requesting that cached data later (in actually retired instructions) is faster assuming it's still cached, which is a reasonable likelihood given the locality of the access. That's the timing attack vector. There's no physics here - it's all architecturally operating as designed. That's why the design has a security flaw, and there is no physics problem here. (There may be others, elsewhere, of course, but none in Spectre or Meltdown that I am aware of.)
  - mst 9y ago
    From my POV "the locality of the access" making a speed difference is a physics phenomenon.
  - mannykannot 9y ago
    The fact that is working as designed has no bearing on the question of whether it is a physics problem. You could just as well say (as Intel's press release seemed to to be trying to imply) that there isn't a fault at all, whether physical or not, because it is working as designed. But your own description of it working as designed is within the context of a state-machine model, and in that model, there is no attack vector; that only appears when you take the physics of the implementation into account. There wouldn't even be a cache except for the temporal physics of memory access. That it works as designed is beside the point because the design did not take the physics into account. Looking at it from the other direction, how do you conclude that rowhammer does exploit a physical phenomenon, without being inconsistent about what that means?

chias 9y ago

This is a bit of a nitpick, but when you say Computer Science I think you mean Software Engineering and/or Computer Engineering. These are very different fields, and Computer Science is by-and-large agnostic of any actual physics. As an anecdote: my Computer Science PhD dissertation contained all of about 12 lines of pseudocode, and these are only to provide a more direct description of an idea than I was able to provide with several paragraphs of prose. Hardware / architecture / physics is entirely irrelevant to it -- while any implementation of the ideas therein should be aware of hardware / physics / etc., we are solidly entering the realm of engineering at that point.

ddellacosta 9y ago

Rowhammer I can understand, but how do you come to that conclusion--"neglecting the EE side is dangerous"--from analyzing Spectre? Does speculative execution rely somehow on physical effects? I can't find anything ( for example here: https://en.wikipedia.org/wiki/Spectre_(security_vulnerability) https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit... ) that suggests there is a physical component to this vulnerability.

mst 9y ago
I'd argue that using timing differences due to physical limitations of the hardware that to exfiltrate data based on whether or not it's cached is very definitely 'relying on physical effects'
- ddellacosta 9y ago
  > timing differences due to physical limitations of the hardware I see; so you're talking about step two as described here, do I have that right? https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)#Detailed_explanation https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit... This seems like a failure of algorithm design to me, in the sense of not starting with a better model that more accurately encodes the possibility of timing attacks. That being the case it appears to me to be a problem still firmly residing in the domain of computer science. But, I'm a programmer, not a chip designer, and I have very little knowledge of this field, so I'm probably biased and not thinking about this correctly or with enough nuance.
  - mst 9y ago
    Quoting the thread root: > Computer Science likes to live in proximity to pure mathematics, but it lives between EE and mathematics which doesn't disagree with "firmly residing in the domain of computer science" - it's merely a question of nobody having factored the right bit of EE into the right bit of math to get the right model.

Qwertious 9y ago

>There's actual physics happening, and we need to be aware of it. More specifically, we're not running software on physics, software is physics - CPUs are simply physical structures designed in such a way as to be extremely easily mathematically modeled. Software is nothing more than runtime configuration of hardware.

zbentley 9y ago

> If you want to prove something about code, you probably have to prove microop semantics upward from verilog What if your chip fab doesn't obey the HDL's instructions? You're always "trusting trust" at some level. See also this horror story: https://www.teamten.com/lawrence/writings/coding-machines/ https://www.teamten.com/lawrence/writings/coding-machines/.

qznc 9y ago

> The "abstractions" we manipulate are not, in point of fact, abstract. They are backed by real pieces of code, running on real machines, consuming real energy, and taking up real space. [...] What is possible is to temporarily set aside concern for some (or even all) of the laws of physics. – Gregor Kiczales, 1992