Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #191703 > unrolled thread

Kernel for Spectre and Meltdown

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Kernel for Spectre and Meltdown Dextin Jerafmel <jerafmel@yahoo.com> - 2018-01-29 09:10 +0100
    Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-29 10:00 +0100
      Re: Kernel for Spectre and Meltdown arne <sp113438@telfort.nl> - 2018-01-29 10:50 +0100
        Re: Kernel for Spectre and Meltdown Michael Lange <klappnase@freenet.de> - 2018-01-29 11:50 +0100
          Re: Kernel for Spectre and Meltdown arne <sp113438@telfort.nl> - 2018-01-29 13:30 +0100
      Re: Kernel for Spectre and Meltdown Jonathan Dowland <jmtd@debian.org> - 2018-01-29 10:50 +0100
      Re: Kernel for Spectre and Meltdown deloptes <deloptes@gmail.com> - 2018-01-29 11:20 +0100
        Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-29 12:40 +0100
          Re: Kernel for Spectre and Meltdown rhkramer@gmail.com - 2018-01-29 14:30 +0100
            Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-29 14:50 +0100
          Re: Kernel for Spectre and Meltdown deloptes <deloptes@gmail.com> - 2018-01-29 14:30 +0100
            Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-29 15:00 +0100
              Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-29 15:30 +0100
                Re: Kernel for Spectre and Meltdown rhkramer@gmail.com - 2018-01-29 16:50 +0100
                  Re: Kernel for Spectre and Meltdown Greg Wooledge <wooledg@eeg.ccf.org> - 2018-01-29 17:20 +0100
                    Re: Kernel for Spectre and Meltdown deloptes <deloptes@gmail.com> - 2018-01-29 18:40 +0100
                  Re: Kernel for Spectre and Meltdown Michael Lange <klappnase@freenet.de> - 2018-01-29 19:10 +0100
                    Re: Kernel for Spectre and Meltdown "Thomas Schmitt" <scdbackup@gmx.net> - 2018-01-29 19:40 +0100
                      Re: Kernel for Spectre and Meltdown Michael Lange <klappnase@freenet.de> - 2018-01-29 20:00 +0100
                    Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-30 20:40 +0100
                      Re: Kernel for Spectre and Meltdown Michael Lange <klappnase@freenet.de> - 2018-01-30 22:50 +0100
                        Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-30 23:10 +0100
                  Re: Kernel for Spectre and Meltdown Elimar Riesebieter <riesebie@lxtec.de> - 2018-01-30 16:30 +0100
                    Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-30 17:20 +0100
                      Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-30 18:00 +0100
                        Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-31 14:50 +0100
            Re: Kernel for Spectre and Meltdown Carl Fink <carl@finknetwork.com> - 2018-01-29 15:50 +0100
              Re: Kernel for Spectre and Meltdown deloptes <deloptes@gmail.com> - 2018-01-29 18:40 +0100
      Re: Kernel for Spectre and Meltdown Michael Lange <klappnase@freenet.de> - 2018-01-29 11:30 +0100
        Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-29 13:40 +0100
          Re: Kernel for Spectre and Meltdown Michael Stone <mstone@debian.org> - 2018-01-29 14:00 +0100
        Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-29 14:10 +0100
          Re: Kernel for Spectre and Meltdown Michael Lange <klappnase@freenet.de> - 2018-01-29 19:20 +0100
            Re: Kernel for Spectre and Meltdown deloptes <deloptes@gmail.com> - 2018-01-29 19:40 +0100
              Re: Kernel for Spectre and Meltdown Michael Lange <klappnase@freenet.de> - 2018-01-29 20:00 +0100
          Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-30 10:50 +0100
            Re: Kernel for Spectre and Meltdown Michael Lange <klappnase@freenet.de> - 2018-01-30 12:20 +0100
              Re: Kernel for Spectre and Meltdown Greg Wooledge <wooledg@eeg.ccf.org> - 2018-01-30 14:30 +0100
                Re: Kernel for Spectre and Meltdown Gene Heskett <gheskett@shentel.net> - 2018-01-30 14:50 +0100
                Re: Kernel for Spectre and Meltdown "tv.debian@googlemail.com" <tv.debian@googlemail.com> - 2018-01-30 16:40 +0100
                Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-31 19:20 +0100
                  Re: Kernel for Spectre and Meltdown Greg Wooledge <wooledg@eeg.ccf.org> - 2018-01-31 19:30 +0100
                  Re: Kernel for Spectre and Meltdown Michael Lange <klappnase@freenet.de> - 2018-01-31 19:40 +0100
                    Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-01-31 23:40 +0100
                      Re: Kernel for Spectre and Meltdown Richard Hector <richard@walnut.gen.nz> - 2018-01-31 23:50 +0100
                        Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-02-01 00:10 +0100
                          Re: Kernel for Spectre and Meltdown Richard Hector <richard@walnut.gen.nz> - 2018-02-01 00:20 +0100
                            Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-02-01 00:50 +0100
                Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-02-01 13:10 +0100
                  Re: Kernel for Spectre and Meltdown Andy Smith <andy@strugglers.net> - 2018-02-02 05:40 +0100
                    Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-02-03 09:10 +0100
                      Re: Kernel for Spectre and Meltdown rhkramer@gmail.com - 2018-02-03 15:50 +0100
                        Re: Kernel for Spectre and Meltdown Cindy-Sue Causey <butterflybytes@gmail.com> - 2018-02-03 16:40 +0100
                          Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-02-03 18:10 +0100
                          Re: Kernel for Spectre and Meltdown David Wright <deblis@lionunicorn.co.uk> - 2018-02-03 18:30 +0100
                            Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-02-03 23:50 +0100
                      Re: Kernel for Spectre and Meltdown David Wright <deblis@lionunicorn.co.uk> - 2018-02-03 18:20 +0100
                        Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-02-03 23:10 +0100
                        Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-02-03 23:10 +0100
                          Re: Kernel for Spectre and Meltdown Andy Smith <andy@strugglers.net> - 2018-02-04 00:20 +0100
                            Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-02-04 01:10 +0100
                              Re: Kernel for Spectre and Meltdown Andy Smith <andy@strugglers.net> - 2018-02-04 16:30 +0100
                                Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-02-05 00:10 +0100
                                Re: Kernel for Spectre and Meltdown Michael Fothergill <michael.fothergill@gmail.com> - 2018-02-05 00:10 +0100
                            Re: Kernel for Spectre and Meltdown rhkramer@gmail.com - 2018-02-04 05:30 +0100
      comment and new question--when do upgrades take effect  (was: Re: Kernel for Spectre and Meltdown) rhkramer@gmail.com - 2018-01-29 14:20 +0100
        Re: comment and new question--when do upgrades take effect  (was:  Re: Kernel for Spectre and Meltdown) Roberto C. Sánchez <roberto@debian.org> - 2018-01-29 14:50 +0100
        Re: comment and new question--when do upgrades take effect  (was:  Re: Kernel for Spectre and Meltdown) Joe <joe@jretrading.com> - 2018-01-29 14:50 +0100
          Re: comment and new question--when do upgrades take effect (was: Re:  Kernel for Spectre and Meltdown) Boyan Penkov <boyan.penkov@gmail.com> - 2018-01-29 15:40 +0100
            Re: comment and new question--when do upgrades take effect Richard Hector <richard@walnut.gen.nz> - 2018-01-30 00:20 +0100
              Re: comment and new question--when do upgrades take effect Boyan Penkov <boyan.penkov@gmail.com> - 2018-01-30 01:00 +0100
          Re: comment and new question--when do upgrades take effect  (was:  Re: Kernel for Spectre and Meltdown) David Wright <deblis@lionunicorn.co.uk> - 2018-01-29 17:20 +0100
        Re: comment and new question--when do upgrades take effect  (was:  Re: Kernel for Spectre and Meltdown) Andy Smith <andy@strugglers.net> - 2018-01-29 15:20 +0100
          Re: comment and new question--when do upgrades take effect Richard Owlett <rowlett@cloud85.net> - 2018-01-29 15:40 +0100
            Re: comment and new question--when do upgrades take effect Roberto C. Sánchez <roberto@debian.org> - 2018-01-29 15:40 +0100
              Re: comment and new question--when do upgrades take effect <tomas@tuxteam.de> - 2018-01-29 16:00 +0100
                Re: comment and new question--when do upgrades take effect Richard Owlett <rowlett@cloud85.net> - 2018-01-29 16:20 +0100
                  Re: comment and new question--when do upgrades take effect David Wright <deblis@lionunicorn.co.uk> - 2018-01-29 16:50 +0100
          Re: comment and new question--when do upgrades take effect (side  question) Neo <neo@spacerat.ch> - 2018-01-29 17:10 +0100
        Re: comment and new question--when do upgrades take effect  (was:  Re: Kernel for Spectre and Meltdown) Michael Lange <klappnase@freenet.de> - 2018-01-29 19:20 +0100
    Re: Kernel for Spectre and Meltdown Bastien Durel <bastien@durel.org> - 2018-01-29 10:50 +0100

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#191894

