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. Now there are some things that could be done to improve security of single- user workstations. For starters encourage users to use a different session for tasks that need root access, even CTRL-ALT-F1 to get a text console will do. Things like ssh keys could be accessed by a setgid program, so have ~/.ssh a symlink to /var/lib/ssh/$USER and have /var/lib/ssh only accessible by the ssh group. Then mail clients could use a local proxy that stores the IMAP/SMTP password and only sends it to the server so the password can't be stolen by a local user compromise. Such techniques could make regular user compromise on a single-user workstation inadequate to get all access. But at the moment for attacking a single-user workstation there's no real need for root. _______________________________________________ luv-main mailing list [email protected] https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
