Intel's data-leaking Spectre defenses scared off yet again

Researchers at ETH Zurich in Switzerland have found a way around Intel's defenses against Spectre, a family of data-leaking flaws in the x86 giant's processor designs that simply won't die. Sandro Rüegge, Johannes Wikner, and Kaveh Razavi have identified a class of security vulnerabilities they're calling Branch Predictor Race …

[williamyf]

¿Do you think Intel will propagate µcode updates to 7th gen processors or below?

I mean, ¿What will the people running Win11 on 7th gen processors and older will do to remain secure?

And, herein, lies the crux of the matter. Microsoft set the 8th gen intel and Zen2 AMD limit for Win11 at the behest of intel and AMD, as they were not too keen to support older processors for the expected lifetime of the Win11 Codebase (~ 10 years give or take).

So, remmeber, is not intel's and AMD's support (drivers for GPU, MemController and PCH + µcode updates) for the processors at launch in Oct 2021, is support for said processors from intel and AMD in ~2031

After the line is drawn at 8th gen or Zen2, the TPM is a non-issuse as all supported processors have either PTT or fTPM in BIOS.

PS: What Microsoft REALLY wanted was HVCI for Driver Security (to prevent driver hijacking attacks, a.k.a "bring your own faulty driver" attacks), (which are present from 4th gen onwards) AND HVCI (to prevent performance drops from the use of HVCI), present since 7th gen. Most likely intel did not want to complicate the support matrix since 7th gen processorsa can go into 6th gen mobos, meaning drivers galore for way too many PCH/Processor combos.

[Blazde]

Re: ¿Do you think Intel will propagate µcode updates to 7th gen processors or below?

It looks like only back to 8th gen era, and even that only limited mobile chips (which I believe are 6th gen architecture or something, just to confuse things): https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/main/releasenote.md

Comet Lake / 10th gen for mainstream desktop if I read right. Maybe they will add more though, because that's similarly stingy to AMD's first offering of their microcode signature vulnerability fix and they were persuaded to go back a bit further in the end. I fear this inevitably leads to the evolving smartphone business model with fixed security update periods heavily stratified by how premium the chip is.

[Anonymous Coward]

How does this affect people

who never trusted the silicon to start with ?

[Anonymous Coward]

Move complexity away from hardware

These leaks occur because of speculative execution, which can only be beneficial for performance if the code paths are predictable, and the gains of predicting outweigh the cost of misprediction.

Why not lift the prediction to the compiler/interpreter, instead of the hardware/microcode, reduce the complexity of the hardware so you can focus on secure, robust, efficient processing.

You could argue that the gains of speculative execution (~10x?) enable more inefficient code to run, whereas if that code would run on a non-speculative platform, it'd be rewritten because too slower otherwise.

Arguably this especially the case in imperative paradigms, where a lot of focus goes into exactly detailing how practically to solve a problem (~ accidental complexity), with a computing model that is no longer 1-1 with the actual hardware since the 90s.

Instead, paradigms that allow you think and solve in tackling algorithmic (essential) complexity, can delegate the translation to the computing model du jour to compiler frameworks, and then that speculative execution bandaid disappears, because you would only see high entropy execution profiles.

[Blazde]

Why not lift the prediction to the compiler/interpreter, instead of the hardware/microcode, reduce the complexity of the hardware so you can focus on secure, robust, efficient processing.

The predictions are never 100% so the processor will always have to deal with unwinding mispredictions regardless of whether it's responsible for the prediction in the first place. Some of the prediction complexity could be passed to the compiler though (eg. a more elaborate version of profiling and emitting branch hints) and that would make exploiting these vulnerabilities easier because the opaqueness of the branch predictor is one obstacle to researching them. That in turn would hopefully me the CPU bugs get squashed quicker.

bandaid

It's not a bandaid, it's an essential way of mitigating the relatively poor latency of DRAM. The most algorithmically perfect, tightly written pieces of code benefit enormously from pipe-lining/speculative execution/branch prediction. In many cases they're benefiting more than inefficient code, because one of the reasons inefficient code can be so is because it has unpredictable branching (that's not necessary for the task).