Linux 5.15 Adds Another Knob To Harden Against Side Channel Attacks

[smitty3268]

I find it useful to always remember this when talking with people on the internet.

[birdie]

Apparently, several latest post in this thread have just dissapeared. How is that possible? Database was reset?

Michael has had intermittent issues with the website for the past two weeks. No idea what's happening but I often get errors from cloudflare.

[tildearrow]

Previously, I have answered only half of this queston (I didn't notice the ommision).

Essentially, the CPU has to wait/stall more. For example: if the CPU rushes over a security check, then there could be a way for protected data to leak. The same goes for all ordinary braches, as those could be a part of a privilege isolation system.

Allso, cache latency is increased. The raw latencly likely goes up by 0.8 - 1.8 clock cycles (on average, there are various cases), but, hopefully, most of this gets ironed down by SE. The net result of increased cache latency is more CPU pipeline waits/stalls, so the number of waits/stall is the key metric for almot entire performance degradation.

Wow.

Curious, do you work for a CPU design company or something?

[tildearrow]

I think I have an even better explanation for this question.

Speculative execution means that some computations are going to be performed before a branch direction is decided. Another way to say this is: speculative execution assigns results of ahead-of-time computataion to various execution paths.

So, when a branch is decided, SE engine must do both of the following things:
1. Discard all the results from rejected execution paths
2. Accept the results from accepted execution paths

The problem lies in 1) Discard. How can the CPU discard an execution path if it has already modified the cache, memory, perhaps even sent some I/O? I/O cant be undone. Undoing memory and cache modifications is hard. So, the solution is simply to NOT modify.

The second problem is with security checks. If a CPU doesn't wait on a security check, can the consequent writes to internal buffers be undone? Because, if a CPU has allowed an operation to proceed without waiting for secutity validation, then to undo that operation it also has to track all the consequent data movements. In a large CPU like a modern high-performace design, the changes caused by a single instruction are going to spill everywhere in the core. So, hard to track, hard to undo. And the solution is simple: the CPU has to wait more, so that changes do not propagate far, so that they are easy to undo.

Yep, precisely this. But here is a question.

While doing speculative execution, why not do "paranoid" speculative execution? (the processor executes the result of a branch twice (one for branch, another for don't branch))
And on top of that, why don't we have an "output buffer" for every speculative processor? This way undo'ing stops being a thing as Discard never occurs:

1. The processor delegates a piece of code twice to the branch processor
2. The branch processor generates results and fills "output buffers" and processor state for both results
3. The branch is reached, and one of the results is picked
4. The output buffer is flushed and all correct output and I/O operations are issued

[tildearrow]

Apparently, several latest post in this thread have just dissapeared. How is that possible? Database was reset?

Wait a moment, indeed, many posts across the forum have disappeared. Not sure if somebody requested those posts' removal, or if Michael did a second wipe...

[Weasel]

While doing speculative execution, why not do "paranoid" speculative execution? (the processor executes the result of a branch twice (one for branch, another for don't branch))

The simple answer is that it's a waste of resources and caches. It's the same as having a 50% prediction rate, because you waste twice as many resources to get 100% prediction rate, and thus can't have as long pipelines or cache utilization etc.

Don't just take my word for it: https://stackoverflow.com/questions/...-both-branches

[tildearrow]

The simple answer is that CPU can't execute a piece of code twice because CPU can't easily undo changes to caches and memory.

By the way, the "paranoid" speculative execution that you have described in your post is not paranoid at all, it is still vulnerable to SPECTRE.



This Weasel's answer is completely off-track. Speculative execution simply can't be performed on sufficiently long instruction sequences since CPU is going to run into a lots of load/store instructions which it can't quickly an efficiently undo. So, the real "paranoid" way to do SE is to stop speculative execution of an execution path whenever a load or store is reached, but that causes a pipeline to stall too often and kills the performance.

This all has nothing to do with "prediction rate", or "wasting resources on both branches".

Excuse me xfcemint... I am reading your replies several times and trying to understand because I am not an expert in modern CPU design, so a response may take a while to be formulated.

[Weasel]

Of course, and again, Weasel didn't bother to read my long answer above, because if he had red it, he wouldn't have posted this utterly misleading answer of his.

In fact, Weasel didn't even read the Stack Overflow answer, nor the actual question. But he linked to it (that's most important for him, an argument from authority).

As for the answer on Stack Overflow that he links to, I just actually bothered to read it.

The Stack Overflow question is not the same as the question posted here, tildearrow was asking here about avoiding SPECTRE, and the answer on Stack Overflow has nothing to do with SPECTRE.

So, completely misses the point.

Maybe you should re-read the quote since it had nothing to do with SPECTRE, and the answer I linked explains exactly that.

Meanwhile you've yet to prove even 1 of your bullshit. Like, you make a lot of claims, where's your PROOF?

Undo is obviously not a problem for anyone with a brain. As long as it is speculatively executing it clearly cannot commit yet, so discarding all of it is as easy as throwing all the temporary data. Because unlike you, most people don't consider "but it's in the cache now!" as "wrong" execution—caches are supposed to be fully transparent to the instructions and software. Because the result, whether it's in the cache or not, is still correct, and that's what matters. Not measuring timing or some other bullshit.

Here's a quote explaining the 50% probability outlined:

Fetching instructions from both paths into one or more of the caches reduces the effective capacity of the caches in general, because, typically, one of the paths will be executed much more frequently than the other (in some, potentially highly irregular, pattern).

Time to put up some proof on your end buddy.

[Weasel]

Tildearrrow asked a question about SPECTRE. The answer you linked to has nothing to do with SPECTRE. And, you have just confirmed that here.

Most types of SPECTRE are based on modifications made by the CPU to the caches during speculative execution. It doesn't matter whether CPU "commits" the data or not, as long as the CPU modifies cache metadata during speculative execution.

I agree with you that implementing "undo" is not a big problem, in your words: "Undo is obviously not a problem for anyone with a brain". But, CPU manufacturers have refused to implement a sufficiently thorough undo operation for getting rid of SPECTRE v1.

That's exactly the most important part of my proposed solution to SPECTRE: thorough undo.

You don't get it. It can do "paranoid" speculation of both paths, but how is that different than normal speculative execution, doing both paths at once?

The answer is the same: it's a waste of resources, because it's the same thing as having a 50% prediction rate (you predict correctly all the time, but waste twice as many resources doing so). This is simple statistics.

Why would "paranoid" speculative execution be any different? "paranoid" speculative buffers/caches aren't cheaper/more free than "normal" caches used in "normal" speculative execution. You're going to literally halve their effectiveness (also pipelines and execution units) by executing both paths at once. It doesn't matter if it's "paranoid" buffers or normal caches.

LOL. Proofs in the crafts of CPU design and computer programming are very rare. Instead of proofs, there is TESTING, lot of testing, and there are "best practices" like: functional programming, RISC design, object oriented programming, KISS, etc...

You also haven't posted any proofs. Why is that?

Well I did, the link supplied earlier.

I was referring to your post here: https://www.phoronix.com/forums/foru...60#post1278860

Which requires proof because it's wrong. It has nothing to do with SPECTRE, as I said.

[tildearrow]

Let's fill this void a bit.

So, tildearrow, do you like my design so far?

In my mind, it's all relatively simple and straightforward.

Don't be afraid, I bite only when people are mean to me.

Seems like a good idea.