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/ _______________________________________________ luv-main mailing list [email protected] https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
