ATTN!...Intel CPU owners (Spectre,Meltdown,Foreshadow, flaws)

[BigEasy]

Not sure about aliases. I copied/pasted from here straight into terminal, no sudo or anything extra, so am not sure why it won't respond to some commands.

There is 2 possibilites:
1. binary file with name dmesg is not single in your system
2. wrong alias.

So:
type

Code: Select all

whereis dmesg

and we will see how many different dmesg installed in your system (and where).

then type

Code: Select all

alias

here we will see your aliases.

[ArtGirl]

There is 2 possibilites:
1. binary file with name dmesg is not single in your system
2. wrong alias.

So:
type

Code: Select all

whereis dmesg

and we will see how many different dmesg installed in your system (and where).

then type

Code: Select all

alias

here we will see your aliases.

Thanks BigEasy

Code: Select all

whereis dmesg
dmesg: /bin/dmesg /usr/share/man/man1/dmesg.1.gz

and

Code: Select all

alias
alias alert='notify-send --urgency=low -i "$([ $? = 0 ] && echo terminal || echo error)" "$(history|tail -n1|sed -e '\''s/^\s*[0-9]\+\s*//;s/[;&|]\s*alert$//'\'')"'
alias egrep='egrep --color=auto'
alias fgrep='fgrep --color=auto'
alias grep='grep --color=auto'
alias l='ls -CF'
alias la='ls -A'
alias ll='ls -alF'
alias ls='ls --color=auto'

[chrisuk]

OK, if this thread will be used as a reference, I'd better give a bit more info on what that line of code I pasted actually confirms:

It only confirms that your active Kernel is capable of page table isolation - it doesn't tell you whether it was disabled at boot (I'm assuming Mint/Ubuntu haven't disabled it). To check for that you can type either of the following:

sudo grep isolation /var/log/kern.log

or

sudo grep isolation /var/log/messages

Either one should return a list of boot message lines, such as this

Jan 21 05:43:17 mx1 kernel: [ 0.000000] Kernel/User page tables isolation: enabled

that tells me that KPTI was enabled at boot this morning.

