MX17.x migrated to MX18.3 : What kernel should I be on?

[entropyagent]

My kernel is now

Code: Select all

$ uname -a
Linux brain 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1~mx17+1 (2020-10-20) x86_64 GNU/Linux

$ aptitude search 'linux-image ?installed'
i   linux-image-4.13.0-1-amd64                - Linux 4.13 for 64-bit PCs                           
i   linux-image-4.19.0-12-amd64-unsigned      - Linux 4.19 for 64-bit PCs                           

and I will be paying more attention to see if I get updates. Thinking back over the last 10 years or so, I think this is the first time that my 'aptitude full-upgrades' did not bring me an updated kernel several times a year.

Regarding the microcode issue, I see MXPI tells me I have a greyed out iucode-tool 2.1.1-1 from Stable Repo, but Debian Backports is tempting me with iucode-tool 2.3.1-1-bpo9+1. Can I safely experiment with this update to see if it changes performance/stability/reported vulnerabilities, without exploding my Intel Core2 Duo E7500 (which does not actually seem to be HyperThreading capable, according to Intel) ?

Thanks for the guidance.

P.S. Is MXPI just casually opening a temporary portal into other repositories so I can browse them, without actually making permanent changes that might bite me if I forget them? That is seriously cool.

[tony37]

What is it about the microcode you are worried about?
I think iucode-tool is not the microcode itself, just a simple tool ("man iucode-tool" for more explanation)
You can use MXPI to have a look at the MX Test repo and at the Debian Backports repo without permanently enabling said repos.

[Huckleberry Finn]

...mentions CPU microcode quite a bit. My current level seems to have received at update recently, which is encouraging ...

Code: Select all

$ cat /etc/modprobe.d/intel-microcode-blacklist.conf
# The microcode module attempts to apply a microcode update when
# it autoloads.  This is not always safe, so we block it by default.
blacklist microcode

:)

[Stevo]

4.19.152 is the current Buster security updated version we backported to MX 17/18.

You're good.

[entropyagent]

What is it about the microcode you are worried about?

I developed this interest after discovering that my meticulous updating regimen of an occasional "aptitude update;aptitude full-upgrade" had left me on the same kernel for +-3 years, which rocked my naively trusting worldview. Now I am wondering what else has been neglected. At around the same time I heard of spectre-meltdown-checker, which, while it might be a little obsessively focused, did help to alert me to the outdated-kernel issue. With a lot of help from the forum MXers, I now have a more recent kernel, which I hope will receive ongoing updates.

However, spectre-meltdown-checker seems not entirely satisfied with this, and offers such encouraging comments as:

STATUS: VULNERABLE (Your kernel supports mitigation, but your CPU microcode also needs to be updated to mitigate the vulnerability)

and

CVE-2018-3640 aka 'Variant 3a, rogue system register read'
* CPU microcode mitigates the vulnerability: NO
> STATUS: VULNERABLE (an up-to-date CPU microcode is needed to mitigate this vulnerability)

> How to fix: The microcode of your CPU needs to be upgraded to mitigate this vulnerability. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section). The microcode update is enough, there is no additional OS, kernel or software change needed.

Sadly, I lack the wit to make much sense of these helpful hints, but my wishfulthinkotron translates that last comment "The microcode update is enough, there is no additional OS, kernel or software change needed." as "Clever, competent people will fix the problem for me, without me having to do anything" which, you must admit, is a cheering straw to clutch at.

On this subject, I commented out the blacklist for "microcode", so I hope this means my boot is trying to load it?

Code: Select all

$ cat /etc/modprobe.d/intel-microcode-blacklist.conf
# The microcode module attempts to apply a microcode update when
# it autoloads.  This is not always safe, so we block it by default.
##blacklist microcode

I tried a boot with each kernel, but the results were not positive - what am I doing wrong?

Code: Select all

$ aptitude search 'ucode ?installed' 'microcode ?installed'
i   amd64-microcode                           - Processor microcode firmware for AMD CPUs           
i   intel-microcode                           - Processor microcode firmware for Intel CPUs         
i   iucode-tool                               - Intel processor microcode tool                      

$ uname -a
Linux brain 4.13.0-1-amd64 #1 SMP Debian 4.13.13-1mx17 (2017-11-18) x86_64 GNU/Linux
yyy@zzz:~
$ lsmod | grep -i micro
yyy@zzz:~
$ sudo modprobe -v microcode
modprobe: FATAL: Module microcode not found in directory /lib/modules/4.13.0-1-amd64
yyy@zzz:~
$ 

