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:

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.

Pjotr wrote: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...

I have travelled 35629424162.9 miles in my lifetime

One thing I would suggest, create a partition a ~28G partition as /. Partition the rest as /Home.
When the system fails, reinstall and use the exact same username and all your 'stuff' comes back to you.

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

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

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

michael louwe wrote: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.

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

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