3 ms·

All other chipmakers are 'immune' to Meltdown precisely because the attack is obvious. Cache timing is hard, but speculating execution before checking permissio

by forgotpw2018 9y ago

All other chipmakers are 'immune' to Meltdown precisely because the attack is obvious. Cache timing is hard, but speculating execution before checking permissions is plain dumb. If it was such a mythical attack why doesn't it work on anyone else's chips? Intel screwed up hard on this and I have no sympathy. Hopefully the incoming lawsuits will make up for the massive amount of money wasted for the performance losses

bonzini 9y ago
The most recent ARM chips (cortex A75) are vulnerable.
- forgotpw2018 9y ago
  Didn't know that. The chipmaking business is insular and pretty incestuous, I wonder if the same engineers built both speculative execution units. I've got a friend in CPU design and he's only got about 50 companies he can work for in the world where he could do the same job he does now
  - bonzini 9y ago
    Actually, what I heard through the grapevine is that it became vulnerable after an engineer retired.
  - TomV1971 9y ago
    There are only so many ways to accelerate a CPU by speculating. I’ve written RTL that speculatively fetches data from memory in order to avoid bubbles in a pipeline. Not a CPU, but the concept is exactly the same. If somebody had assigned me to a CPU project without guidance from a security architect and ask me to speculate reads, I’d probably have done the same as Intel. The chance that the same guy did both CPUs is small. It’s just that it’s not an unreasonable way of doing thing if you’re not familiar with these kind of attack.
    - pwg 9y ago
      In the never ending quest for yet more performance out of memory systems that are ever slower than the CPU's, this is likely exactly how it happened. The speculative reads, because they were speculative, were likely viewed as harmless (because the instruction that generated the read would never be committed if the speculation missed anyway, so CPU state (registers/flags) would not be changed improperly). And if anyone even considered the results of the reads, they likely saw them as nothing more than free cache pre-fetch instructions that would enhance performance should the speculative path turn out to be the correct path after-all. And because the push was for yet more performance, free cache pre-fetch operations were likely viewed as a great bonus.
- hah-muh-rabbi 9y ago
  Sadly that doesn't fit OpenBSD's "Intel you suck" narrative.
xucheng 9y ago
You may want to read the following from the Meltdown paper. > We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD. The reasons for this can be manifold. First of all, our implementation might simply be too slow and a more optimized version might succeed. For instance, a more shallow out-of-order execution pipeline could tip the race condition towards against the data leakage. Similarly, if the processor lacks certain features, e.g., no re-order buffer, our current implementation might not be able to leak data. However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.

bonzini 9y ago

The most recent ARM chips (cortex A75) are vulnerable.

forgotpw2018 9y ago
Didn't know that. The chipmaking business is insular and pretty incestuous, I wonder if the same engineers built both speculative execution units. I've got a friend in CPU design and he's only got about 50 companies he can work for in the world where he could do the same job he does now
- bonzini 9y ago
  Actually, what I heard through the grapevine is that it became vulnerable after an engineer retired.
- TomV1971 9y ago
  There are only so many ways to accelerate a CPU by speculating. I’ve written RTL that speculatively fetches data from memory in order to avoid bubbles in a pipeline. Not a CPU, but the concept is exactly the same. If somebody had assigned me to a CPU project without guidance from a security architect and ask me to speculate reads, I’d probably have done the same as Intel. The chance that the same guy did both CPUs is small. It’s just that it’s not an unreasonable way of doing thing if you’re not familiar with these kind of attack.
  - pwg 9y ago
    In the never ending quest for yet more performance out of memory systems that are ever slower than the CPU's, this is likely exactly how it happened. The speculative reads, because they were speculative, were likely viewed as harmless (because the instruction that generated the read would never be committed if the speculation missed anyway, so CPU state (registers/flags) would not be changed improperly). And if anyone even considered the results of the reads, they likely saw them as nothing more than free cache pre-fetch instructions that would enhance performance should the speculative path turn out to be the correct path after-all. And because the push was for yet more performance, free cache pre-fetch operations were likely viewed as a great bonus.
hah-muh-rabbi 9y ago
Sadly that doesn't fit OpenBSD's "Intel you suck" narrative.

xucheng 9y ago

You may want to read the following from the Meltdown paper. > We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD. The reasons for this can be manifold. First of all, our implementation might simply be too slow and a more optimized version might succeed. For instance, a more shallow out-of-order execution pipeline could tip the race condition towards against the data leakage. Similarly, if the processor lacks certain features, e.g., no re-order buffer, our current implementation might not be able to leak data. However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.