On Thursday, 4 January 2018 11:44:17 AM AEDT Stewart Smith via luv-main wrote:
On Wed, Jan 3, 2018, at 6:29 PM, Russell Coker via luv-main wrote:
On Wednesday, 3 January 2018 4:32:25 PM AEDT Andrew Pam wrote:
On 03/01/18 16:11, Arjen Lentz via luv-main wrote:
This raises the interesting question: will distros start to provide > separate kernel packages for Intel and AMD CPUs. I'd guess they will, as the performance hit of the KPTI workaround is significant.
They won't need to, as the mitigation is loaded at runtime and AMD's provided kernel patch prevents the slow KPTI workaround from being loaded when AMD CPUs are detected.
Naturally the kernel can recognise which CPU it's running on and do appropriate things. Changes or similar scope are made at run-time for other purposes (EG SIMD instructions and the recent kernel changes that broke compatability with older libc).
But there is a reasonable use case for systems that don't need such kernel security. A significant portion of Linux systems are single user workstations. For such a system you have one UID that deals with all the data from the Internet (and is therefore at risk of compromise) which also has access to all secrets (Internet banking passwords, GPG keys, ssh keys, etc). On such a single-user workstation the UID in question is generally used to access root via sudo or similar, and therfore an attacker who gets that UID can get root with a little patience and not much skill. For such a single user workstation (like the systems most of us use to post to this list) the new kernel won't provide any real benefit.
I *strongly* disagree. Modern machines sandbox a *lot*, and we trust a web browser to protect our documents from malicious javascript, and these processes are much more constrained than general random processes running as that uid.
Since I wrote that previous message more information has come out which makes it seem that these problems are more serious than I initially believed. So I agree with you now. As a general rule applying security fixes ASAP is going to be a reasonable option.
You could also use these vulnerabilities to get further than you otherwise could. e.g. a web server running in a very constrained SELinux environment could break out of that and get access to things it's not meant to be able to.
I recommend applying all security fixes to servers. They are open for attack 24*7. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/