[Multipart message — attachments visible in raw view] — view raw

On 3 February 2018 at 23:14, Andy Smith <andy@strugglers.net> wrote:

> Hello,
>
> On Sat, Feb 03, 2018 at 09:43:33PM +0000, Michael Fothergill wrote:
> > I am trying to suggest one would want to move faster than the approximate
> > cycle time of new stable releases here.
>
> You have been repeatedly told that the updates will appear as
> security updates in Debian stable when the kernel team judges they
> have had an appropriate amount of testing. Security updates do not
> wait for the next stable release, nor even the next stable point
> release.
>
> You are writing vastly more text in this thread than any other
> single correspondent but you don't appear to be particularly
> familiar with your subject matter. I suggest that for a newcomer
> trying to follow your long and winding tale thinking it is somehow
> representative of Debian, *that* would seem like an odyssey, and
> there's just no need. The answers were all given in the first few
> posts and the rest of it is a combination of you misunderstanding
> what Debian is, and you wishing Debian was something that it's not.
>
>

> > I am concerned about new users and what they would have to to
> > install the current kernels (ie use a separate live sid
> > distribution (correctly and helpfully referred to by Andy) to
> > compile the new kernel and then transfer it to the stable
> > install).
>
> Well I didn't say you needed a live distribution, I suggested a
> chroot would be the normal way. Unless you consider a chroot to be a
> live distribution, which I personally would not, but it is
> debatable.
>

​OK I am incorrect here.​


>
> To me a live distribution is something you boot into, whereas a
> chroot is a lightweight thing that you just create, launch processes
> in and then throw away. No rebooting, etc. Telling people that they
> need "a live sid distribution" implies a lot more work than is
> actually required.
>
> > That does not seem to me to be ideal for a new user.  Hence my
> > comment about it not being fit for purpose at present.
>
> The Spectre bugs are quite unusual in that they need a kernel update
> *and* a new compiler to build it with (and microcode updates too).
> That is a really exceptional set of requirements and it would be
> inappropriate to design your whole distribution around that being a
> normal state of affairs.
>
> ​I agree it is only temporary. I don't a dramatic solution but perhaps
bending the rules
a bit for a while because it's a funny problem but I see that is pehpas not
really needed.​




