A solution for Spectre

[dondon44]

We have been receiving those half-baked Spectre patches for two months. But in reality, the problem likely isn't solved, not by far.

The current solutions for Spectre are just attempts by Intel and AMD to avoid legal prosecution, by claiming that the processors still work at their intended performance level for "most applications".

The only real solution for Spectre is to completely disable speculative execution, and take the consequential 15% performance hit.

Does anyone have any information whether any CPU vendor is planning on releasing a microcode update which would completely disable speculative execution?

 

[whm1974]

I think the performance hit would be greater then 15%, and I'm not sure if it is even possible to completely disable speculative execution.

 

[dondon44]

We don't know and we can't know whether it is possible to disable speculative execution. Only the CPU designer knows this. The reason that I believe that it is possible is that I saw a post where a CPU designer wrote something like: "Fortunately, we discovered a way to flush the BTB, otherwise we would have no choice but to diasble speculative execution".

About the performance hit estimation, I was thinking about it. Most of the performance comes from pipelining, branch prediction and reordering. Speculative execution really doesn't contribute a lot. So that's why my estimate is 15%, and I don't see why it would be higher. Disabling specEx doesn't imply disabling instruction reordering.

 

[Insert_Nickname]

A work around on x86 if you need absolutely certain Spectre protection, is to dig up an older Atom CPU (pre-Silvermont). Those use an in order architecture, and so should be completely immune.

The performance is atrocious though.

 

[dondon44]

dig up an older Atom CPU (pre-Silvermont).
The performance is atrocious though.

Yeah, or Pentium 200 MMX. Oh, wait, I have an even better choice: Pentium 233 MMX. I wouldn't even settle for a 2 GHz Cortex-A55 (in order arch).

I want 85% of performance of my current CPU and I want the speculative execution OFF. Not this ever-endless patching.

 

[whm1974]

Yeah, or Pentium 200 MMX. Oh, wait, I have an even better choice: Pentium 233 MMX. I wouldn't even settle for a 2 GHz Cortex-A55 (in order arch).

I want 85% of performance of my current CPU and I want the speculative execution OFF. Not this ever-endless patching.

Seriously? The Pentium 233 can't run modern software or do the modern tasks that people expect to be able to do with current hardware.

There are always and will be trade offs.

 

[Insert_Nickname]

Yeah, or Pentium 200 MMX. Oh, wait, I have an even better choice: Pentium 233 MMX. I wouldn't even settle for a 2 GHz Cortex-A55 (in order arch).

Older Atoms are at least somewhat capable of running modern software, through slowly. The Pentium 233 isn't. At all.

There is nothing wrong with having multiple systems for different purposes*. F.x. a highly secure one for financial transactions, and a lower security one for general browsing.

*if you can afford it of course.

 

[dondon44]

Seriously? The Pentium 233 can't run modern software

Pentium 233 MMX can run modern software, it can run any software because it is Turing-complete, it is just not fast enough for the common level of impatience.

But, yes, I was joking. There is no way I'm buying it, or Intel Atom, or Cortex-A55 as a general-purpose computer.

And, I must emphasize that Pentium 233 MMX has MMX extensions which further acclelerate media decoding. https://www.anandtech.com/show/53

 

[piesquared]

Is there a solution for Meldown yet?

 

[Jan Olšan]

A work around on x86 if you need absolutely certain Spectre protection, is to dig up an older Atom CPU (pre-Silvermont). Those use an in order architecture, and so should be completely immune.

Yeah, or Pentium 200 MMX. Oh, wait, I have an even better choice: Pentium 233 MMX. I wouldn't even settle for a 2 GHz Cortex-A55 (in order arch).

1) These are not true. Speculative attacks are easier on out-of-order execution chips, but speculation itself is not the same as out of order execution. Even these in-order CPUs do use speculative execution, anything with branch predictor uses speculation. Currently published exploits don't work on Atom, yes, but that does not mean in-order CPUs are fundamentally safe from speculation-based attacks like Spectre v2.

I want 85% of performance of my current CPU and I want the speculative execution OFF. Not this ever-endless patching.

