On 30/01/2018 18:52, Greg Wooledge wrote:
On Tue, Jan 30, 2018 at 12:13:47PM +0100, Michael Lange wrote:Michael Fothergill <michael.fothergill@gmail.com> wrote:The response from Greg was the following: On Thu, Jan 25, 2018 at 12:36:46PM +0000, Michael Fothergill wrote:If I become sid and install the kernel correctly, could I go back tobeingjust buster (sounds like an energy drink) and carry on using the newkernel? No. ******************* At that point I really did seem that: 1. I had no choice but to become sid/unstable here.I can only guess of course, I think probably they figured you would upgrade your system to Sid, then compile a kernel and then *downgrade* the system again to buster. The answer to that would clearly be "no". But running a kernel compiled on a *different* Sid system on buster or stretch is an entirely different thing of course.Yes, that's correct. If you actually "become sid" (upgrade your whole system to sid), there is no going back. But you can set up a *separate* system (either an entirely new box, or a chroot into which you debootstrap sid, or a virtual machine, or a container, or whatever other fancy thing the kids are using these days), build a kernel .deb package there, *copy* that package to your buster system, and install it. Or you can do what most of us are doing: wait for the Debian security team (and, really, for the entire *world*) to figure out how best to approach, mitigate, and/or solve the issues. Meanwhile, I would recommend not letting random people get shell access to your critical systems. Near as I can tell, exploiting a Spectre-type CPU vulnerability requires the ability to install and execute a program of the attacker's creation on the target system. If you don't have users logging in and running commands, then you probably don't have to worry so much about this. Unless I'm completely missing something. (If you have users issuing commands on your system through some other vector, like a PHP web-app exploit, then that's a bigger issue you should address directly.)
It should be possible to exploit Spectre via javascript, the prominent web browsers (G.Chrome/Chromium and Firefox) have already applied mitigation for this scenario. For G.Chrome/Chromium you can also use an experimental flag do harden site isolation (at the cost of memory consumption). But you can be sure the clever kids in their basements, the mafia networks and the state sponsored rogue agencies are hard at work trying to find novelty use for these new pathways to our systems. So patch, update, and be careful what emailed link you click on (hint: none). In Debian we are lucky as far as I can judge, Stable received a backport of the Kaiser/kpti patches, and Sid has retpolined kernel and patched gcc (but still vulnerable to Spectre 1 just as everybody else on the planet). On Stable and Backport kernel you are covered for Meltdown (for Intel cpu) but still vulnerable to Spectre. That will be the case as long as the gcc patches are not backported, or the Debian deities decide to break the taboo and issue a kernel and gcc bump for Stable, unlikely.
In Testing you are following Sid, remember there is no official security support for Testing outside of the very end of the pre-stable release freeze period. So you can cherry-pick what you want from Sid, or wait for the migration to naturally happen (if it has not happened yet, I don't know). The cpu microcode side of things is a lot murkier, Intel is going back and forth with crappy code that crashes some systems, and the decision to apply or not those microcode updates is a tricky one. As for board vendors they don't seem to scramble to send updates out...
In any case right now there is no cause for alarm for the general public (IMHO), that may change if a working javascript exploit surfaces but it isn't here yet. If you are hosting virtual systems for distrusted clients (aren't they all) then you need to weight your options seriously, keeping in mind that when an efficient exploit surfaces it will be too late to patch.
All of the above is just my attempt at offering a synthesis of my experience, I am not working for US-CERT and I am not a DD, so you can ignore all of the above and go find out for yourself (the best way®).