Meltdown - Intel CPU design flaw affecting all OS platforms

martix · 2018-01-14 13:11:47

twoion wrote:

Updated my x240 ThinkPad's BIOS for the Intel microcode update addressing CVE-2017-5715. ... A disaster for Intel. Starting to look for a refurbished skylake or KabyLake ThinkPad x250/x260

I see the point (getting a faster hardware), but it'll be still full of Intel proprietary junk. An other way would be downgrading and getting an X230, flashing Coreboot and being careful about physical access to the machine (as the exploitation of those recently discovered vulnerabilites (also the atm one) require physical access).

Last edited by martix (2018-01-14 13:51:18)

Head_on_a_Stick · 2018-01-14 16:33:26

Worrying news on the Alpine Linux mailing lists about the fix that has been applied to the 4.9-series kernels (as found in Debian stretch):

William Pitcock wrote:

[...] there were serious reliability patches with these "backports", largely because in reality the mitigation "backported" was actually a derivative of an earlier mitigation called KAISER. We have observed that KAISER had major reliability issues in private testing of the new kernels.
Natanael recently pushed 4.9.76 linux-vanilla kernel to edge for public testing and that also verified that there were still regressions in the release that was supposed to fix the regressions in 4.9.75. Accordingly, we are lead to believe that the situation is not likely to get better with trying to fix KAISER any time soon. In addition, it was posted to Hacker News that KAISER has severe design defects that neither the real KPTI or unpatched kernels have[1].
[...]
[1] https://news.ycombinator.com/item?id=16087736

http://lists.alpinelinux.org/alpine-devel/6022.html

This is exceptionally bad for BL-He (if true).

EDIT: a case for switching to the Liquorix kernel, perhaps?

https://liquorix.net/

Last edited by Head_on_a_Stick (2018-01-14 16:38:10)

stevep · 2018-01-15 00:31:46

Well, the standard Liquorix kernel headers require gcc-7, but one could use my backported versions in the OBS...jeesh, another new one today? It's every other day now. OK, I'll add that.

https://techpatterns.com/forums/about2615.html

Not to mention that most third-party drivers like broadcom-sta need updates or patches to build on the new kernels. I have some in my repo for Jessie...I'll see if they are up to date.

Last edited by stevep (2018-01-15 00:54:24)

ohnonot · 2018-01-15 06:51:41

Head_on_a_Stick wrote:

Bruce Schneier's blog has a nice article about Meltdown/Spectre:
https://www.schneier.com/blog/archives/ … mel_1.html

thanks again.
maybe i should make it a habit to visit his blog regularly.

I presume you aren't hosting a cloud server running lots of Docker containers for other people in your kitchen, right?

no, of course not.
all in all, no reason to panic for this setup.
just don't use wordpress

Head_on_a_Stick · 2018-01-15 07:07:39

stevep wrote:

the standard Liquorix kernel headers require gcc-7

Drat, I forgot about that...

Scratch that plan then.

jr2 · 2018-01-15 23:02:40

Head_on_a_Stick wrote:

Worrying news on the Alpine Linux mailing lists about the fix that has been applied to the 4.9-series kernels (as found in Debian stretch):
William Pitcock wrote:
[...] there were serious reliability patches with these "backports", largely because in reality the mitigation "backported" was actually a derivative of an earlier mitigation called KAISER. We have observed that KAISER had major reliability issues in private testing of the new kernels.
Natanael recently pushed 4.9.76 linux-vanilla kernel to edge for public testing and that also verified that there were still regressions in the release that was supposed to fix the regressions in 4.9.75. Accordingly, we are lead to believe that the situation is not likely to get better with trying to fix KAISER any time soon. In addition, it was posted to Hacker News that KAISER has severe design defects that neither the real KPTI or unpatched kernels have[1].
[...]
[1] https://news.ycombinator.com/item?id=16087736
http://lists.alpinelinux.org/alpine-devel/6022.html
This is exceptionally bad for BL-He (if true).
EDIT: a case for switching to the Liquorix kernel, perhaps?
https://liquorix.net/

Hard to believe Debian would allow such a dire situation to continue for long - by the time Helium's out it'll probably be fixed.

Head_on_a_Stick · 2018-01-16 06:45:59

jr2 wrote:

by the time Helium's out it'll probably be fixed

The kernels for wheezy, jessie and stretch are all marked as "fixed" for Meltdown[1] so as far as Debian are concerned the KAISER patch offers sufficient protection despite the fact that it was deemed unworthy enough to warrant a complete re-write (into KPTI) for the upstream fix.

I don't think we really have any choice but to accept that but I am not happy about the situation.

[1] https://security-tracker.debian.org/tra … -2017-5754

ohnonot · 2018-01-16 06:51:03

^ i think i read somewhere that kernel dev's are aware that this is just a sticky-tape solution, and are still looking for better ways?
with intel contributing code to the kernel, my guess is that they themselves have an intrest in a satisfactory solution?

Head_on_a_Stick · 2018-01-16 06:58:44

I know that Intel released a set of microcode updates on 2018-01-08 (my OpenBSD box keeps loading it onto my CPU) that should also fix things.

That version is in sid but not stable and I have no idea how Debian are handling that because the firmware is in the non-free repositories and so not technically part of the official release.

unklar · 2018-01-16 09:41:12

I have no idea...
truing me as a yardstick for sid thereafter

uname -a
Linux siduction 4.14.13-towo.2-siduction-amd64 #1 SMP PREEMPT siduction 4.14-24 (2018-01-15) x86_64 GNU/Linux