> The mere fact that the Debian kernel team is waiting a little while
> before pushing new packages into stable does not for me render the
> entire distribution "not fit for purpose" - nor even the kernel
> team's processes.


​I did not think that at all.  Really not. It was just having to sid in
some way to make the new kernel for a while in some cases I now realise
with a chroot
I see now not a live distribution.



> *Someone*'s got to do that work and I'd rather
> Debian's kernel team did it than have the latest upstream stuff
> thrown at the general user base.
>
> Other distributions which track upstream more aggressively are
> designed for that. It's part of their contract with their users.
>
> Proposals to make some sort of rolling release version of Debian
> that more closely follows upstream have been made many times but
> have never come to much. For example:
>
>     <https://lists.debian.org/debian-devel/2015/03/msg00045.html>
>
> > It has been suggested to me others on the site that eventually the
> > GCC 7.3 compiler might be introduced into Debian Buster whereupon
> > it could be used to compile the latest kernels.
>
> I don't know what the plans are for gcc but that would make things a
> little easier, yes. However the route to a fix for the majority of
> Debian users will be to receive new binary kernel packages from a
> security update. Which is even easier.
>
> > The odyssey is debian itself as I see it.​
>
> …because you went on a learning experience and instead of doing what
> multiple people suggested, went down some very long dead ends of
> your own.
>
> If you want to make genuine constructive suggestions for how things
> could be improved, I think you should start by identifying what
> exactly the deficiencies are.
>

​Only wanting kernels quicker so chrooting not needed. ​


>
> A lot of this thread seems to have been along the lines of "it's too
> hard to build Debian kernel packages that are fixed against Spectre
> and Meltdown", but the point is marred by a) you taking a lot of
> wrong turns, and b) the Spectre bugs being quite exceptional in how
> they can be mitigated.
>

​I don't think its much harder than in gentoo which I have already done.
Trying with
GCC was making it more difficult than is now necessaruy and is fair
comment.​



>
> Having to build a chroot and then rebuild a kernel package with the
> gcc inside that chroot sounds tricky but it's actually fairly easy
> once you've done it once. Given how rare it is to need to do that,
> I'm not convinced it is that onerous or that it is any kind of
> condemnation of Debian.
>

​"Condemnation" is too harsh a word.  All I wanted was earlier new kernels
but
you have pointed out they are comgin soon above.​


​OK, I agree a chroot is *a lot* simpler than a live distribution of sid
etc. I use it
all time with gentoo and chroot into gentoo from debian all the time when
gentoo
has problems Sorry about that.​


>
> If that is *not* what you consider the deficiency to be, can you
> succinctly explain what it is?
>

​I think we should leave it at that.​

Cheers

MF



>
> Cheers,
> Andy
>
> --
> https://bitfolk.com/ -- No-nonsense VPS hosting
>
>

[toc] | [prev] | [next] | [standalone]

#191918

Hi Michael,

On Sat, Feb 03, 2018 at 11:44:39PM +0000, Michael Fothergill wrote:
> On 3 February 2018 at 23:14, Andy Smith <andy@strugglers.net> wrote:
> > If you want to make genuine constructive suggestions for how things
> > could be improved, I think you should start by identifying what
> > exactly the deficiencies are.
> 
> ​Only wanting kernels quicker so chrooting not needed. ​

Okay! That, Debian can do.

Easiest thing to do when requiring a newer kernel would be to check
the backports suite, so in this case in stretch-backports we find
linux-image-amd64:

    <https://packages.debian.org/stretch-backports/linux-image-amd64>

That's a virtual package that gets you the latest real kernel
package available in that suite, which right now is
linux-image-4.14.0-0.bpo.3-amd64:

    <https://packages.debian.org/stretch-backports/linux-image-amd64>

>From there, if you look on the right you will see the Debian
changelog link
<http://ftp-master.metadata.debian.org/changelogs//main/l/linux/linux_4.14.13-1~bpo9+1_changelog>
which tells us that this corresponds to upstream release 4.14.13.
The upstream release was made on 10 January and this backports
package came on 14 January, so that's pretty swift.

Of course, there have been newer upstream kernel releases since
then, but you can see from the Debian changelog that a new package
is made available every couple of weeks.

A lot of the time that is going to be "new enough" for anyone
running Debian stable who for some reason needs a newer kernel. No
need for compiling anything, no chroot, just install different
binary packages from a different suite. It was no use for your
specific request because it still lags behind upstream a little bit
and it wasn't compiled with a new enough gcc.

So what if you really do need to build a Debian kernel package based
off of the very latest upstream kernel release?

If you take a look at the Debian Linux Kernel Handbook
<https://kernel-handbook.alioth.debian.org/> you will see there is a
section about rebuilding the kernel package
<https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official>.
That isn't exactly what you want because it's talking about only
rebuilding from an existing source package, but it contains
instructions that you will also need later on.

Later on there's a section on building kernel packages from any
kernel source archive:
<https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-kernel-org-package>.
Using that process you can build kernel packages from the latest
kernel.org archive available.

Usually you can do that on the stable release, no chroot needed,
just a few downloads, a few commands and a lot of CPU time.

The reason why you were directed to do a lot more (chroot and gcc)
is because in the specific instance of Spectre a new gcc is needed
as well, and that was only available in Debian sid. Absent that
requirement, it is much simpler.

So there you go, the Debian Kernel team has got you covered for a
variety of kernel-related needs. :)

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#191932

[Multipart message — attachments visible in raw view] — view raw

