Re: [Discussion] Consequences of CPU vulnerabilities

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 6024 bytes --]

-----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/Recommended_Settings
> 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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE5/rW5l3GGe2ypktxgHnw/2+QCQcFAlt1bBMACgkQgHnw/2+Q
CQc1zg/9EHHE0QxNVeCn6zidyuHBnCaW0r6X6HMS6jEURmiErgR0WQZ9BqiTP7v6
m/tYIOm+Pn8DrbTrP6EKZOfy98qvhXaWa9tcvfighrGNTX3hcwxnQOQpeLN7upDa
deRa33aorQxfA/8cxGkfTmT++g00dDNCk2CZDozBCFeM8s/g16VZX/CNpdEbvo9H
6MH4YGknrOPXmEM8IurNxNYyi8fmNxwfQGtm/HSNGJvyyDBZ1SbXQ4A7k2C5vKfd
H6gN/YDZhTyDdLCGiTplEFvNqKAhleEzGcwTTFcUklD1cPjcuZfNJECpLhqrVWe0
xJtv1VwaxTkFGXBU7EFf4HxZgP4LtQJ/41+j/FdZbYQvgUsIXmKHStet+IlNgGJc
ux3MAtRJPy897bgqUfxNJ6L3/9yg1yDhYqKbbZuf7yGOBDYEP4whm9wdIr0J5os5
LdQnveP2vlEZKzCHJikyV4Qi/EWVB9luvhEb/Ii7oOAc+5RMwWTocdjz9MYgqBky
An8M6b/y6nwbDy/cgZQk1R6RZY81tS2aPGgY/33vggs32aFHMyocU5CZFMZFaHYA
31dI79fDuT0W8AAQMG+Ndb9a1dsW6y5JmyhHHfvQaJnZ082uHNe1VImTBwz6Kufh
P/n/pLWgcaHaaRDVO5vQo4yx3+Zhs9G76iqeCDRqEhT+aF0pdH0=
=OsnR
-----END PGP SIGNATURE-----