.png)
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.
But if this created all these security problems, the simplest way to mitigate those was to turn off hyper-threading via the BIOS, something estimated by researchers to cause a performance drop of up to 30% for datacentre installations, depending on which flaw was being addressed.
Lock it up
For a while, this was just a debate, but it quickly started seeping into the real world. The deepest well of unhappiness has been in the Linux world, an influential sector for whom even theoretical security problems are a big deal.
During 2018, the maintainers of Linux distros such as 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 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.
Reducing performance by that big a hit could cause major issues for datacentres to the extent they might have to consider leaving it turned on and take the risk.
Encouraging the conservative response is the fact that reported attacks exploiting issues such as ZombieLoad are non-existent.
That might be because attackers have yet to figure out how to do that or because detecting side-channel attacks is inherently impossible once a compromise fundamental enough to reach microprocessor level has been attained.
But when someone like Kroah-Hartman starts talking about performance as a necessary sacrifice – possibly for many years to come – perhaps server users have reason to worry.
What’s become apparent is that patching side-channel issues is the microprocessor problem with no simple answer.
Customers will carry on patching the issues that pop up, caught in a sort of dented version of Moore’s Law where microprocessor performance continues to rise exponentially for some customers, but not others.
from Naked Security https://ift.tt/34gMb5H
0 comments:
Post a Comment