On 4 February 2018 at 22:50, Michael Fothergill <
michael.fothergill@gmail.com> wrote:

>
>
> On 4 February 2018 at 15:20, Andy Smith <andy@strugglers.net> wrote:
>
>> Hi Michael,
>>
>> On Sat, Feb 03, 2018 at 11:44:39PM +0000, Michael Fothergill wrote:
>> > On 3 February 2018 at 23:14, Andy Smith <andy@strugglers.net> wrote:
>> > > If you want to make genuine constructive suggestions for how things
>> > > could be improved, I think you should start by identifying what
>> > > exactly the deficiencies are.
>> >
>> > ​Only wanting kernels quicker so chrooting not needed. ​
>>
>> Okay! That, Debian can do.
>>
>> Easiest thing to do when requiring a newer kernel would be to check
>> the backports suite, so in this case in stretch-backports we find
>> linux-image-amd64:
>>
>>     <https://packages.debian.org/stretch-backports/linux-image-amd64>
>>
>> That's a virtual package that gets you the latest real kernel
>> package available in that suite, which right now is
>> linux-image-4.14.0-0.bpo.3-amd64:
>>
>>     <https://packages.debian.org/stretch-backports/linux-image-amd64>
>>
>> >From there, if you look on the right you will see the Debian
>> changelog link
>> <http://ftp-master.metadata.debian.org/changelogs//main/l/li
>> nux/linux_4.14.13-1~bpo9+1_changelog>
>> which tells us that this corresponds to upstream release 4.14.13.
>> The upstream release was made on 10 January and this backports
>> package came on 14 January, so that's pretty swift.
>>
>
> ​This is impressive stuff.  I didn't know about this.  It seems that
> Debian is swifter and more responsive than I thought here..........​
>
>
>>
>> Of course, there have been newer upstream kernel releases since
>> then, but you can see from the Debian changelog that a new package
>> is made available every couple of weeks.
>>
>
> ​Now that sounds like a way forward here........​
>
>
>
>>
>> A lot of the time that is going to be "new enough" for anyone
>> running Debian stable who for some reason needs a newer kernel. No
>> need for compiling anything, no chroot, just install different
>> binary packages from a different suite. It was no use for your
>> specific request because it still lags behind upstream a little bit
>> and it wasn't compiled with a new enough gcc.
>>
>> ​Yes, but what you have posted here suggests at least two good things.
>
> One is that these current kernels are actually very nearly there (and
> impressively so) with respect to
> offering both meltdown and spectre protection.
>
> ​And the joint fix is likely to come  a lot faster than I had realised.
>
>
>
>
>> So what if you really do need to build a Debian kernel package based
>> off of the very latest upstream kernel release?
>>
>> If you take a look at the Debian Linux Kernel Handbook
>> <https://kernel-handbook.alioth.debian.org/> you will see there is a
>> section about rebuilding the kernel package
>> <https://kernel-handbook.alioth.debian.org/ch-common-tasks.
>> html#s-common-official>.
>> That isn't exactly what you want because it's talking about only
>> rebuilding from an existing source package, but it contains
>> instructions that you will also need later on.
>>
>> ​This is excellent - not just for me but for the brief period when a new
> user might want a bit
> extra flexiblity without too much technical difficulty - but I now realise
> that new kernels
> will likely also be put to debian stretch in the conventional way to solve
> this faster than
> I had thought as well.​
>
>
>
>> Later on there's a section on building kernel packages from any
>> kernel source archive:
>> <https://kernel-handbook.alioth.debian.org/ch-common-tasks.
>> html#s-kernel-org-package>.
>> Using that process you can build kernel packages from the latest
>> kernel.org archive available.
>>
>
> ​I will read up on this.​
>
>
>>
>> Usually you can do that on the stable release, no chroot needed,
>> just a few downloads, a few commands and a lot of CPU time.
>>
>> The reason why you were directed to do a lot more (chroot and gcc)
>> is because in the specific instance of Spectre a new gcc is needed
>> as well, and that was only available in Debian sid. Absent that
>> requirement, it is much simpler.
>>
>
> ​And it is only a temporary problem, and also I now realise the response
> to it
> will come a lot faster than I had realised.​
>
>
>
>> So there you go, the Debian Kernel team has got you covered for a
>> variety of kernel-related needs. :)
>>
>
> ​Impressive stuff.  ​
>
> ​I now realise that I was too gloomy in email posts
> and
> ​ needed to be​
> thinking in a "glass half full" kind of way
> ​ instead​
> .
>

​I made a correction to the above sentence.​



>
> Debian has more firepower built into it than I had imagined.
>
> I apologise for being such a silly eeyore and grinch here. No more
> gloomy posts from now on!
>
> Regards
>
> MF​
>
>>
>> Cheers,
>> Andy
>>
>> --
>> https://bitfolk.com/ -- No-nonsense VPS hosting
>>
>>
>

[toc] | [prev] | [next] | [standalone]

#191934

[Multipart message — attachments visible in raw view] — view raw

On 4 February 2018 at 15:20, Andy Smith <andy@strugglers.net> wrote:

