Comment by BeeOnRope | Hacker News Reader

Comment by BeeOnRope | Hacker News Reader

Parent Full thread

I considered this, but we have pretty good evidence that the chipmakers have not been busily secretly patching Spectre attacks:

1) Microcode updates are visible and Spectre fixes are hard to hide: most have performance impacts and most require coordination from the kernel to enable or make effective (which are visible for Linux). There have been a large number of microcode changes tied to published attacks and corresponding fixes, but no corresponding "mystery" updates and hidden kernel fixes to my knowledge which have a similar shape to Spectre fixes.

It's possible they could wait to try to bundle these fixes into a microcode update that arrives for another reason, but the performance impacts and kernel-side changes are harder to hide.

2) If this were the case, we'd expect independent researches to be at least in part re-discovering these attacks, rather than finding completely new ones. This would lead to a case where an attack was already resolved in a release microcode version. To my knowledge this hasn't really happened.

You don't need to patch the errors found during the initial R&D. The patch was made before the hardware was ever sold.

What's left are the attack vectors that Intel's greatest minds didn't discover.

That's true, but it leads the odd assumption that the vendor managed to fix N side-channel attacks before release but 0 thereafter, while random individuals fixed M thereafter over a period of years with N >> M.

This seems to be much less likely than the conclusion that vendors are not in fact fixing many prior to the release and then stopping "cold turkey" after that. Especially since these attacks seem to cross chip versions, in many cases 6+ generations of chips: if vendors had substantial and increasing efforts on new chip versions they'd also be catching issues that applied to old released chips as well. We don't see that happening.

If a bug is not known, most of the incentives to the vendor are to not bother investigating, I suspect.

You could spend arbitrary amounts of time looking for these bugs and find nothing. Simpler and easier to offer a bounty or something and fix it then. If no one publicly finds the bug it doesn't matter to the mfg (and it wouldn't surprise me if there's truth to your supposition that they know about the bug but wait to fix until someone reports it - no public backlash so long as the bug is unknown)

Fixing bugs prior to release seems easy and free, though, especially since many more eyes would also be on the "new" in progress architecture, and proper hardware mitigations that don't cost a lot of performance can be made.

What about the incentive to release "the most secure chips on the market", are you discounting that a bit too much?

Granted that human nature tends to mean these factors don't have a high enough weight, e.g. it's not the safest airplanes that sell the most, it's the cheapest ones that meet the regulations, and the regulations drive safety improvements, for the most part

I guess there's probably some margin in it - if both parties seem about equally vulnerable, there's not much lost. You could expend a lot of effort into security, but the nature of these bugs is still that they are fairly rare, often require pretty significant hurdles, etc. The mfg. could probably spend a lot more money and find a few extra bugs, but who knows if they would have turned into "real" exploits?

Remember that this particular bug isn't actually present on the newest chips either - and 12th/13th gen were shipping before Intel was informed of this bug - so it was fixed eventually, probably incidentally as a result of design changes.

The unknown factor is how much additional money you'd have to invest to gain additional security, given how esoteric many of these bugs are.

This. Downfall affects CPUs released almost a decade ago. The argument of 'Intel caught a ton of these and downfall is the one that got away' doesn't add up. Surely Intel would find at least one issue during development of a new chip that has the property that it _also_ affects older chips. They can hardware-fix it before ever releasing their new chip, but unless they just decided to ignore the vulnerability in their older chips, they'd have starte work on a patch or at least on contacting OS vendors.

None of which is easy to do without the public at large figuring out what happend.

Conclusion: That is highly unlikely to have ever happened. Therefore, this isn't survivor bias and it really is bizarre that chip vendors (or, at least, Intel) doesn't look for this stuff or at least didn't find this.

FWIW. Spectre/meltdown really caught the hardware development world off guard. Speculative execution was well-trodden ground and we thought it was fine. After these attacks, we had legacy designs that we needed to patch in a hurry, and the performance costs of not speculating were unfathomable. A lot of work went into mitigations like new kinds of barriers. But hardware designs are enormous and there is state lurking absolutely everywhere. It’s just a really hard problem.

dan bernstein had pointed out the risk that speculative execution would lead to side-channel attacks years before, but there's a common pattern where security people point out a risk and then vendors dismiss it as impractical until it's demonstrated in practice

In computer engineering grad school, I mentioned to my PI that there was an upcoming hardware security flaw that I had heard about from … sources… and he quickly guessed it was speculative execution related without knowing anything more. I think people knew it was possibly dangerous, but the performance gains from speculative execution were huge enough nobody in Intel/AMD red-teamed the design basically.

probably incentives are not well-aligned

i mean meltdown didn't exactly crater intel's sales

To be fair, there's a lot of low quality security research out there, pointing at totally impractical attacks. But ok, these are not Dan Bernstein ;)

Reply on news.ycombinator.com