Intel Publishes Spectre and Meltdown Hardware Plans: Fixed Gear Later This Year

From what I underst and this fixes variants two and three which are cross ring and cross process data extraction. I believe their hardware mitigation is to separate the caches between those (or something to that effect). So there will still be a minor penalty hit for running multiple identical process compared to before.

That's my interpretation though, I don't know enough to say that's the correct interpretation.

> to fix it without some performance penalty.

10nm + higher frequency?

An additional check can be made in the same time in parallel if there's extra hardware (specific gates) assigned to do that.

Isn't it clear? Performance is top priority and security is also top priority.

edit: apparently sarcasm on the web doesn't work very well.

They probably aren't sure yet.

It's doubtful Intel would delay plans too much to work on such subject, and its even more doubtful the result would even be better for anybody: we would have to use the old completely unpatched chips for longer...

It's better for everybody to have more frequent gradual fixes, even if the firsts are not 100% complete.

That's a good point.

Ideally the ISA would allow user level code to also toggle a flag that affects the BTB. That would allow embedding JIT code while guarding against Spectre 2 (fixing the BTB injection).

I don't think you really need more than that though. Reading arbitrary memory would seem to require a Spectre 1-type attack instead. Unless you have an explicit counterexample in mind?

For the JIT'ed code, Spectre 1 can probably be mostly avoided using the bitmask trick or something equivalent, which we seem to be moving in the direction of anyway (thinking about the WASM execution environment specifically), and for the "host" code inside the sandbox, the same kind of selective software fixes are required as in the kernel.

Disclaimer; I don't work at Intel, nor in any other processor design house, nor in a fab, etc.

And honestly, look at what is variant 1, before spreading uninformed opinion. It is fundamental to speculative execution. You can have some form of hardware support, and actually both Intel, AMD, ARM, and probably others, have begun some work on the subject, but it is in the form of instructions that can be added or replaced in the software at the right spot, because there is absolutely no way to have a speculative enough HW enforce security for variant 1 without some software help: it is not an architectural or a microarchitectural problem; it is a fundamental logic problem...

My opinion is that we need extensible tagging in programing languages quickly, for that, and other subjects.

All I'm saying is that for a certain set of potential customers, this tips the balance from spending money to not spending money. A handful of people inside Intel and computer OEMs are probably spitting feathers about this circumstance. At the present time, I feel no pressure to accept anything.

Random users in the wild are unlikely to recognize that they've been attacked after the fact.

I'm going to be worried until I hear about a way to detect an actual Spectre-based attack carried out against a random user in the wild...

Perhaps a bit of a dark thought, but fixing existing processors means you might not buy their new 'fixed' processor.

As a result they are not that motivated to fix it as well as they should.

I'm not exactly sure what's more "nebulous" about the timing for consumer chips. This timing is specified for both the consumer and server chips in the same sentence in the press release: "These changes will begin with our next-generation Intel® Xeon® Scalable processors (code-named Cascade Lake) as well as 8th Generation Intel® Core™ processors expected to ship in the second half of 2018." (I guess the nebulous thing is exactly which 8th generation Cores will have the update.)

Most of the long-horizon reports that I read centered around Spectre 1 (intra-process OOB reads by racing bounds check against conditional branch prediction, currently mitigated by lfence), which is still a fundamental-principles issue that would be exceptionally challenging to solve without either substantial performance loss or some form of userland/compilation-level workaround. Intel still haven't indicated a hardware fix for that one. I expect that most mitigations for this will center around improving static analysis tooling and giving the compiler finer-grained control around fencing to reduce performance impact.

Variant 2 (branch target injection, retpoline style software mitigation) is the most interesting. There are certainly obvious theoretical hardware mitigation strategies like tagged BTB entries and this is the most interesting hardware fix. To me it's very cool but not particularly surprising that Intel believe they'll have pure-hardware mitigations for that soon.

And Meltdown was frankly an Intel mistake that would have been shocking if left unfixed in the next hardware revision.