Re: Kernel for Spectre and Meltdown

On 30 January 2018 at 13:22, Greg Wooledge <wooledg@eeg.ccf.org> 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 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

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.)