> Hi Michael,
>
> On Sat, Feb 03, 2018 at 11:44:39PM +0000, Michael Fothergill wrote:
> > On 3 February 2018 at 23:14, Andy Smith <andy@strugglers.net> wrote:
> > > If you want to make genuine constructive suggestions for how things
> > > could be improved, I think you should start by identifying what
> > > exactly the deficiencies are.
> >
> > ​Only wanting kernels quicker so chrooting not needed. ​
>
> Okay! That, Debian can do.
>
> Easiest thing to do when requiring a newer kernel would be to check
> the backports suite, so in this case in stretch-backports we find
> linux-image-amd64:
>
>     <https://packages.debian.org/stretch-backports/linux-image-amd64>
>
> That's a virtual package that gets you the latest real kernel
> package available in that suite, which right now is
> linux-image-4.14.0-0.bpo.3-amd64:
>
>     <https://packages.debian.org/stretch-backports/linux-image-amd64>
>
> >From there, if you look on the right you will see the Debian
> changelog link
> <http://ftp-master.metadata.debian.org/changelogs//main/l/
> linux/linux_4.14.13-1~bpo9+1_changelog>
> which tells us that this corresponds to upstream release 4.14.13.
> The upstream release was made on 10 January and this backports
> package came on 14 January, so that's pretty swift.
>

​This is impressive stuff.  I didn't know about this.  It seems that
Debian is swifter and more responsive than I thought here..........​


>
> Of course, there have been newer upstream kernel releases since
> then, but you can see from the Debian changelog that a new package
> is made available every couple of weeks.
>

​Now that sounds like a way forward here........​



>
> A lot of the time that is going to be "new enough" for anyone
> running Debian stable who for some reason needs a newer kernel. No
> need for compiling anything, no chroot, just install different
> binary packages from a different suite. It was no use for your
> specific request because it still lags behind upstream a little bit
> and it wasn't compiled with a new enough gcc.
>
> ​Yes, but what you have posted here suggests at least two good things.

One is that these current kernels are actually very nearly there (and
impressively so) with respect to
offering both meltdown and spectre protection.

​And the joint fix is likely to come  a lot faster than I had realised.




> So what if you really do need to build a Debian kernel package based
> off of the very latest upstream kernel release?
>
> If you take a look at the Debian Linux Kernel Handbook
> <https://kernel-handbook.alioth.debian.org/> you will see there is a
> section about rebuilding the kernel package
> <https://kernel-handbook.alioth.debian.org/ch-common-
> tasks.html#s-common-official>.
> That isn't exactly what you want because it's talking about only
> rebuilding from an existing source package, but it contains
> instructions that you will also need later on.
>
> ​This is excellent - not just for me but for the brief period when a new
user might want a bit
extra flexiblity without too much technical difficulty - but I now realise
that new kernels
will likely also be put to debian stretch in the conventional way to solve
this faster than
I had thought as well.​



> Later on there's a section on building kernel packages from any
> kernel source archive:
> <https://kernel-handbook.alioth.debian.org/ch-common-
> tasks.html#s-kernel-org-package>.
> Using that process you can build kernel packages from the latest
> kernel.org archive available.
>

​I will read up on this.​


>
> Usually you can do that on the stable release, no chroot needed,
> just a few downloads, a few commands and a lot of CPU time.
>
> The reason why you were directed to do a lot more (chroot and gcc)
> is because in the specific instance of Spectre a new gcc is needed
> as well, and that was only available in Debian sid. Absent that
> requirement, it is much simpler.
>

​And it is only a temporary problem, and also I now realise the response to
it
will come a lot faster than I had realised.​



> So there you go, the Debian Kernel team has got you covered for a
> variety of kernel-related needs. :)
>

​Impressive stuff.  ​

​I now realise that I was too gloomy in email posts
and thinking in a "glass half full" kind of way.

Debian has more firepower built into it than I had imagined.

I apologise for being such a silly eeyore and grinch here. No more
gloomy posts from now on!

Regards

MF​

>
> Cheers,
> Andy
>
> --
> https://bitfolk.com/ -- No-nonsense VPS hosting
>
>

[toc] | [prev] | [next] | [standalone]

#191895

On Saturday, February 03, 2018 06:14:11 PM Andy Smith wrote:
> Hello,
> 
> On Sat, Feb 03, 2018 at 09:43:33PM +0000, Michael Fothergill wrote:
> > I am trying to suggest one would want to move faster than the approximate
> > cycle time of new stable releases here.
> 
> You have been repeatedly told that the updates will appear as
> security updates in Debian stable when the kernel team judges they
> have had an appropriate amount of testing. Security updates do not
> wait for the next stable release, nor even the next stable point
> release.

+1

> You are writing vastly more text in this thread than any other
> single correspondent but you don't appear to be particularly
> familiar with your subject matter. I suggest that for a newcomer
> trying to follow your long and winding tale thinking it is somehow
> representative of Debian, *that* would seem like an odyssey, and
> there's just no need. The answers were all given in the first few
> posts and the rest of it is a combination of you misunderstanding
> what Debian is, and you wishing Debian was something that it's not.

+1

Other good stuff elided.

[toc] | [prev] | [next] | [standalone]

#191722 — comment and new question--when do upgrades take effect (was: Re: Kernel for Spectre and Meltdown)

On Monday, January 29, 2018 03:35:58 AM Michael Fothergill wrote:
> On 29 January 2018 at 07:52, Dextin Jerafmel <jerafmel@yahoo.com> wrote:
> > I tried to search for available Kernel images but there isn't any newer
> > Kernel than 4.9.0.5

> ​Your need to upgrade to unstable (Debian Sid).  Then you need to get the
> latest kernel from the kernel.org website.

I just want to emphasize that you don't need to upgrade to unstable (Debian 
Sid).

See the response in this thread from Bastien Durel.

Also, iiuc, the fixes for Spectre and Meltdown have been "backported" (probably 
not the right word) to Wheezy (which is my "everyday" machine).  If I'm wrong 
about that, somebody can let me know.

Sort of a digression:

I regularly download "security" upgrades for Wheezy.  I assume that most of 
those don't take effect until I restart the application.  For instance, a 
Firefox upgrade does not take effect until I shutdown Firefox and restart it.