dmesg | grep microcode
[    0.688316] microcode: sig=0x1067a, pf=0x80, revision=0xa07
[    0.688357] microcode: Microcode Update Driver: v2.2.

cat /proc/cpuinfo | grep -m 1 bugs
bugs		: cpu_meltdown spectre_v1 spectre_v2

Quelle

Head_on_a_Stick · 2018-01-16 19:11:15

unklar wrote:

truing me as a yardstick for sid thereafter

Thanks unklar!

Here's my output from OpenBSD (with the new microcode applied):

Puffy:~$ dmesg | grep microcode
cpu_ucode_intel_apply: microcode updated cpu 0 rev 0x2->0x4 (6282013)
cpu_ucode_intel_apply: microcode updated cpu 2 rev 0x2->0x4 (6282013)
Puffy:~$

I have no idea how to interpret this output

I will post back later with output from my Arch box.

Intel's microcode page offers downloads for Debian "7.x" & "8.x":

https://downloadcenter.intel.com/downlo … -Data-File

According to that page:

this file will be used by the operating system mechanism if the file is placed in the /etc/firmware directory of the Linux system

Another alternative would be the Arch Linux intel-ucode package, this contains a custom initramfs image that will apply the microcode — just untar the package, copy the intel-ucode.img to /boot and add it before Debian's initrd on the "initrd" line (in /etc/grub.d/40_custom).

Head_on_a_Stick · 2018-01-16 21:28:44

Just booted Alpine Linux with Arch's intel-ucode.img first on the initrd line in GRUB and I now get this:

alpine:~$ sudo dmesg | grep microcode
[    0.538900] microcode: sig=0x20655, pf=0x10, revision=0x2
[    0.538971] microcode: Microcode Update Driver: v2.2.
alpine:~$

And:

alpine:~$ grep -m1 bugs /proc/cpuinfo
bugs		: cpu_meltdown
alpine:~$

I have KPTI enabled though, which is good.

stevep · 2018-01-16 21:47:31

The newer microcode makes one of the Spectre "NO" results for my Skylake processor turn to YES with that Meltdown-Spectre script; the one about microcode. It seems that LFENCE that it complains about not having enough of in the kernel is a processor command to disable any speculation, and having those in the kernel code would really slow things down. Steve Gibson on Security Now said that a better approach overall may be using pcid, which Intel processors have supported for the last decade, but the kernel hasn't implemented support for yet--though I think the Debian patches mentioned pcid for some reason.

You can always use my backported Liquorix kernels + headers on Jessie...that's why I build them on the OBS, after all.

Last edited by stevep (2018-01-16 22:17:26)

Head_on_a_Stick · 2018-01-16 21:52:03

stevep wrote:

You can always use my backported Liquorix kernels + headers on Jessie...that's why I build them on the OBS, after all.

Thanks Steve, I may well do that 8)

@Community: could this be an option for BunsenLabs?

If not with the stock release then perhaps as something for bl-welcome to offer?

stevep · 2018-01-16 22:30:14

Head_on_a_Stick wrote:

stevep wrote:
You can always use my backported Liquorix kernels + headers on Jessie...that's why I build them on the OBS, after all.
Thanks Steve, I may well do that 8)
@Community: could this be an option for BunsenLabs?
If not with the stock release then perhaps as something for bl-welcome to offer?

I don't know if anyone wants to maintain builds in the BL repo, the 64-bit takes about an hour to build on my i5-6200u and the 32-bit twice as long since it builds a PAE and non_PAE version...that's for the MX Linux versions. And new releases have been coming out every few days. The OBS versions just require me to generate new debian and .dsc files and upload them.

Head_on_a_Stick · 2018-01-16 22:42:34

stevep wrote:

new releases have been coming out every few days

Yes, that's a good point — I use the Liquorix kernel for my live image and it's hard work keeping it current.

jr2 · 2018-01-17 04:20:05

This seems all very fluid atm. Time to keep calm, have a cup of tea...

o9000 · 2018-01-17 06:11:01

So all these years, Intel CPUs were faster than AMD mostly because they were skipping security checks in the speculative execution pipeline?

https://www.amd.com/en/corporate/speculative-execution

AMD is not affected by Meltdown.

Head_on_a_Stick · 2018-01-17 06:34:04

o9000 wrote:

AMD is not claim they are not affected by Meltdown.

Fixed that for you

I apply this kernel parameter on my AMD laptop:

pti=on

The users have complained of some slowdown but I don't care O:)

o9000 · 2018-01-17 07:08:25

Any reason to say that, or just FUDing?

#61 2018-01-14 13:11:47

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#62 2018-01-14 16:33:26

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#63 2018-01-15 00:31:46

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#64 2018-01-15 06:51:41

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#65 2018-01-15 07:07:39

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#66 2018-01-15 23:02:40

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#67 2018-01-16 06:45:59

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#68 2018-01-16 06:51:03

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#69 2018-01-16 06:58:44

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#70 2018-01-16 09:41:12

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#71 2018-01-16 19:11:15

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#72 2018-01-16 21:28:44

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#73 2018-01-16 21:47:31

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#74 2018-01-16 21:52:03

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#75 2018-01-16 22:30:14

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#76 2018-01-16 22:42:34

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#77 2018-01-17 04:20:05

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#78 2018-01-17 06:11:01

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#79 2018-01-17 06:34:04

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#80 2018-01-17 07:08:25

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

Board footer