More on Intel's Hardware Bugs

by Michael Tremer, November 6, 2018, Updated November 7, 2018

Do you like what you are reading? Subscribe to our newsletter and don't miss out on the latest...   Join Now

It has actually been eleven months ago, when I wrote about the chaotic story called Meltdown and Spectre. It was very clear that those were not to be the only CPU vulnerabilities of that kind and here we are now, almost a year later, and that speculation has become reality.

Why am I writing about this now?

To be honest, there are good sources about all these vulnerabilities elsewhere. People who actually invested a lot of time into all of this - more than I can do. Therefore I would not at all call myself an expert on any of those. I guess this not only a result of my limited time, but also Intel and other vendors trying to make sure that as little information is out there as possible. That results in news stories that are based on only very few facts and a lot of speculation.

It is frustrating. But now, I think we have seen a turn in this matter. Unfortunately, not for the better.

PortSmash

Yesterday, the IPFire people had a conversation about the latest addition to the show: PortSmash. Hardware vulnerabilities are something that is coming up all the time, but also a conversation that rotates around itself. We all agree on one thing: We need to do something against it. But what? Not knowing the full detail of the issue does not help. This is also a little outside of the scope of the IPFire project and should be handled in the Linux kernel. But there, the situation is basically the same. Confusion, little action because of various reasons and if there are patches available, they are coming late and are often not well tested or have a significant performance impact.

That means all available solutions always have a huge trade-off. This time, the offered solution is of another quality: Turn off Hyper-Threading.

Turning off Hyper-Threading

In all fairness, not only Intel is affected here, but the PortSmash story is about Intel again. They have not revealed a lot about this vulnerability and do not intend to do so. Therefore, the researchers who found out about it, recommend to disable Hyper-Threading. It definitely mitigates the problem. But at what price?

Hyper-Threading - or SMT in general - works. In many use-cases - and that includes firewalls - they double performance. You are literally getting another CPU core. Disabling it will roughly half the performance of any hardware. That might be acceptable in a single case, but I am quite sure that this is not an option for a large cloud provider to just build another data center and by every bit of hardware they own again.

The question we debated was: Should we disable SMT in IPFire? OpenBSD has quite controversially decided to do so, but we decided that we should not do it. We cannot make that decision for the users. In some situations it might be the right thing to do, in some others it might not be. Although considering security first, it is not the only thing there is to consider.

We also think, that this is not the only thing to do. You, the users, need to take care of your hardware. Install BIOS updates. Make sure that firmware for every component is up to date, patched and that anything you don't need or want (I am looking at you, Intel Management Engine) is disabled. This is something that we as an OS vendor, cannot do for you.

Where are we going?

I do not know. Again, this time it is not only an Intel issue. It is a problem that is very deep within the design of modern processors. Nothing that can be fixed without replacing the CPU. Obviously that is not possible with all the smartphones, laptops and other devices out there that have it soldered on. But even for a socketed CPU, there is no alternative CPUs to buy that have these problems fixed. And even if they did, the list of vulnerabilities is getting longer and longer (I cannot even remember the names of all of them any more) and you would need to replace your CPU again and again and again... An endless game. Some serious action is required. But I guess the recommendation to disable HT is a sign for resignation rather than anything else. So it is not only me who doesn't know. Security researches who are deep in this topic do not know either.

But it is not all doom and gloom

Since I tend to end these blog posts on such a dark note, I want to highlight that IPFire is very well patched against anything that is possible to protect against. We ship a recent kernel that receives all fixes that are built into the Linux kernel, we harden the user-space where possible. IPFire is better protected than others, but developing and distributing patches takes time and effort. In the meantime it is up to you to decide if you can afford to disable HT.