Correspondingly, I assume that a Linux kernel upgrade does not take effect 
until I reboot the machine.

I guess I can confirm by watching version numbers next time I get a kernel 
upgrade, but if someone can respond now, that would (possibly) set my mind at 
ease.

[toc] | [prev] | [next] | [standalone]

#191727 — Re: comment and new question--when do upgrades take effect (was: Re: Kernel for Spectre and Meltdown)

On Mon, Jan 29, 2018 at 08:18:35AM -0500, rhkramer@gmail.com wrote:
> 
> I regularly download "security" upgrades for Wheezy.  I assume that most of 
> those don't take effect until I restart the application.  For instance, a 
> Firefox upgrade does not take effect until I shutdown Firefox and restart it.
> 
That is correct.

> Correspondingly, I assume that a Linux kernel upgrade does not take effect 
> until I reboot the machine.
> 
Also correct.

You also need to be careful of library upgrades.  Fore xample, if there
is an update to libssl, then any application that uses it (i.e.,
dynamically links it or dlopens it) needs to be restarted.  If you run
Postfix and Apache (and have their SSL features configured and active)
you would need to restart them following a libssl upgade in order to
ensure that they are using the latest version.

Regards,

-Roberto

-- 
Roberto C. Sánchez

[toc] | [prev] | [next] | [standalone]

#191729 — Re: comment and new question--when do upgrades take effect (was: Re: Kernel for Spectre and Meltdown)

On Mon, 29 Jan 2018 08:18:35 -0500
rhkramer@gmail.com wrote:


> 
> I regularly download "security" upgrades for Wheezy.  I assume that
> most of those don't take effect until I restart the application.  For
> instance, a Firefox upgrade does not take effect until I shutdown
> Firefox and restart it.
> 
> Correspondingly, I assume that a Linux kernel upgrade does not take
> effect until I reboot the machine.

Yes, but it's a little more complicated. The modules used by the kernel
(and the kernel file itself) *are* replaced during the process of
upgrading the kernel, but the running code is not. There is a tiny
chance of some kind of mismatch if new modules are loaded, so rebooting
is recommended soon, and in the past I used to see a message to that
effect, displayed during the upgrade.

Generally, user applications (e.g. Firefox) will not be restarted
automatically, but most daemons will be e.g. mysql, exim4. Some
important daemons may request your input as to whether to restart or
not e.g. during a major upheaval such as a libc upgrade. Pretty much
all software on a server is in the form of daemons, and generally
rebooting a server is only necessary after a change of kernel.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#191734 — Re: comment and new question--when do upgrades take effect (was: Re: Kernel for Spectre and Meltdown)

[Multipart message — attachments visible in raw view] — view raw

Does checkrestart (apt-get install checkrestart) prompt for application
restarts on library updates, or only for daemons?

On Jan 29, 2018 08:43, "Joe" <joe@jretrading.com> wrote:

> On Mon, 29 Jan 2018 08:18:35 -0500
> rhkramer@gmail.com wrote:
>
>
> >
> > I regularly download "security" upgrades for Wheezy.  I assume that
> > most of those don't take effect until I restart the application.  For
> > instance, a Firefox upgrade does not take effect until I shutdown
> > Firefox and restart it.
> >
> > Correspondingly, I assume that a Linux kernel upgrade does not take
> > effect until I reboot the machine.
>
> Yes, but it's a little more complicated. The modules used by the kernel
> (and the kernel file itself) *are* replaced during the process of
> upgrading the kernel, but the running code is not. There is a tiny
> chance of some kind of mismatch if new modules are loaded, so rebooting
> is recommended soon, and in the past I used to see a message to that
> effect, displayed during the upgrade.
>
> Generally, user applications (e.g. Firefox) will not be restarted
> automatically, but most daemons will be e.g. mysql, exim4. Some
> important daemons may request your input as to whether to restart or
> not e.g. during a major upheaval such as a libc upgrade. Pretty much
> all software on a server is in the form of daemons, and generally
> rebooting a server is only necessary after a change of kernel.
>
> --
> Joe
>
>

[toc] | [prev] | [next] | [standalone]

#191759 — Re: comment and new question--when do upgrades take effect

[Multipart message — attachments visible in raw view] — view raw

On 30/01/18 03:35, Boyan Penkov wrote:
> Does checkrestart (apt-get install checkrestart) prompt for application
> restarts on library updates, or only for daemons?

apt-get install debian-goodies, actually. Yes, I think so. But for
jessie onwards, I find needrestart (package: needrestart) much nicer. It
tells you about kernel mismatches too, which checkrestart doesn't. Fewer
false positives, too.

Richard

[toc] | [prev] | [next] | [standalone]

#191760 — Re: comment and new question--when do upgrades take effect

On Mon, Jan 29, 2018 at 6:18 PM, Richard Hector <richard@walnut.gen.nz> wrote:
> On 30/01/18 03:35, Boyan Penkov wrote:
>> Does checkrestart (apt-get install checkrestart) prompt for application
>> restarts on library updates, or only for daemons?
>
> apt-get install debian-goodies, actually. Yes, I think so. But for
> jessie onwards, I find needrestart (package: needrestart) much nicer. It
> tells you about kernel mismatches too, which checkrestart doesn't. Fewer
> false positives, too.

Yep, Richard is absolutely correct here -- I biffed up the package
names too early in the morning.....

>
> Richard
>



-- 
Boyan Penkov

[toc] | [prev] | [next] | [standalone]

#191745 — Re: comment and new question--when do upgrades take effect (was: Re: Kernel for Spectre and Meltdown)

