Is your kernel vulnerable to MELTDOWN and SPECTRE ?

kazimir · 2018-01-25 09:13:47

Thanks to a recent kernel addition to sysfs[1] it is now possible to know if the kernel is vulnerable to MELTDOWN, SPECTREv1 and SPECTREv2 vulnerabilities.

Here's the command to run in a terminal[2]:

grep . /sys/devices/system/cpu/vulnerabilities/*

On my machine running 4.14.14-1 ck kernel it returns:

/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable: Minimal generic ASM retpoline

Maybe this should be put into the wiki but I could not find an appropriate place.

[1]: [tip:x86/pti] sysfs/cpu: Add vulnerability folder
[2]: Meltdown and Spectre Linux Kernel Status - Update

lo1 · 2018-01-25 10:28:05

Yes, please consider adding it to the wiki as it is much better rather than posting it here. Announce your changes in the talk page before doing so, in case someone would like to disagree/consider improvements.

Security seems the most appropriate wiki page to me.

mcloaked · 2018-01-25 16:21:53

Some mitigation for Spectre V2 is in the current kernel too:

[mike@lenovo2 ~]$ uname -r
4.14.15-1-ARCH
[mike@lenovo2 ~]$ grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline

Hopefully over the coming weeks there will be more code for Spectre V1 that comes with kernel 4.15

The kernel developers have done an amazing job writing code as a matter of urgency once the Meltdown/Spectre vulnerabilities were made public.

Last edited by mcloaked (2018-01-25 16:23:33)

loqs · 2018-01-25 16:53:50

mcloaked wrote:

Some mitigation for Spectre V2 is in the current kernel too

"Full generic retpoline" should be full mitigation unless the CPU is skylake+

mcloaked wrote:

Hopefully over the coming weeks there will be more code for Spectre V1 that comes with kernel 4.15

No https://git.kernel.org/pub/scm/linux/ke … 5-rc9#n272 kernel will report "Not affected" or "Vulnerable" no mitigation to check for.
https://patchwork.kernel.org/patch/10176655/ is the initial framework for variant 1 mitigation's targeted at 4.16 with stable backports in its current form even if it is applied it still reports Vulnerable.

R00KIE · 2018-01-25 17:48:25

Lots of ink will run over this, at least lenovo has retracted a bios update for my laptop which carried an updated microcode and on their security page the availability of a fix is to be defined. Also the matter with IBRS/IBPB/STIBP is contentious, see [1].

You also need patched compilers to get the full protection so there is that also.

[1] https://lwn.net/Articles/745111/

loqs · 2018-01-25 18:00:39

Rookie fortunately arch already has a patched version of gcc and is your system not getting the same microcode update via early update from the kernel?
I was wondering if you had noticed any issues with it as per https://bugs.archlinux.org/task/57067#comment165861

mcloaked · 2018-01-25 19:08:28

loqs wrote:

mcloaked wrote:
Some mitigation for Spectre V2 is in the current kernel too
"Full generic retpoline" should be full mitigation unless the CPU is skylake+
mcloaked wrote:
Hopefully over the coming weeks there will be more code for Spectre V1 that comes with kernel 4.15
No https://git.kernel.org/pub/scm/linux/ke … 5-rc9#n272 kernel will report "Not affected" or "Vulnerable" no mitigation to check for.
https://patchwork.kernel.org/patch/10176655/ is the initial framework for variant 1 mitigation's targeted at 4.16 with stable backports in its current form even if it is applied it still reports Vulnerable.

Thank you for the correction. Does this also mean that for the optimal mitigation for Spectre V1 it will need both microcode update as well as the updated gcc and kernel patches?

R00KIE · 2018-01-25 19:21:46

Yes my system would be receiving the same microcode update via early update, but the bios I'm using already has the same microcode version so the is nothing to update. From what is described here[1] I'd say the kernel will blacklist the current microcode version, in my case 0xc2 for a mobile skylake system.

From what I had seen before only Broadwell and Haswell cpus were affected by the faulty microcode updates but this more recent kernel patch turns that on its head.

The problem is that lenovo had a bios update available with an updated microcode much sooner than intel made available the bundle with updated microcodes. I'm usually quick in updating the bios, more so in this case. Apparently if you update the bios and later revert to an earlier version the microcode updates present in the bios are not reverted, so if the microcode update stated to cause problems then you're stuck until intel releases an update that does not cause problems.

Until now I have not experienced any problems whatsoever, so it seems I just dodged a bullet.

[1] http://lkml.org/lkml/2018/1/24/553

loqs · 2018-01-25 19:24:37

Spectre V1 the patches uses some specially crafted functions to prevent the cpu/compiler from using speculation https://patchwork.kernel.org/patch/10174297/
it requires the kernel developers to locate every vulnerable site though no need for microcode updates or special compiler support.
Spectre V2 as implemented in 4.14.y stable 4.15rc-9 uses the updated gcc for full mitigation for none skylake+ systems, older gcc produces a weaker protection.
4.16 nothing is decided if IBRS/IBPB will be used for skylate+ or some alternative approach that counts call depth.

mcloaked · 2018-01-25 19:41:54

I have a Skylake NUC6i5SYK which had a BIOS update early January to version 0065 including a microcode update that has now been withdrawn. I had no problems with it but I was told that it was Windows that used the ibrs fix where there were reboot problems, but not in arch linux where the mitigation method uses retpoline. For that machine apparently Intel is planning a further BIOS update at the end of January. https://www.intel.co.uk/content/www/uk/ … i-pcs.html

Last edited by mcloaked (2018-01-25 19:43:20)

R00KIE · 2018-01-25 20:04:19

@mcloaked
It seems there is conflicting information, in the page you linked to it says: "If you have already updated BIOS with the first microcode update and you experience reboots or unstable system behavior, you can downgrade your BIOS to the previous version." which seems to imply the microcode will be rolled back if the bios is rolled back.

In the Lenovo security page[1] it says: "Removed issue *1 BIOS/UEFI back-flash recommendation. MCU microcode updates cannot be reversed."

[1] https://support.lenovo.com/pt/en/solutions/len-18282

mcloaked · 2018-01-25 20:26:22

R00KIE wrote:

@mcloaked
It seems there is conflicting information, in the page you linked to it says: "If you have already updated BIOS with the first microcode update and you experience reboots or unstable system behavior, you can downgrade your BIOS to the previous version." which seems to imply the microcode will be rolled back if the bios is rolled back.
In the Lenovo security page[1] it says: "Removed issue *1 BIOS/UEFI back-flash recommendation. MCU microcode updates cannot be reversed."
[1] https://support.lenovo.com/pt/en/solutions/len-18282

Yes in recent times there was always a warning when updating the bios that it cannot be reversed by a "normal" update process (eg the F7 key update (in this case downgrade) method as a security protection). However there is a way to reset the bios from a flash drive, and loading an earlier version on the machine using a different procedure to normal and accept the warnings that this could cause problems ( https://www.intel.co.uk/content/www/uk/ … i-pcs.html )- a feature designed to recover the motherboard if a bios flash goes wrong leaving the system otherwise bricked.

mcloaked · 2018-01-25 20:33:54

The most recent information I can find about microcode versions for Intel processors is at https://newsroom.intel.com/wp-content/u … idance.pdf

I guess that will get updated as new information comes in to Intel.

I have a Haswell series laptop which is now using a microcode version 0x21 which the above document says should not be used but to go back to 0x20 -

$ sudo journalctl -b | egrep microcode
Jan 25 18:46:38 archlinux kernel: microcode: sig=0x40651, pf=0x40, revision=0x21
Jan 25 18:46:38 archlinux kernel: microcode: Microcode Update Driver: v2.2.

However this machine has been working fine with the latest kernel 4.14.15 and microcode 0x21 with no reboot or other problems related to the new mitigations. This version of the microcode was delivered by the most recent Lenovo BIOS update so the early update process when the kernel boots has the same version so there is no early microcode update. If and when a new microcode package is released and has a version later than 0x21 then the machine will use such a more recent version. But until then arch linux runs without issue on that machine (Lenovo s540).

Last edited by mcloaked (2018-01-25 20:41:37)

R00KIE · 2018-01-25 21:51:11

Downgrading the bios is easy I think, if I recall correctly there is an option in the firmware setup of my laptop to block/allow downgrading.

I was referring to the information provided by Lenovo, initially their recommendation was if the update started to cause problems to downgrade the bios, which is the recommendation from Intel, however later they have removed that advice and added to the changelog table the note I have mentioned before.

Like I have said before I haven't noticed anything amiss, but as far as I know linux isn't trying to use the new IBRS & friends instructions yet, maybe that is why. I suppose most of the systems showing problems are windows systems, at least judging by the description of the symptoms.

cirrus9 · 2018-01-27 02:34:26

There is also this vulnerability checker in the AUR, or you can get it from Github: spectre-meltdown-checker

Apparently, Intel isn't going to issue new microcode to patch this on older CPU models like Sandybrige, Ivybridge, etc., and other older CPU's. Older machines, and motherboards not likely to get BIOS/EFI firmware updates either. If it can't be fixed through the kernel, and or browser updates, older systems are just sunk, in my opinion. It's a sad mess...

nomorewindows · 2018-01-28 03:20:23

Odd that speculative execution came along about the same time as the release of Windows 95...did Windows 95 need it to run...well it was much hampered by anything less than a Pentium.

ugjka · 2018-01-28 11:31:35

mcloaked wrote:

...
The kernel developers have done an amazing job writing code as a matter of urgency once the Meltdown/Spectre vulnerabilities were made public.

Fixing cpu bugs is not their favourite job, it should be intel's job

R00KIE · 2018-01-28 12:02:43

nomorewindows wrote:

Odd that speculative execution came along about the same time as the release of Windows 95...did Windows 95 need it to run...well it was much hampered by anything less than a Pentium.

I'm sure it didn't need it but everything benefits greatly if the cpu is capable of speculative execution and gets the speculation right as it hides the latency from having to wait to fetch things from ram.

loqs · 2018-01-29 00:48:39

cirrus9 wrote:

Apparently, Intel isn't going to issue new microcode to patch this on older CPU models like Sandybrige, Ivybridge, etc., and other older CPU's. Older machines, and motherboards not likely to get BIOS/EFI firmware updates either. If it can't be fixed through the kernel, and or browser updates, older systems are just sunk, in my opinion. It's a sad mess...

http://lkml.org/lkml/2018/1/22/598 covers IBPB, STIBP, IBRS and possible uses within the kernel. My understanding is without them the kernel itself is still protected from V2 using retpoline but it does not protect VM's or userspace.
V1 and V3 are not mitigated by IBPB, STIBP, IBRS. http://lkml.org/lkml/2018/1/28/173 notes the state of protection offered by 4.15 in the view of Linus.

andmars · 2018-01-29 10:46:11

Just tested with the latest kernel. Still not completely fixed, yet:

╭─ andreas@andreas-pc ~
╰─$ uname -r
4.15.0-1-ARCH

╭─ andreas@andreas-pc ~
╰─$ cat /sys/devices/system/cpu/vulnerabilities/
meltdown    spectre_v1  spectre_v2

╭─ andreas@andreas-pc ~
╰─$ cat /sys/devices/system/cpu/vulnerabilities/meltdown
Mitigation: PTI

╭─ andreas@andreas-pc ~
╰─$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v1
Vulnerable

╭─ andreas@andreas-pc ~
╰─$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Full generic retpoline

And for those who understand german: https://www.heise.de/ct/artikel/Die-Neu … ml?seite=3

Last edited by andmars (2018-01-29 10:56:38)

Batou · 2018-01-31 00:38:21

andmars wrote:

Just tested with the latest kernel. Still not completely fixed, yet:

On existing CPUs, v1 won't be fixed for a long time. Possibly never. Don't hold your breath for it. The only option is to ditch your defective CPU and get a new one... unfortunately.

My Ivy Bridge i5 shows this:

 
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline

As long as you're not a service provider and you trust local code and use a browser that has disabled SharedArrayBuffer, lowered counter granularity and provides site isolation, you should be fine. Also, run an adblocker, disable JS on sites by default and only enable it for sites that need it.

Just reduce your attack surface in general.

Personally, I'm more worried about loss in performance from all these mitigations than from being exploited.

Last edited by Batou (2018-01-31 00:41:16)

loqs · 2018-01-31 01:01:16

Batou wrote:

On existing CPUs, v1 won't be fixed for a long time. Possibly never. Don't hold your breath for it. The only option is to ditch your defective CPU and get a new one... unfortunately.

For the kernel there will be v1 mitigation see https://patchwork.kernel.org/patch/10191245/ and http://lkml.org/lkml/2018/1/28/173
Userspace seems to be an unknown and if / when CPU's which are not vulnerable to v1 / v2 will be released is another unknown.

Batou · 2018-01-31 01:28:26

loqs wrote:

Batou wrote:
On existing CPUs, v1 won't be fixed for a long time. Possibly never. Don't hold your breath for it. The only option is to ditch your defective CPU and get a new one... unfortunately.
For the kernel there will be v1 mitigation see https://patchwork.kernel.org/patch/10191245/ and http://lkml.org/lkml/2018/1/28/173
Userspace seems to be an unknown and if / when CPU's which are not vulnerable to v1 / v2 will be released is another unknown.

Right. That patch is for kernel only. To mitigate against v1 in userspace, you'd have to completely eliminate branch prediction which would result in an immediate 50+ slowdown of the CPU. That's why it's unrealistic that this will ever happen.

I'm not familiar with what's happening with AMD, since I don't have any of their CPUs, but I'm pretty sure AMD CPUs are also vulnerable to Spectre. From what I've read, there won't be any CPUs that are not vulnerable from Spectre in 2018 from AMD and Intel. Whatever they release this year will still be vulnerable so I wouldn't waste money just yet.

Until we can upgrade to something safe, best defense is to reduce the amount of untrusted code that you run.

loqs · 2018-01-31 08:37:17

Batou wrote:

I'm not familiar with what's happening with AMD, since I don't have any of their CPUs, but I'm pretty sure AMD CPUs are also vulnerable to Spectre. From what I've read, there won't be any CPUs that are not vulnerable from Spectre in 2018 from AMD and Intel. Whatever they release this year will still be vulnerable so I wouldn't waste money just yet.

See here http://lkml.org/lkml/2018/1/21/192 for Linus making the case that from what Intel has disclosed so far implies it may never be fixed and mitigation's will be required on all future CPU's.

Slithery · 2018-01-31 09:34:40

Batou wrote:

From what I've read, there won't be any CPUs that are not vulnerable from Spectre in 2018 from AMD and Intel.

That's not what Intel are saying...
http://bit-tech.net/news/tech/cpus/inte … is-year/1/

Arch Linux

#1 2018-01-25 09:13:47

Is your kernel vulnerable to MELTDOWN and SPECTRE ?

#2 2018-01-25 10:28:05

Re: Is your kernel vulnerable to MELTDOWN and SPECTRE ?

#3 2018-01-25 16:21:53

Re: Is your kernel vulnerable to MELTDOWN and SPECTRE ?

#4 2018-01-25 16:53:50

Re: Is your kernel vulnerable to MELTDOWN and SPECTRE ?

#5 2018-01-25 17:48:25

Re: Is your kernel vulnerable to MELTDOWN and SPECTRE ?

#6 2018-01-25 18:00:39

Re: Is your kernel vulnerable to MELTDOWN and SPECTRE ?

#7 2018-01-25 19:08:28

Re: Is your kernel vulnerable to MELTDOWN and SPECTRE ?

#8 2018-01-25 19:21:46

Re: Is your kernel vulnerable to MELTDOWN and SPECTRE ?

#9 2018-01-25 19:24:37

Re: Is your kernel vulnerable to MELTDOWN and SPECTRE ?

#10 2018-01-25 19:41:54

Re: Is your kernel vulnerable to MELTDOWN and SPECTRE ?

#11 2018-01-25 20:04:19

Re: Is your kernel vulnerable to MELTDOWN and SPECTRE ?

#12 2018-01-25 20:26:22

Re: Is your kernel vulnerable to MELTDOWN and SPECTRE ?

#13 2018-01-25 20:33:54

Re: Is your kernel vulnerable to MELTDOWN and SPECTRE ?

#14 2018-01-25 21:51:11

Re: Is your kernel vulnerable to MELTDOWN and SPECTRE ?

#15 2018-01-27 02:34:26

Re: Is your kernel vulnerable to MELTDOWN and SPECTRE ?

#16 2018-01-28 03:20:23

Re: Is your kernel vulnerable to MELTDOWN and SPECTRE ?

#17 2018-01-28 11:31:35

Re: Is your kernel vulnerable to MELTDOWN and SPECTRE ?

#18 2018-01-28 12:02:43

Re: Is your kernel vulnerable to MELTDOWN and SPECTRE ?

#19 2018-01-29 00:48:39

Re: Is your kernel vulnerable to MELTDOWN and SPECTRE ?

#20 2018-01-29 10:46:11

Re: Is your kernel vulnerable to MELTDOWN and SPECTRE ?

#21 2018-01-31 00:38:21

Re: Is your kernel vulnerable to MELTDOWN and SPECTRE ?

#22 2018-01-31 01:01:16

Re: Is your kernel vulnerable to MELTDOWN and SPECTRE ?

#23 2018-01-31 01:28:26

Re: Is your kernel vulnerable to MELTDOWN and SPECTRE ?

#24 2018-01-31 08:37:17

Re: Is your kernel vulnerable to MELTDOWN and SPECTRE ?

#25 2018-01-31 09:34:40

Re: Is your kernel vulnerable to MELTDOWN and SPECTRE ?

Board footer