Patching side-channel flaws is killing performance – Naked Security

Mirror, mirror on the wall, which is the worst side-channel vulnerability of them all?

For a while it was Meltdown and Spectre, the two biggies that kicked off the era of microprocessor security worry in early 2018, followed some months later by another contender, PortSmash.

In May this year, news emerged of more weaknesses with fancy names – ZombieLoad (CVE-2018-12130), RIDL, and Fallout (CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091).

The thread loosely holding this list together is a new class of weaknesses known as Microarchitectural Data Sampling (MDS) flaws, in the case of PostSmash and ZombieLoad in Intel’s Simultaneous Multithreading (SMT) hyper-threading.

When it was introduced nearly 20 years ago by Intel, SMT multithreading was promoted as a clever way of boosting processor performance.

In the absence of patches, the simplest way to mitigate the numerous security issues stemming from hyper-threading was to turn it off via the BIOS, something researchers initially estimated would cause a performance drop of up to 30% for datacentre installations, depending on which flaw was being addressed.

Lock it up

During 2018, the maintainers of security-first operating system OpenBSD started recommending turning SMT off if it was being used in certain types of installation – just patching it on a piecemeal basis wasn’t enough.

An easy-to-miss mainstream follow up to that was Google’s 2019 decision to disable MDS on Chrome v74 in its Chromebooks, a move it followed up with additional mitigations in later versions.

By now, the SMT fire was burning on several fronts, especially comments made by the maintainer of the stable branch of Linux, Greg Kroah-Hartman. In May, he summed up a year of doubt about SMT:

As I said before just over a year ago, Intel once again owes a bunch of people a lot of drinks for fixing their hardware bugs, in our software…

Only days ago, Kroah-Hartman came back with another salvo in comments to The Register:

A year ago, they [OpenBSD] said disable hyper-threading, there’s going to be lots of problems here. They chose security over performance at an earlier stage than anyone else. Disable hyper-threading. That’s the only way you can solve some of these issues. We are slowing down your workloads. Sorry.

And there is no way of jumping the performance shark either:

I see a slowdown of about 20 per cent. That’s real. As kernel developers we fight for a 1 per cent, 2 per cent speed increase. Put these security things in, and we go back like a year in performance. It’s sad.