(That "mx1" is because I'm running MX Linux )

I'm in a rush, but I'm sure someone will correct if any errors in my post

[BigEasy]

Thanks BigEasy

OK! Good thing is your outputs seems completely OK.
Bad thing - I still see no reason why simple "dmesg" is not working for you It is not big deal but interesting.

[ArtGirl]

Thanks chrisuk Same result as yours.

[ArtGirl]

Thanks BigEasy

OK! Good thing is your outputs seems completely OK.
Bad thing - I still see no reason why simple "dmesg" is not working for you It is not big deal but interesting.

Sorry, I hadn't tried 'dmesg' on it's own ... it's working okay. The weirder thing is that I've gone back a few posts and re-tried all the suggested commands, and they're all now working (same copy/paste). Twilight zone time, lol.

[BigEasy]

OK! You proved my sentence "there is no mysteries"

[ArtGirl]

OK! You proved my sentence "there is no mysteries"

Great that they ended up all working, yes!

[Pjotr]

Because of Meltdown/Spectre, I had to downgrade the driver for my Nvidia video card to the open source nouveau driver:


....which was rather a bummer.
Anybody seen any sign somewhere, that Nvidia will fix the nvidia-340 as well (and not only the nvidia-384.111 and higher)?

[Arch_Enemy]

Because of Meltdown/Spectre, I had to downgrade the driver for my Nvidia video card to the open source nouveau driver:


....which was rather a bummer.
Anybody seen any sign somewhere, that Nvidia will fix the nvidia-340 as well (and not only the nvidia-384.111 and higher)?

I do not get the Intel Microcode as a driver in my driver manager. Something is not right, I knew it was there before...

[smurphos]

sudo grep isolation /var/log/kern.log
or
sudo grep isolation /var/log/messages

grep isolation /var/log/kern.log with no sudo works as does grep isolation /var/log/syslog

For microcode enquiries

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

There is no /var/log/messages on Mint 18.3.....

Using dmesg is unreliable for me as-well.

[chrisuk]

sudo grep isolation /var/log/kern.log
or
sudo grep isolation /var/log/messages

grep isolation /var/log/kern.log with no sudo works as does grep isolation /var/log/syslog

For microcode enquiries

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

There is no /var/log/messages on Mint 18.3.....

Using dmesg is unreliable for me as-well.

Thanks for the Mint specific correction - I was trying to cover other distros that will give a grep: /var/log/kern.log: Permission denied without admin rights. (I added that I was on MX Linux at the bottom of my post)

Oh, dmesg -T | grep isolation will only work if you (re)booted recently

[michael louwe]

From Artgirl's recent microcode post at Newbie Questions, I have checked Synaptic PM, LM 17.3 = just got a new Intel microcode update. It reverts 20180108 to 20170707. The Changelog ...

intel-microcode (3.20180108.0+really20170707ubuntu14.04.1) trusty-security; urgency=medium

* Revert to 20170707 version of microcode because of regressions on
certain hardware. (LP: #1742933)

-- Marc Deslauriers <marc.deslauriers@ubuntu.com> Mon, 22 Jan 2018 07:21:24 -0500

This means those microcode updates dated after 07/07/2017 should contain the patch for Spectre 2. Does this mean Intel will remove those problematic microcode updates before releasing a new non-buggy update.?

[thx-1138]

https://newsroom.intel.com/news/root-ca ... -partners/

This means those microcode updates dated after 07/07/2017 should contain the patch for Spectre 2.

Not necessary (although most likely yes) - note that there was an intermediate release of 20171117 (for which nothing was reported for approx 2 months - but maybe that's because no-one suspected such at the time)...

[ArtGirl]

From Artgirl's recent microcode post at Newbie Questions, I have checked Synaptic PM, LM 17.3 = just got a new Intel microcode update. It reverts 20180108 to 20170707.
This means those microcode updates dated after 07/07/2017 should contain the patch for Spectre 2. Does this mean Intel will remove those problematic microcode updates before releasing a new non-buggy update.?

Not sure, but can certainly understand the doubt towards Intel. They should have been responsible and announced it unavailable just before releasing this one.
There's an openssh update come through too, but am unsure if this is to do with spectre. Applying the 'not broken, don't fix' about microcode, as it must contain the same meltdown fix; great that people with (risk of) borked systems can update.

[thx-1138]

...of whatever use it might be, i came up with an added and/or modified changelog of sorts between 20180108 - 20171117 - 20170707.
Ie. it includes what is supposed to be the potentially 'suspect' ones (microcodes which were identical since 20170707 or completely removed aren't included) =>
https://pastebin.com/raw/tTwdW5b8

...in addition => https://newsroom.intel.com/wp-content/u ... idance.pdf

[Harfud]

Oh dear, this doesn't look very promising....

I laughed from start to finish while reading it though.

https://lkml.org/lkml/2018/1/21/192

[stereo555]

https://www.computerworld.com/article/3 ... fixes.html

[michael louwe]

https://wiki.ubuntu.com/SecurityTeam/Kn ... ndMeltdown

2018 Jan 22: Kernel updates containing CVE-2017-5753 (Spectre variant 1) and CVE-2017-5715 (Spectre variant 2) mitigations for i386, amd64, ppc64el, and s390x are published

Note: The Ubuntu kernels for the i386 architecture do not include CVE-2017-5715 (Spectre variant 2) mitigations

Note: The Ubuntu 14.04 LTS kernel, based on kernel version 3.13, does not include CVE-2017-5753 or CVE-2017-5715 (Spectre) mitigations for ppc64el

Note: Support for retpoline is not yet included in these kernel updates

These should be kernel updates for 3.13.141, 4.4.112 and 4.13.31.

[thx-1138]

...i cross-checked the intel-microcode packages 'additions / modifications' changelog that i came up yesterday (via iucode_tool -L and some diff-ing), with Intel's own Revision Guidance, and here are my eventual results:
https://pastebin.com/raw/xRWrsVZR

This should make it quite easy to draw more precise conclusions as to what got messed up, when, with which package (2011117 or 20180108) & in what processor.
Quite interesting is the fact that, at least at first glance, Kabylake doesn't really appear to have received any faulty microcodes via the packages that were withdrawn from the repos: looks more likely that such were supplied instead to vendors & deployed via BIOS updates...
Note however that there exist a few ones that have absolutely no mention in Intel's Guidance - your guess is as good as anyone else's about them.

Self-correction (after double-checking): Kabylake did receive faulty microcode updates, but only via the latest 20180108, and not via 20111117.