3 ms·

Meltdown is an Intel-specific design mistake dating back a decade. It is also the bigger fish. Spectre, while real, has been a gift to Intel to use as a smokesc

Meltdown is an Intel-specific design mistake dating back a decade. It is also the bigger fish. Spectre, while real, has been a gift to Intel to use as a smokescreen in PR and reporting.

wsxcde 9y ago
But that is what it is, a design mistake -- a totally non-obvious design mistake. I believe the number of people who would have looked at Intel's design decisions related to meltdown and thought to themselves this was a credible security holeis very close to zero. I can say this with some confidence because I used to do processor performance modeling for AMD, security verification for Intel and now do research in hardware security verification. This is not a bug until you look at the exploit. I am certain AMD/ARM/RISC-V or whatever other Intel competitor you can think of have similar security bugs in them. It's just a question of whether people will find them. In fact, knowing what I know about AMD and Intel, I'm willing to bet these other companies have more security holes, not less than Intel
- xigency 9y ago
  Performing even speculative operations on protected memory is a mistake. Part of the speculation should be to check the protection before performing operations on the data. This _flaw_ is precisely why protected information is leaked via side-channel in the Meltdown attack. They decided on this design without realizing it was a mistake -- but that is exactly what it is. Same as Takata's airbag design which used an unstable compound. They were not unaware of the chemical propties of their inflating device. Instead, they miscalculated the impact.
  - wsxcde 9y ago
    > Performing even speculative operations on protected memory is a mistake. Every high performance processor in the world performs speculative cache updates. That did not cause meltdown, nor did it cause spectre.
  - throwaway203937 9y ago
    I think that a lot of discussion here is missing a key design aspect of modern speculative cores: the "late check" of permissions was likely not a sloppy shortcut or oversight, but rather due to a common design principle, or separation-of-concerns, in modern cores: exception-condition handling and speculation flush/restart are ordinarily handled when the excepting instruction reaches retirement, because at that stage, instructions are back in order again, and they are "real" (could not be flushed by any earlier mis-speculation). It seems completely natural w.r.t. modern design principles to handle page faults at retire. In other words, as obvious as the vulnerability is in hindsight, the general design is "textbook computer architecture" -- at least it would not raise any eyebrows. In fact the alternative, eager checking, would be the less obvious design, because almost every other exception is handled at retirement, and it would require careful thought and some additional complexity: do you cancel the instruction? (Potential problem: dependent instructions are already scheduled and will expect your result next cycle, because scheduling is deeply pipelined. Now you need some auxiliary scheduling information to let you cancel those too, which will be very complex and ripe for bugs.) Do you zero out the result? (Potential timing issue: this requires a few more gate delays between the data-cache word-select MUX and the results bus, a pipeline stage that's probably already timing-critical.) Clearly, AMD and ARM made other design decisions, but I would bet this is due to incidental aspects of their pipelines rather than an explicit prediction of a Meltdown-like vulnerability. Overall: the issue looks very obvious in hindsight, but it arises due to an unexpected interaction of common design principles of modern cores, rather than a negligent oversight or shortcut. (I worked on processor design for a while; throwaway for obvious reasons)
    - wilun 9y ago
      It's not about generating the exception. It's about not operating on privileged data. (And not loading it to registers seems a good way to not operate on them, btw)... Generating the exception can still obviously happen at retire. It's not even a problem to run an extra bunch of code with constant placeholder garbage data (if that would be too costly to interrupt it sooner), given you know all is gonna be cancelled by the eventual exception anyway. But you just don't fucking load the privileged data to begin with!!! Timing side channel attacks have been known for maybe a decade for heaven's sake. Even if Meltdown would not have been as simple as it is, as soon as you speculate on privileged data you are completely dead; because there will be tons of obvious side channels to retrieve said data. (measuring occupation of execution units through HT comes to mind, actually before meltdown was disclosed I thought this was the trick to leak the data that should not have been loaded, turns out it was even simpler...) Maybe the field needs better "textbooks", or to return to the classics about speculative execution. I've yet to see anybody blaming Intel for Spectre. Some other designers might have made the same mistake as Intel for Meltdown, but that does not make it less a mistake. Maybe AMD only had it correctly by some kind of strange accident, and it will probably be very hard to know. That would still be a silly mistake for Intel, even then.

Meltdown is an Intel-specific design mistake dating back a decade. It is also the bigger fish. Spectre, while real, has been a gift to Intel to use as a smokescreen in PR and reporting.

wsxcde 9y ago

But that is what it is, a design mistake -- a totally non-obvious design mistake. I believe the number of people who would have looked at Intel's design decisions related to meltdown and thought to themselves this was a credible security holeis very close to zero. I can say this with some confidence because I used to do processor performance modeling for AMD, security verification for Intel and now do research in hardware security verification. This is not a bug until you look at the exploit. I am certain AMD/ARM/RISC-V or whatever other Intel competitor you can think of have similar security bugs in them. It's just a question of whether people will find them. In fact, knowing what I know about AMD and Intel, I'm willing to bet these other companies have more security holes, not less than Intel

xigency 9y ago
Performing even speculative operations on protected memory is a mistake. Part of the speculation should be to check the protection before performing operations on the data. This _flaw_ is precisely why protected information is leaked via side-channel in the Meltdown attack. They decided on this design without realizing it was a mistake -- but that is exactly what it is. Same as Takata's airbag design which used an unstable compound. They were not unaware of the chemical propties of their inflating device. Instead, they miscalculated the impact.
- wsxcde 9y ago
  > Performing even speculative operations on protected memory is a mistake. Every high performance processor in the world performs speculative cache updates. That did not cause meltdown, nor did it cause spectre.
- throwaway203937 9y ago
  I think that a lot of discussion here is missing a key design aspect of modern speculative cores: the "late check" of permissions was likely not a sloppy shortcut or oversight, but rather due to a common design principle, or separation-of-concerns, in modern cores: exception-condition handling and speculation flush/restart are ordinarily handled when the excepting instruction reaches retirement, because at that stage, instructions are back in order again, and they are "real" (could not be flushed by any earlier mis-speculation). It seems completely natural w.r.t. modern design principles to handle page faults at retire. In other words, as obvious as the vulnerability is in hindsight, the general design is "textbook computer architecture" -- at least it would not raise any eyebrows. In fact the alternative, eager checking, would be the less obvious design, because almost every other exception is handled at retirement, and it would require careful thought and some additional complexity: do you cancel the instruction? (Potential problem: dependent instructions are already scheduled and will expect your result next cycle, because scheduling is deeply pipelined. Now you need some auxiliary scheduling information to let you cancel those too, which will be very complex and ripe for bugs.) Do you zero out the result? (Potential timing issue: this requires a few more gate delays between the data-cache word-select MUX and the results bus, a pipeline stage that's probably already timing-critical.) Clearly, AMD and ARM made other design decisions, but I would bet this is due to incidental aspects of their pipelines rather than an explicit prediction of a Meltdown-like vulnerability. Overall: the issue looks very obvious in hindsight, but it arises due to an unexpected interaction of common design principles of modern cores, rather than a negligent oversight or shortcut. (I worked on processor design for a while; throwaway for obvious reasons)
  - wilun 9y ago
    It's not about generating the exception. It's about not operating on privileged data. (And not loading it to registers seems a good way to not operate on them, btw)... Generating the exception can still obviously happen at retire. It's not even a problem to run an extra bunch of code with constant placeholder garbage data (if that would be too costly to interrupt it sooner), given you know all is gonna be cancelled by the eventual exception anyway. But you just don't fucking load the privileged data to begin with!!! Timing side channel attacks have been known for maybe a decade for heaven's sake. Even if Meltdown would not have been as simple as it is, as soon as you speculate on privileged data you are completely dead; because there will be tons of obvious side channels to retrieve said data. (measuring occupation of execution units through HT comes to mind, actually before meltdown was disclosed I thought this was the trick to leak the data that should not have been loaded, turns out it was even simpler...) Maybe the field needs better "textbooks", or to return to the classics about speculative execution. I've yet to see anybody blaming Intel for Spectre. Some other designers might have made the same mistake as Intel for Meltdown, but that does not make it less a mistake. Maybe AMD only had it correctly by some kind of strange accident, and it will probably be very hard to know. That would still be a silly mistake for Intel, even then.