On Mon 29 Jan 2018 at 13:43:20 (+0000), Joe wrote:
> On Mon, 29 Jan 2018 08:18:35 -0500
> rhkramer@gmail.com wrote:
> 
> 
> > 
> > I regularly download "security" upgrades for Wheezy.  I assume that
> > most of those don't take effect until I restart the application.  For
> > instance, a Firefox upgrade does not take effect until I shutdown
> > Firefox and restart it.
> > 
> > Correspondingly, I assume that a Linux kernel upgrade does not take
> > effect until I reboot the machine.
> 
> Yes, but it's a little more complicated. The modules used by the kernel
> (and the kernel file itself) *are* replaced during the process of
> upgrading the kernel, but the running code is not. There is a tiny
> chance of some kind of mismatch if new modules are loaded, so rebooting
> is recommended soon, and in the past I used to see a message to that
> effect, displayed during the upgrade.

For the benefit of the OP, who is unaware of the meaning of version
numbers, it's worth pointing out that during their upgrade, they got
a new set of modules along with the kernel because the new kernel was
in a new package with a new name.

However, it's not clear that, having searched for a new kernel and
found ("only") a 4.9.0-5 one, they have installed it. If they haven't,
they need to, or else they will not receive further upgrades.
Better still, install the most generic/least specific kernel metapackage
so that upgrades will be automatic (or more obvious, depending on
the tools used).

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#191732 — Re: comment and new question--when do upgrades take effect (was: Re: Kernel for Spectre and Meltdown)

Hi,

On Mon, Jan 29, 2018 at 08:18:35AM -0500, rhkramer@gmail.com wrote:
> iiuc, the fixes for Spectre and Meltdown have been "backported"
> (probably not the right word) to Wheezy (which is my "everyday"
> machine).  If I'm wrong about that, somebody can let me know.

The confusion here is that "Spectre and Meltdown" comprise multiple
different (but related) vulnerabilities.

The dangerous effects of Meltdown are avoided in Linux by use of the
KPTI feature which is now in Debian's supported kernels.

Fixing one of the Spectre vulnerabilities requires new CPU
microcode, possibly a new BIOS, new kernel features and kernel to be
compiled with an as-yet unreleased version of GCC. For this you
would currently need to get a few things from sid and build your own
kernel. The risk/reward calculation for these actions requires some
thought because a suitable kernel update is likely to appear soon.

As for the other known Spectre vulnerability: no one has much of an
idea how to avoid yet, but probably will in the near future.

There are likely to be further vulnerabilities in this class that
are as-yet unknown at least to the public. There are also likely to
be new mitigations developed that get around known problems in less
expensive ways. So expect a lot more kernel updates in our near
future.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#191735 — Re: comment and new question--when do upgrades take effect

On 01/29/2018 08:15 AM, Andy Smith wrote:
> [snip]
> 
> The dangerous effects of Meltdown are avoided in Linux by use of the
> KPTI feature which is now in Debian's supported kernels.
> 

I've seen comments such as that before.
But I've not seen anything about "What is KPTI or how to use it".

[toc] | [prev] | [next] | [standalone]

#191736 — Re: comment and new question--when do upgrades take effect

On Mon, Jan 29, 2018 at 08:29:33AM -0600, Richard Owlett wrote:
> On 01/29/2018 08:15 AM, Andy Smith wrote:
> > [snip]
> > 
> > The dangerous effects of Meltdown are avoided in Linux by use of the
> > KPTI feature which is now in Debian's supported kernels.
> > 
> 
> I've seen comments such as that before.
> But I've not seen anything about "What is KPTI or how to use it".
> 
KPTI - kernel page table isolation

It basicall puts all kernel memory addresses in a completely different
address range than those of user processes.  You don't "use" it as the
kernel handles all of that for you.  All that is needed is to boot a
kernel that has the feature and then it will work automatically.  The
reason it protects against Meltdown is because accesses to kernel memory
under the new construct will force a context switch (meaning that stale
values are not left in machine registers that are accesible to user
code).

Also, there is a parameter you can pass to the kernel at boot time to
disable KPTI if you would rather not have it.

The Wikipedia article on the subject is much more informative, if you
want to go deeper.

Regards,

-Roberto

-- 
Roberto C. Sánchez

[toc] | [prev] | [next] | [standalone]

#191738 — Re: comment and new question--when do upgrades take effect

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Jan 29, 2018 at 09:37:54AM -0500, Roberto C. Sánchez wrote:
> On Mon, Jan 29, 2018 at 08:29:33AM -0600, Richard Owlett wrote:

[...]

> > I've seen comments such as that before.
> > But I've not seen anything about "What is KPTI or how to use it".
> > 
> KPTI - kernel page table isolation

[...]

> The Wikipedia article on the subject is much more informative, if you
> want to go deeper.

Indeed -- a visit to the Internet Library of Alexandria (aka Wikipedia)
should be mandatory these days (quick! before someone burns it down :-)

  https://en.wikipedia.org/wiki/KPTI

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlpvNRMACgkQBcgs9XrR2kbjpgCeOlEV1rXNEtQgveZS0TChdy4W
u4MAn3V4l58N0moF6t3Rbbqip4bze2r3
=e6vk
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#191739 — Re: comment and new question--when do upgrades take effect