2) The performance hit would be much, much worse than 15 %. Without hand-tuning code, it would probably be massive hits, with potential to go over order of magnitude drop in pathological cases.

 

[whm1974]

Pentium 233 MMX can run modern software, it can run any software because it is Turing-complete, it is just not fast enough for the common level of impatience.

But, yes, I was joking. There is no way I'm buying it, or Intel Atom, or Cortex-A55 as a general-purpose computer.

And, I must emphasize that Pentium 233 MMX has MMX extensions which further acclelerate media decoding. https://www.anandtech.com/show/53

Oh really? Which current OSes and applications will run on a Pentium 233 MMX? Hell you can't even play DVDs on that.

 

[Markfw]

Is there a solution for Meldown yet?

Its called "Ryzen"

 

[dondon44]

Oh really? Which current OSes and applications will run on a Pentium 233 MMX? Hell you can't even play DVDs on that.

Ridiculous. Modern Linux Mint with Xfce desktop runs fine on Pentium 233 MMX.

 

[whm1974]

Ridiculous. Modern Linux Mint with Xfce desktop runs fine on Pentium 233 MMX.

Name the the distro. And besides most distros are dropping 32-bit support.

 

[whm1974]

Name the the distro. And besides most distros are dropping 32-bit support.

Sorry I didn't see the Mint there. I'll check the specs, but I doubt that is the case.

 

[dondon44]

Sorry I didn't see the Mint there. I'll check the specs, but I doubt that is the case.

I think Linux Mint stopped publishing the minimum specs some time ago. But I'm certain that you need a Mpeg2 decode accelerator card to watch the DVDs, the processor doesn't have the power to decode it in real-time.

 

[whm1974]

I think Linux Mint stopped publishing the minimum specs some time ago. But I'm certain that you need a Mpeg2 decode accelerator card to watch the DVDs, the processor doesn't have the power to decode it in real-time.

As I recall you need a 686 class CPU running at 400Mhz for DVD software playback.

 

[Insert_Nickname]

1) These are not true. Speculative attacks are easier on out-of-order execution chips, but speculation itself is not the same as out of order execution. Even these in-order CPUs do use speculative execution, anything with branch predictor uses speculation. Currently published exploits don't work on Atom, yes, but that does not mean in-order CPUs are fundamentally safe from speculation-based attacks like Spectre v2.

Of course. But in-order Atom is the safest bet right now, until this mess gets sorted. I doubt someone is going out of their way to exploit an older, somewhat rare (now) CPU architecture.

I think Linux Mint stopped publishing the minimum specs some time ago. But I'm certain that you need a Mpeg2 decode accelerator card to watch the DVDs, the processor doesn't have the power to decode it in real-time.

Minimum for realtime DVD decoding is a 300-350MHz Pentium if memory serves. But even my K6-2 450MHz had trouble with it, if things were running in the background.

Edit; ninja'ed by whm1974...

 

[dondon44]

1) Even these in-order CPUs do use speculative execution, anything with branch predictor uses speculation. Currently published exploits don't work on Atom, yes, but that does not mean in-order CPUs are fundamentally safe from speculation-based attacks like Spectre v2.

It is not true that anything with branch predictor uses speculation. Example: Pentium 233 MMX doesn't speculate, but it has branch prediction.

2) The performance hit would be much, much worse than 15 %. Without hand-tuning code, it would probably be massive hits, with potential to go over order of magnitude drop in pathological cases.

I'm not sure you are getting this right. The processor can pipeline everything as usual up to the execution stage. That means it uses branch prediction to fill up the pipeline. it's just the last stage (or two), the execution+retire, that cannot be -executed-. This causes a small stall until the branching condition is resolved, but that is just too small to cause big performance hits.

On what do you base your estimation that the performance hit will be more than 15%. Or are you just saying it like, it would be massive, trust me, I consulted my magical ball.

 

[dondon44]

Minimum for realtime DVD decoding is a 300-350MHz Pentium if memory serves. But even my K6-2 450MHz had trouble with it, if things were running in the background.

This is not true, or it is only partially true. A Pentium 133 with a mpeg2 decode accelerator can play DVDs fine. You statement is only true for realtime software decoding.

