-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi,
On Wed, 2018-08-15 at 18:06 +0200, Peter Müller wrote:
Hello *,
during the past months, more and more vulnerabilities in modern CPUs were detected. At the moment, there is
- Spectre v1 and v2
- Meltdown (sometimes referred to as Spectre v3)
- Spectre v4
- a bunch of vulnerabilities similar to v4 (summarised as Spectre-NG)
- Spectre v5
- and a lot more, at least five of them undisclosed.
Needless to say, this complex is a total nightmare for anybody caring about security - not only because of the technical issues, but mainly due to very sloppy responses from the hardware vendors (I cannot resist naming Intel here directly).
Yes, I thought I was overstating a little bit in the last blog post that there are many more to come, but I guess was quote right with that.
I personally cannot grasp this any more that such *severe* vulnerabilities are in such an essential part of our infrastructure. This is not just an oversight, this is negligence and prioritizing the wrong things like performance which translates into profit.
At the same time I have to say that there is just no alternative to Intel CPUs in most sectors of the market.
Further, the current CVE and patch situation (especially when it comes to the Linux kernel) is completely confusing, making it nearly impossible to check which has been backported whereto, addressing which security bulletin. In my humble opinion, the significance of security has decreased a lot and is still dropping. Being discontent with the overall security situation in the Linux kernel, the handling of recent CPU vulnerabilities did not help.
I do not think that this is a Linux kernel issue. I think it is inherited from Intel who do not seem to be helping the kernel community (and that seems to include their own developers, too) to develop any functioning mitigation because it slows things down. That was the main concern for the media when PTI was being developed - not that there is a huge hole in the CPU. Just that it is slower than before.
It is also very obvious where people's priorities are. I.e. nobody cares about 32 bits any more because there is no money in it. But that doesn't mean that those systems are not out there...
That being said, I would like to discuss some changes to improve security in IPFire, most of them at kernel or sysctl level.
(a) Disable hyperthreading by default? OpenBSD did so a while ago, arguing this makes some side-channel attacks more complicated or even impossible. HT was the source of some serious vulnerabilities in the past (starting around 2006), which is one reason why I never liked it too much. Would you consider disabling it acceptable (it will probably cause some performance impact)?
I do not think that this is a good solution to the problem.
You can do that with the "noht" parameter at boot time and you can disable it in your BIOS. I would vote against making this the default.
There reason for that is the solution to just disable it isn't really one. It is just a hack that works if performance isn't an issue. In the big picture, performance is an issue.
(b) Update kernel more frequently It seems to be necessary to ship new kernels more frequently, as some security fixes are backported to 4.14.x very quickly. Unfortunately, this causes updates to become very big, as C121/122 turned out, and I am not familiar with the procedure behind this. How often do we want to ship a new kernel? Every second update? Every forth? I have no idea... :-)
Well, I have to have a little bit of a rant here:
I would like to push out core updates more often and also faster, but there is literally no feedback from any testers.
EFI images? No response to my email
Latest kernel update? Nothing
How can we push out more code that is not being tested? That's just irresponsible and will break down very quickly.
So, we have to have testing doing better first before we can think about it. A strict release schedule didn't work for us because people are often unavailable for quite a while.
We are doing best-effort on some of the bigger changes here and you can believe me that we have been trying hard in the past.
(c) Introduce kernel and sysctl hardening Fortunately, there are some configure flags and /etc/sysctl.conf settings improving the overall situation: https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommende... Their implementation in IPFire is on my TODO list (forgive me for being slow during the last time) and filed here: https://bugzilla.ipfire.org/show_bug.cgi?id=11659
How small should the chunks be here? A patch for every changed setting or can portions be bigger (same applies on OpenSSH hardening as well)? Just asking to avoid unnecessary noise afterwards.
One at a time.
https://wiki.ipfire.org/devel/submit-patches#separate_your_changes
Comments? Anything I forgot here?
Thanks, and best regards, Peter Müller