On 01/29/2018 08:52 AM, tomas@tuxteam.de wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Mon, Jan 29, 2018 at 09:37:54AM -0500, Roberto C. Sánchez wrote:
>> On Mon, Jan 29, 2018 at 08:29:33AM -0600, Richard Owlett wrote:
> 
> [...]
> 
>>> I've seen comments such as that before.
>>> But I've not seen anything about "What is KPTI or how to use it".
>>>
>> KPTI - kernel page table isolation
> 
> [...]
> 
>> The Wikipedia article on the subject is much more informative, if you
>> want to go deeper.
> 
> Indeed -- a visit to the Internet Library of Alexandria (aka Wikipedia)
> should be mandatory these days (quick! before someone burns it down :-)
> 
>    https://en.wikipedia.org/wiki/KPTI
> 

Mea [not quite] culpa
I quit reading before the last sentence as it was talking about 
implementation details without any evident interest in Joe End User.
And that last sentence was not really informative. IMHO

There has been a similar tendency in this and related threads.

[toc] | [prev] | [next] | [standalone]

#191741 — Re: comment and new question--when do upgrades take effect

On Mon 29 Jan 2018 at 09:17:14 (-0600), Richard Owlett wrote:
> On 01/29/2018 08:52 AM, tomas@tuxteam.de wrote:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >On Mon, Jan 29, 2018 at 09:37:54AM -0500, Roberto C. Sánchez wrote:
> >>On Mon, Jan 29, 2018 at 08:29:33AM -0600, Richard Owlett wrote:
> >
> >[...]
> >
> >>>I've seen comments such as that before.
> >>>But I've not seen anything about "What is KPTI or how to use it".
> >>>
> >>KPTI - kernel page table isolation
> >
> >[...]
> >
> >>The Wikipedia article on the subject is much more informative, if you
> >>want to go deeper.
> >
> >Indeed -- a visit to the Internet Library of Alexandria (aka Wikipedia)
> >should be mandatory these days (quick! before someone burns it down :-)
> >
> >   https://en.wikipedia.org/wiki/KPTI
> >
> 
> Mea [not quite] culpa
> I quit reading before the last sentence as it was talking about
> implementation details without any evident interest in Joe End User.

Well, certain end users seem to be very impatient for a fix before the
true scale of the problem has been fully appreciated.

> And that last sentence was not really informative. IMHO

You never know these days. We may eventually look back at Wikipedia
with nostalgia. Remember Net Neutrality, Fairness Doctrine, …?

> There has been a similar tendency in this and related threads.

No idea of what is meant and in what.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#191743 — Re: comment and new question--when do upgrades take effect (side question)

Sorry for the hijack, but has this also to do with this newly enabled 
default kernel options?

grep STACKPROTECTOR /boot/config-3.16.0-5-amd64
CONFIG_HAVE_CC_STACKPROTECTOR=y
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR_NONE is not set
CONFIG_CC_STACKPROTECTOR_REGULAR=y
# CONFIG_CC_STACKPROTECTOR_STRONG is not set

because dkms now fails and so my geoip support in iptables is now 
broken, as the module is missing.

BR, Spacerat

Am 29.01.2018 um 15:15 schrieb Andy Smith:
> Hi,
>
> On Mon, Jan 29, 2018 at 08:18:35AM -0500, rhkramer@gmail.com wrote:
>> iiuc, the fixes for Spectre and Meltdown have been "backported"
>> (probably not the right word) to Wheezy (which is my "everyday"
>> machine).  If I'm wrong about that, somebody can let me know.
> The confusion here is that "Spectre and Meltdown" comprise multiple
> different (but related) vulnerabilities.
>
> The dangerous effects of Meltdown are avoided in Linux by use of the
> KPTI feature which is now in Debian's supported kernels.
>
> Fixing one of the Spectre vulnerabilities requires new CPU
> microcode, possibly a new BIOS, new kernel features and kernel to be
> compiled with an as-yet unreleased version of GCC. For this you
> would currently need to get a few things from sid and build your own
> kernel. The risk/reward calculation for these actions requires some
> thought because a suitable kernel update is likely to appear soon.
>
> As for the other known Spectre vulnerability: no one has much of an
> idea how to avoid yet, but probably will in the near future.
>
> There are likely to be further vulnerabilities in this class that
> are as-yet unknown at least to the public. There are also likely to
> be new mitigations developed that get around known problems in less
> expensive ways. So expect a lot more kernel updates in our near
> future.
>
> Cheers,
> Andy
>

[toc] | [prev] | [next] | [standalone]

#191749 — Re: comment and new question--when do upgrades take effect (was: Re: Kernel for Spectre and Meltdown)

On Mon, 29 Jan 2018 08:18:35 -0500
rhkramer@gmail.com wrote:

> On Monday, January 29, 2018 03:35:58 AM Michael Fothergill wrote:
> > On 29 January 2018 at 07:52, Dextin Jerafmel <jerafmel@yahoo.com>
> > wrote:
> > > I tried to search for available Kernel images but there isn't any
> > > newer Kernel than 4.9.0.5
> 
> > ​Your need to upgrade to unstable (Debian Sid).  Then you need to get
> > the latest kernel from the kernel.org website.
> 
> I just want to emphasize that you don't need to upgrade to unstable
> (Debian Sid).
> 
> See the response in this thread from Bastien Durel.
> 
> Also, iiuc, the fixes for Spectre and Meltdown have been
> "backported" (probably not the right word) to Wheezy (which is my
> "everyday" machine).  If I'm wrong about that, somebody can let me know.

I think this is only true for the Meltdown fix ("page tables isolation"),
for the Spectre fix ("retpoline") work is apparently in progress.

Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

[Doctors and Bartenders], We both get the same two kinds of customers
-- the living and the dying.
		-- Dr. Boyce, "The Menagerie" ("The Cage"), stardate
unknown

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | linux.debian.user

csiph-web