$ uname -a
Linux brain 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1~mx17+1 (2020-10-20) x86_64 GNU/Linux
yyy@zzz:~
$ lsmod | grep -i micro
yyy@zzz:~
$ sudo modprobe -v microcode
[sudo] password for paul: 
modprobe: FATAL: Module microcode not found in directory /lib/modules/4.19.0-12-amd64

So, questions:

1) Is there anything more I need to do to get my system up to date so that it stays up to date? One suggestion seems to be "update the microcode", but
1a) Is this possible?
1b) Is this necessary?
1c) How?

Thinking outside the box:

A fresh install of MX19 is an option - I have one ready and waiting - but I kinda like ecryptfs, which is not (yet) available there.

A fresh install of MX18.1 is an option (I have the media at hand) - would this neatly overcome the concern about what updates have been neglected? The Migration page says

Code: Select all

From MX-18 to MX-18.3

Update will be automatic through the normal update process. 

but then again, it said something "similar" about migration from 17 to 18

Admittedly, it's basically laziness that has stopped this. And pride....I hoped I had left "Just reinstall" behind. And I would still have to fight with getting abcde to work with converting my CDs (another thread planned). And I am learning quite a bit, though it will probably all be forgotten within days.

[tony37]

With a lot of help from the forum MXers, I now have a more recent kernel, which I hope will receive ongoing updates.

It won't, I explained this in post 10. Best solution at the moment is:

Code: Select all

sudo apt install linux-image-4.19-amd64 linux-headers-4.19-amd64

For the microcode, what does this say?

Code: Select all

dmesg | grep microcode

[asqwerth]

MX17 and 18 are both based on Debian Stretch. Why would you need to do a fresh update of MX18 over MX17? Just keep MX17 fully updated and install the latest MX 4.19 kernel from MXPI Popular apps tab. If you're going to fresh install, then you might as well fresh install MX19 and preserve /home.

MX18.3 is essentially just MX17 with all the updates rolled up, except for the kernel, because kernels only auto-update within its own series (and except for the MX18 collection of wallpapers, which you can get from MXPI popular apps tab as well). Since MX17 was released with 4.13 kernel, it won't suddenly jump to installing 4.19 series kernel (which the MX18 iso was released with), but that's why we have the MXPI tool.

I have 2 installs of MX17 still running. I never bothered to install MX18 over it. The distro release file reads it as MX18, just with an earlier (MX17's) release date. I just made sure to install newer kernels (either liquorix 5+ series or the MX 4.19 series, again using MXPI Popular apps tab).

[Stevo]

What version of intel-microcode do you have installed? Debian Stretch and Buster both have the current release. If you still have the microcode problem, that means that Intel didn't update the microcode for your particular CPU. It's Intel's closed firmware, so you're stuck with what they decided.

[entropyagent]

Maybe it's worth separating the kernel story from the microcode story.

I see a possible contradiction between these Stevo statements:

We recommend that MX 18.3 users keep the backported 4.19 Debian kernels it uses as default updated to the latest 4.19 security updates we continue to backport to main from the Buster repository. Currently, that's the 4.19.0-12 (4.19.152) kernel.

+

4.19.152 is the current Buster security updated version we backported to MX 17/18.

You're good.

and this tony37 contribution:

With a lot of help from the forum MXers, I now have a more recent kernel, which I hope will receive ongoing updates.

It won't, I explained this in post 10. Best solution at the moment is:

Code: Select all

sudo apt install linux-image-4.19-amd64 linux-headers-4.19-amd64

Are they addressing the same topic? I would like both

1) an up-to-date kernel and

2] to be automagically kept up to date with security patches, with no more effort on my part than an
occasional "aptitude full-upgrade". Goal no. 2 is what I mean by "on the train".


Stevo seems to be saying I have achieved goal number 1) with my current kernel
"linux-image-4.19.0-12-amd64-unsigned" (Thanks) But what about goal no. 2) ? Is that included in "You're good."?
Stevo, can you please clarify this point?

tony37 seems to be saying I have definitely not achieved goal no. 2), and the best way to achieve both 1) and 2) is by installing "linux-image-4.19-amd64 linux-headers-4.19-amd64", which, at present, will pull in
linux-headers-4.19.0-0.bpo.12-amd64
linux-headers-4.19.0-0.bpo.12-common
linux-image-4.19.0-0.bpo.12-amd64
and <will> be kept up-to-date automagically by an occasional "aptitude full-upgrade"
Did I understand that correctly?

Thanks for the feedback so far.

[Stevo]

My statement applies to MX 17/18 only. Tony's is for MX 19, which uses Debian's 4.19 kernel by default.

Apples and oranges.