Installing microcode to protect against Spectre/Meltdown

[bob466]

Hi panorain,

This may be of help...https://www.pcsuggest.com/update-cpu-mi ... -in-linux/

[michael louwe]

@ smurphos, .......

Michael - the Microcode packages from the repos are cumulative - i.e. 3.20180108 contains all current Microcodes not just the new and updated ones highlighted in the changelog.

So a user with an older machine will get the most up to date microcode available for their processor whether they install 3.20180108 package or the predecessor 3.20170707. They may as well stay up to date...

The point is not whether the Intel microcode updates are cumulative. The main point is whether Linux users should install the Intel microcode 20180108 update if the update does not apply to their older processors.
... My recommendation is No, because microcode updates can be dangerous to the system. Why take the risk.? There are reports that the Intel microcode 20180108 update has broken some systems, eg ... https://www.bleepingcomputer.com/news/s ... ot-issues/ .
... The Linux users should instead wait for Intel to release the appropriate microcode update for their older processors. There is a possibility that Intel may never release any microcode update for processors that are more than 10 years old and are not high-end Core i (= Core i3, i5, i7 and Xeon), eg in order to FUD them into buying new computers and Intel processors.

Here is a link on "How to update CPU microcode in Linux" ... https://www.pcsuggest.com/update-cpu-mi ... -in-linux/ , where Linux users are also taught to install the Intel iucode_tool to check whether their CPU needs a microcode update. Why the need for such a tool if all Linux users should install every latest Intel microcode update just because they are cumulative, even though it may not apply to their processor.?

During installation, Intel microcode updates work by auto-detecting the Linux users' processor and will only actually install the necessary microcode changes if the processor is applicable to the update. Nothing is changed by the microcode update if the processor is not applicable.
... In the case of microcode 20180108, the update applies only to high-end Intel processors that are not more than 5 years old, ie 3rd-gen Ivy Town(= Xeon) and 4th-gen Haswell or newer. It does not apply to 3rd-gen Ivy Bridge or older. These will have to wait.

For Win 10, users must install every latest cumulative updates and feature updates, in order to remain supported by M$ with security updates. M$ have even stopped such support for Win 7/8.1 computers running the latest 7th-gen Intel Kabylake processors, in order to force the users onto Win 10, eg by buying new Win 10 computers.
... Even though cumulative, Intel microcode updates are different, ie not forced.

[panorain]

I did ----> No idea - you have reboot into it? <---- reboot the Compaq machine. After ugh the kernel update to ---> 4.4.0-109 <--- which

I feel upset about - - ->

Code: Select all

dmesg | grep isolation

not being reported . <-- on the Compaq .

Should I just leave the entry's displayed below / installed as the following in apt then for now or not ? It appears Intel packages then and or CPUS's are not secure if they are outdated.

ii intel-gpu-tools 1.3-0ubuntu2.1 amd64 tools for debugging the Intel graphics driver
ii intel-microcode 3.20180108.0~ubuntu14.04.2 amd64 Processor microcode firmware for Intel CPUs

Thank you for all your time .

[thx-1138]

...Michael:
https://bugs.debian.org/cgi-bin/bugrepo ... bug=886998
And also:
http://metadata.ftp-master.debian.org/c ... _changelog

Ie. there were approximately 20 microcodes updated in the last package, along with a couple of 'downgrades'. Quite a few of them (around 7 it seems so far & hopefully not more than that?) were found to be problematic, let's say a rushed job from Intel's side.
Now, all of those are meant for relatively new processors as we know...and apparently those were the ones that Red Hat reverted to their previous versions (20171117) be on the safe side & have it's peace of mind customer-wise.

Ie. you said it yourself actually...

During installation, Intel microcode updates work by auto-detecting the Linux users' processor and will only actually install the necessary microcode changes if the processor is applicable to the update. Nothing is changed by the microcode update if the processor is not applicable.

Nothing is changed if the processor is not applicable (eg. an older one) - so how is that going to cause any problems?...

If you run a relatively new Skylake / Kabylake etc., and installed the problematic updated microcodes via 20180108, then yes, you might experience reboots / crashes etc...but older microcodes weren't changed in the first place. If / when a newer microcode gets released for a processor, at any given future moment, assuming Intel messed it up, then sure, all kinds of problems might rise up...hence the reason someone should always be cautious when applying such.

panorain -> see Michael's previous reply in regards to 32-bit systems, as i don't run such, hence i haven't really been paying attention to the current availability of fixes for them:

As of today, Canonical-Ubuntu have only issued Meltdown kernel updates for 64bit Linux, ie not yet for 32bit systems.

I have to assume though that such will come anytime soon...

[michael louwe]

@ panorain, .......

...

.
If nothing is reported for dmesg | grep isolation , it means the kernel has not been patched for Meltdown/KPTI = kernel page table isolation. Otherwise, if patched, it should return ...

[ 0.000000] Kernel/User page tables isolation: enabled
.
.
Alternatively, use grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` && echo "patched" || echo "unpatched"

[panorain]

Output of --> grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` && echo "patched" || echo "unpatched"

This is over and I sincerely hate Intel for abusing people who care about computers. All now are junk I want a decent thing I did not come to MINT for war you pieces of trash being paid 100k a year listen to me right now I am so angry I never mess with you and you mess with me wow now.

Russia is upset now so should Intel's trash hole of an os. < --- Intel is junk Cyrix will start.

4 5 6 7 18 more days on this Linux trash kernel and we find alternatives. Listen UP

JUNK MEN

paul@paul-Compaq-nc6400 ~ $ grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` && echo "patched" || echo "unpatched"
unpatched

Jerk

[smurphos]

Double check...run and report the output

uname -a

then

grep isolation /var/log/syslog or grep isolation /var/log/kern.log

One of your machines is 32bit? I'm pretty sure the new kernels only have PTI enables for 64bit systems as it stands.

[panorain]

uname -a

Code: Select all

uname -a 

paul@Paul-Lenovo-m57p ~ $ uname -a
Linux Paul-Lenovo-m57p 4.4.0-109-generic #132~14.04.1-Ubuntu SMP Tue Jan 9 21:46:42 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

paul@Paul-Lenovo-m57p ~ $ grep isolation /var/log/syslog
Binary file /var/log/syslog matches
paul@Paul-Lenovo-m57p ~ $ grep isolation /var/log/kern.log
Jan 21 08:58:57 Paul-Lenovo-m57p kernel: [ 0.000000] Kernel/User page tables isolation: enabled

SPLIT : to other PC as requested in same topic on prior post.
The output on the Compaq is as follows :

paul@paul-Compaq-nc6400 ~ $ grep isolation /var/log/syslog
paul@paul-Compaq-nc6400 ~ $ grep isolation /var/log/kern.log

1 question why is not response rendered?
The enter button on the keyboard has been pressed / depressed after issuing each of the above command .