Edit: DVDs were contemporary with Pentium 133 processor, and the people were actually watching DVDs on Pentium 133 using the said decode accelerators. It was common.

 

[Jan Olšan]

It is not true that anything with branch predictor uses speculation. Example: Pentium 233 MMX doesn't speculate, but it has branch prediction.


I'm not sure you are getting this right. The processor can pipeline everything as usual up to the execution stage. That means it uses branch prediction to fill up the pipeline. it's just the last stage (or two), the execution+retire, that cannot be -executed-.

On what do you base your estimation that the performance hit will be more than 15%. Or are you just saying it like, it would be massive, trust me, I consulted my magical ball.

I don't think you are right on the first two claims.
1) Using branch prediction in itself means speculation happens. (Edit: if you didn't speculatively fetch/decode/execute based on the prediction, the predictor would have no effect and would be a waste of silicon, literally.)
2) Branch prediction speculation affects almost all stages of CPU pipeline, from fetch, decode onwards. What you propose is not realistic AFAIK.
3) If anything is crystal-ball guessing, it's your 15 % number that you seem are so sure of. What is THAT based on?
Let's just say I consulted my own experience (6 years of journalistic work on hardware, CPU architectures included). From what I recall people with some insight into this tend to expect performance drops in absence of branch prediction to be crippling.

 

[dondon44]

Ok, Mr. Olšan, let's see who has the better arguments. But consider the possibility that it's you and all your fellow tech journalist who are wrong on this one. It's called a groupthink effect.

1) Using branch prediction in itself means speculation happens.

I don't agree. You are wrong here, at the very start. Branch prediction IS NOT speculation. As I said, Pentium and Pentium MMX processors are the counterexample. Do i really need to go around and cite any further evidence which goes against what you said here. Speculation involves the execution stage, while branch prediction does not. That's the difference.

If anything is crystal-ball guessing, it's your 15 % number that you seem are so sure of. What is THAT based on?

The processor proceeds to fill the pipeline as usual. In case of a branch instruction (and those are only, what, 25% of cases), the processor will stall for a cycle or two in order to resolve the branching condition (only in the cases where the branching condition is still executing). Ok, so you lose that one cycle every four instructions. How much of a slowdown is that?

 

[Zodiark1593]

Ok, Mr. Olšan, let's see who has the better arguments. But consider the possibility that it's you and all your fellow tech journalist who are wrong on this one. It's called a groupthink effect.



I don't agree. You are wrong here, at the very start. Branch prediction IS NOT speculation. As I said, Pentium and Pentium MMX processors are the counterexample. Do i really need to go around and cite any further evidence which goes against what you said here. Speculation involves the execution stage, while branch prediction does not. That's the difference.

Actually, yes. You should, in fact, cite your sources to back up your claim that the performance hit among a multitude of different architectures (even among x86, some architectures are narrower than others) is 15%. I'm not sure myself where you pull that 15% figure from, so please feel free to enlighten us.

 

[yoram]

never mind

 

[dondon44]

Actually, yes. You should, in fact, cite your sources to back up your claim that the performance hit among a multitude of different architectures (even among x86, some architectures are narrower than others) is 15%. I'm not sure myself where you pull that 15% figure from, so please feel free to enlighten us.

Ok, Zodiark1593, I'm glad that I'm having this conversation with you, because I rarely have the opportunity to converse with people who can write, but cannot read. It is really amazing for me.

I don't have a source for the 15% number. I have an argument. It's because I'm the first person making the argument. But someone has to be the first, right? I wrote about the argument, and if you are having trouble finding my argument because you cannot read, here it is again:

The processor proceeds to fill the pipeline as usual. In case of a branch instruction (and those are only, what, 25% of cases), the processor will stall for a cycle or two in order to resolve the branching condition (only in the cases where the branching condition is still executing). Ok, so you lose that one cycle every four instructions. How much of a slowdown is that?

But, I have sources to confirm that branch prediction IS NOT speculative execution. Do I have to post them here, or can you perhaps find them by yourself. You should try Wikipedia.

Drop the condescending and sarcastic attitude
and you will have a much better stay here.

AT Mod Usandthem