On 30 January 2018 at 13:22, Greg Wooledge <wool...@eeg.ccf.org> wrote:
> On Tue, Jan 30, 2018 at 12:13:47PM +0100, Michael Lange wrote: > > Michael Fothergill <michael.fotherg...@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 to > > > being > > > > just buster (sounds like an energy drink) and carry on using the new > > > kernel? > > > > > > 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. > What about if you became sid, made the spectre kernel and backed it up on a usb drive and then you backed up the work files and wiped the entire installation and then reinstalled stretch. Could you then install the kernel on the usb drive or is that not possible and, like full gender reassignment surgery there really is no going back as it were.......? Cheers MF > > 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.) > >
