Linux 5.15 Adds Another Knob To Harden Against Side Channel Attacks

[phoronix]

Phoronix: Linux 5.15 Adds Another Knob To Harden Against Side Channel Attacks

With the Linux 5.15 kernel is a new build-time option to further harden the kernel around side channel attacks and information leakage. Enabling this option can have some (small) performance cost and a slightly larger kernel...

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.15-Hardening

[uid313]

Imagine if there were a computer that had no side channels so that side-channel attacks were impossible and wouldn't have to be mitigated in software.

[Developer12]

rop = return oriented programming
cop = call oriented programming?
job = jump oriented something?

[Developer12]

Imagine if there were a computer that had no side channels so that side-channel attacks were impossible and wouldn't have to be mitigated in software.

A nice concept, but it would take monumental effort to formally verify that none existed, and it would be a massive drag on the entire design effort. It might not even be compatible at all with a lot of modern performance enhancements, spectre aside.

Intel recently patched out a don't-load-zeros optimization in their skylake (and above) microcode. It made memory loading a lot more power efficient, but it also allowed you to guess the contents of memory based on timing. Speculative execution wasn't even involved in that side channel.

And then there's the really crazy stuff. There are designs out there that load both a register, and it's compliment into a shadow register, just so that the total number of 1's and 0's loaded is always the same. Why? You can guess what the contents being loaded are based on power consumption.

[tildearrow]

Imagine if there were a computer that had no side channels so that side-channel attacks were impossible and wouldn't have to be mitigated in software.

There was already... The 68000, the first Intel Atom processors and earlier ARM processors were immune to these attacks because they ran in-order...

[tildearrow]

This person wants you to believe that a computer system can't be very secure without complete formal verification, which is false. At least, the major problem in today's designs isn't a lack of formal verification, but intentional chase of even higher profit margins by hardware-design companies.

One thing is being very secure. Another is having a seal that ensures it is very secure.
Just like jobs. You may be skilled enough to take a specific job, but sadly most require you to have verification of formal study on specific topics (usually learned from academies, college or university) to ensure you are fit for the task.

This person wants you to believe that a very secure design cannot be high-performance, citing some outdated examples from the past. IMO, there is no inherent reason why a high-performance design couldn't be very secure, except for a rather small (less than 15%) performance penalty compared to a common high-performance design.

Yes, in fact these are old examples. Back when out-of-order execution, branch prediction and the rest of that magic dust was unknown to human (68000) or too difficult to apply on a low cost design (Atom).
I wonder, how would you implement a high performance secure design? AMD made a Meltdown-proof design, but.... Spectre

I've heard some security researchers made a processor design that is immune to Spectre as well but nobody has ever considered that paper from the moment it was released...

This person might be some kind of a high-performance enthusiast, and their mindset is stuck in a never-ending chase of ultimate speed, always worshipping the current king of the hill.

The result of poor application design with layer on top of layer on top of layer, just like a burger that has too many layers.
By the way, not a high-performance enthusiast. Even though I do appreciate speed improvements, I am not the wow guy.

[smitty3268]

I wonder, how would you implement a high performance secure design? AMD made a Meltdown-proof design, but.... Spectre

AMD just announced Zen+ and Zen2 had a meltdown similar flaw.

[Weasel]

Or, in simpler words: after speculation, the CPU must clean up the microarchitectural state thoroughly, and the design should not include elements which are not easy to clean-up (therefore, the L1 must be speculation-aware, and the "speculative cache buffer" must be present to speed up cache writes).

To simplify the design of such CPU, the CPU has to wait more often for security clearance, and wait more often for conditional branches to resolve.

If it has to wait, it shits on performance. Period. You can't have it both ways.

Deal with it.

[tomas]

After a branch in the code.....

Now this is the reason I still bother to read the comments section on Phoronix. You wade through debris most of the time and then suddenly... you find a gem. Thank you for both interesting and well written posts. 😊

[Developer12]

This person wants you to believe that a computer system can't be very secure without complete formal verification, which is false. At least, the major problem in today's designs isn't a lack of formal verification, but intentional chase of even higher profit margins by hardware-design companies.

This person should learn to read before they speak.

The question was "Imagine if there were a computer that had no side channels so that side-channel attacks were impossible and wouldn't have to be mitigated in software."

If you want absolutely no possibility of a side channel attack then you need formal verification. End of story.