Meltdown/Spectre: Unauthorized Disclosure of Kernel Memory

[tholin]

That will be another

Code: Select all

emerge -e @world

when the new gcc is out.

Will it? or will it just be the kernel? I would have thought it would just be the kernel that needs to be rebuild with the new speculative branching mitigation (ie poisoning it)

Here is the way I see it, and I could be totally wrong. The information is spread over a lot of sites and patches.

To mitigate variant 2 you need to either recompile everything without indirect branches (retpolines solution) or update your kernel so it will flush the branch predictor on each context switch. Branch predictor flushing requires updated microcode. The needed microcode might be released but the upstream kernel support is not ready yet. Redhat and possible other vendors have rushed out patches already.

Retpolines doesn't work on recent intel cpus like Skylake so the only solution there is microcode. Intel said they released microcode update for cpus released within the last 5 year but what about older cpus? Unless there is a microcode update the only solution is retpolines afaik. Unfortunately rebuilding everything really means everything including the UEFI code. An attacker could play around with the branch predictor and then do something that causes UEFI to run. Since UEFI has access to all memory that could still leak everything.

Booting in legacy mode does not prevent UEFI from running but it might make it more difficult for an attacker to selectively run UEFI code. I'm not sure about that. Something else I'm not sure about is if the operating system can always guarantee that the branch predictor will be flushed before firmware code is run. When the operating system makes UEFI calls it can flush the branch predictor before but UEFI can also run because of obscure hardware interrupts. In that case you would need an update to the bios, not just microcode.

In any case the variant 2 is difficult to exploit. The attacker needs know the layout and some content of the address space it wants to attack. As gentoo users we are lucky because the code we run is mostly unique to our systems. The firmware code is something an attacker could easily get from the vendors website but the attacker would have to create a separate exploit for each mobo/bios version combo. That's a lot of work so I don't think most home users have a lot to fear from variant 2 if the retpolines workaround is used alone. In the future the attack might be improved so I can't tell how long this will be true.

[PrSo]

I wonder if that's a side effect of Gentoo kernels not compiling in thousands of useless drivers. Maybe we're fine there.

Please correct me if I am wrong, but with assumption that the kernel is crafted to my needs, and in accordance to:

- that the alternative to "legit retpoline" and "IBRS" on AMD cpu - "lfence" solution could be used:
https://lkml.org/lkml/2018/1/4/742;

- and migration in MSR was not fully implemented yet:
https://patchwork.kernel.org/patch/10146709/;

- PoC executed on my netbook says that its vulnerable to Spectre:
https://github.com/Eugnis/spectre-attack

in this perspective I think that we are not save yet but I wish I was wrong.

My intel NAS is another story touhg...



EDIT:

Above applies to spectre v2.

I have problems with LKML.org and could not read treads earlier.

There is a hot discussion about not to rely on "lfence" solution in resolving Spectre v1 problem on AMD cpu cause of slowdown impact.

https://www.spinics.net/lists/netdev/msg476433.html

I am starting to worry about performance downgrade.

[Tony0945]

It gets worse. Trust Wintel to take advantage:
It gets worse: Microsoft’s Spectre-fixer bricks some AMD PCs

[tholin]

latest microcode will be mark stable in a few, you can get it there if you don't want wait :
https://gitweb.gentoo.org/repo/gentoo.g ... 80a1a31b5e

Thats not new enough. That is Intels microcode from nov 2017... they have not made avail microcode for spectre ( well maybe to vendors for BIOS updates)

Let's try checking that.
https://www.mail-archive.com/linux-kern ... 78797.html

Assuming what is reported here is correct then "cpuid ax=0x7, return rdx bit 26 to indicate presence of this feature
IA32_SPEC_CTRL ... { X86_FEATURE_SPEC_CTRL, CPUID_EDX, 26, 0x00000007, 0 }"

sys-apps/cpuid can be used to read the cpuid.

Code: Select all

$ dmesg |grep -m 1 microcode
microcode: CPU0 microcode updated early to revision 0x22, date = 2017-01-27
$ cpuid -1r
...
0x00000007 0x00: eax=0x00000000 ebx=0x000027ab ecx=0x00000000 edx=0x00000000
...

So EDX is all zero and the needed feature is not in this microcode. Lets try the new version.

Code: Select all

$ dmesg |grep -m 1 microcode
microcode: CPU0 microcode updated early to revision 0x23, date = 2017-11-20
$ cpuid -1r
...
   0x00000007 0x00: eax=0x00000000 ebx=0x000027ab ecx=0x00000000 edx=0x0c000000
...

EDX is now 0x0c000000 with bit 26 set so the microcode from November appears to have the needed feature at least on my i7-4790K Haswell.

[EasterParade]

Code: Select all

./spectre-meltdown-checker.sh 
Spectre and Meltdown mitigation detection tool v0.13

Checking vulnerabilities against Linux 4.14.11-gentoo-r2 #2 SMP Sun Jan 7 10:09:37 CET 2018 x86_64

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Kernel compiled with LFENCE opcode inserted at the proper places:  NO  (only 27 opcodes found, should be >= 70)
> STATUS:  VULNERABLE 

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  NO 
*   Kernel support for IBRS:  NO 
*   IBRS enabled for Kernel space:  NO 
*   IBRS enabled for User space:  NO 
* Mitigation 2
*   Kernel compiled with retpolines:  NO 
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpolines are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  YES 
* PTI enabled and active:  YES 
> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)

Uh-Hu

[Thistled]

I'm really confused here, because although Intel say they no longer support my CPU, they are still offering a microcode update from late 2017,
and yet even after applying the update via Portage, I am still on a 2010 microcode update.
??
Intel® Pentium® Processor E5400 (2M Cache, 2.70 GHz, 800 MHz FSB) is in the list.

[albright]

I have three intel computers running gentoo with
these cpus:

i7-6700
i5-4300U
i7-6600U

the latter two are thinkpads

Loading the new intel microcode worked on the thinkpads:

for the 4300U:

Code: Select all

dmesg | grep microco
[    0.000000] microcode: microcode updated early to revision 0x21, date = 2017-11-20
[    0.204333] microcode: sig=0x40651, pf=0x40, revision=0x21

for the 6700U:

Code: Select all

dmesg | grep microco
[    0.000000] microcode: microcode updated early to revision 0xc2, date = 2017-11-16
[    0.262780] microcode: sig=0x406e3, pf=0x80, revision=0xc2

these two both show:

Code: Select all

cpuid -1r:
edx=0x0c000000 

But the 6700 does not seem to take the update:

Code: Select all

grep microco dmesg
[    0.000000] microcode: microcode updated early to revision 0xba, date = 2017-04-09
[    0.324397] microcode: sig=0x506e3, pf=0x2, revision=0xba

and here:

Code: Select all

cpuid -1r:
edx=0x00000000

Is there something about this chip - it did not get upated microcode, or what?

EDIT: I should add, all running kernel 4.14.12

[Thistled]

It seems they will be rolling out in batches all the microcode updates.
Seems applicable to all CPUs manufactured in the last 5 years.
The i7-6700 was produced in Q3-2015 so you will get the update sooner or later.
Just today there is another update to the microcode in Portage.
Suppose you just have to keep an eye out for it.

[krinn]

But the 6700 does not seem to take the update:

Code: Select all

grep microco dmesg
[    0.000000] microcode: microcode updated early to revision 0xba, date = 2017-04-09
[    0.324397] microcode: sig=0x506e3, pf=0x2, revision=[color=red]0xba[/color]

and here:

Is there something about this chip - it did not get upated microcode, or what?

Look again more: https://wiki.gentoo.org/wiki/Project:Se ... nd_Spectre

Skylake H/S 000506E3 0xc2

So it mean you use correct microcode for the two other, but as the link show you, the correct one should be 0xc2. Forget to emerge latest one?

[albright]

eix -I intel-microcode
sys-firmware/intel-microcode
Available versions: 20140430 (~)20140624 (~)20140913 20150121 (~)20150121-r1 20151106 (~)20160607 (~)20160714 20161104 20170511 20170707 (~)20171117 20171117_p20171215 20171117_p20171215-r1 {initramfs monolithic +split-ucode}
Installed versions: 20171117_p20171215-r1(08:36:10 AM 01/08/2018)(split-ucode -initramfs)
Homepage: http://inertiawar.com/microcode/ https://downloadcenter.intel.com/Detail ... ldID=27337
Description: Intel IA32/IA64 microcode update data

looks like the latest to me ... (I could try the initrd route I guess ...)

[krinn]

albright: you are right, the wiki page seems incorrect with 0xc2

Code: Select all

iucode_tool  -l /lib/firmware/intel-ucode/* | grep 506e3
  066/001: sig 0x000506e3, pf_mask 0x36, 2017-04-09, rev 0x00ba, size 98304

[eccerr0r]

BTW, in case it's not clear, x86 32-bit currently has no fix. Upgrading to 4.14.12 will not protect from meltdown.

There was a comment about the "4GB/4GB memsplit" doing something to mitigate, alluded to in a twitter comment. I also wonder if PAE does the 4GB/4GB split due to the nature of what is entailed getting PAE to work...

Due to instruction lack (clflush) of the old cpus, it may be harder to exploit this bug. If you have SSE2, then you're still on the hook.

I suspect for those who are running 32-bit and have:

486, p5, p5mmx, atom N-series ... probably safe, carry on
ppro; p2; p3 ... continue the course, harder to exploit due to missing instructions for cache timing exploitation (see if you can run PAE if not already doing so)
p-m (banias, dothan) ... worry more (problems with PAE, might be SOL)
p4 (willamette, northwood)... worry more due to deep pipes (try running PAE)
p4 (prescott)... try to migrate to 64-bit if you can, else try running PAE
Core solo, core duo... try to migrate to 64-bit
atom D,Z-series (silvermont)... Try to migrate to 64-bit!

I don't know if it's valid to run 32-in-64... that would be another interesting situation...

[fedeliallalinea]

albright: you are right, the wiki page seems incorrect with 0xc2

Code: Select all

iucode_tool  -l /lib/firmware/intel-ucode/* | grep 506e3
  066/001: sig 0x000506e3, pf_mask 0x36, 2017-04-09, rev 0x00ba, size 98304

I don't understand anymore, my Ivybridge (306e4) must be revision 0x42a from wiki page but

Code: Select all

iucode_tool  -l /lib/firmware/intel-ucode/* | grep 306e4
  051/001: sig 0x000306e4, pf_mask 0xed, 2014-05-29, rev 0x0428, size 13312

with latest microcode 20171117_p20171215-r1

[eccerr0r]

Allright, I think I found more information about the 4GB/4GB split.

Apparently, unfortunately, the current incarnation of PAE does not have the so-called 4GB/4GB split. This patch was suggested to kernel devs but not integrated. The patch was introduced during the 2.5.X series and jettisoned before it made it into the kernel.

It completely maps out kernel space so that user programs can access the whole 4GB of address space, so your programs can fully use 4GB of RAM per process instead of running out of RAM at 3GB per process. This has the side effect of preventing Meltdown.

So... 32-bit continues to be vulnerable with no solutions as of now, unless you happen to still use the experimental 4G/4G patch on an ancient kernel.

[krinn]

I don't understand anymore, my Ivybridge (306e4) must be revision 0x42a from wiki page but

Code: Select all

iucode_tool  -l /lib/firmware/intel-ucode/* | grep 306e4
  051/001: sig 0x000306e4, pf_mask 0xed, 2014-05-29, rev 0x0428, size 13312

with latest microcode 20171117_p20171215-r1

intel latest provide microcode is https://downloadcenter.intel.com/downlo ... uct=122139
Which is the "already" too old file that is use by 20171117_p20171215.
20171117_p20171215 -r1 have some microcode update, and that file comes from debian that took it from redhat.

You can see that file has "some update", here's the list from https://bugs.debian.org/cgi-bin/bugrepo ... bug=886367

Code: Select all

     + Updated Microcodes:
       sig 0x000306c3, pf_mask 0x32, 2017-11-20, rev 0x0023, size 23552
       sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size 18432
       sig 0x000306f2, pf_mask 0x6f, 2017-11-17, rev 0x003b, size 33792
       sig 0x00040651, pf_mask 0x72, 2017-11-20, rev 0x0021, size 22528
       sig 0x000406e3, pf_mask 0xc0, 2017-11-16, rev 0x00c2, size 99328
       sig 0x000406f1, pf_mask 0xef, 2017-11-18, rev 0xb000025, size 27648
       sig 0x00050654, pf_mask 0xb7, 2017-11-21, rev 0x200003a, size 27648
       sig 0x000506c9, pf_mask 0x03, 2017-11-22, rev 0x002e, size 16384
       sig 0x000806e9, pf_mask 0xc0, 2017-12-03, rev 0x007c, size 98304
       sig 0x000906e9, pf_mask 0x2a, 2017-12-03, rev 0x007c, size 98304

As you see, no update for 306e4 cpu, so i suppose the version gentoo speak in the wiki, is a not yet release version that will have the fix.

So for now, if your cpu is in that list, you have an update.

[fedeliallalinea]

As you see, no update for 306e4 cpu, so i suppose the version gentoo speak in the wiki, is a not yet release version that will have the fix.

So for now, if your cpu is in that list, you have an update.

Thank you krinn, now is clear!

[The Main Man]

I'm really confused here, because although Intel say they no longer support my CPU, they are still offering a microcode update from late 2017,
and yet even after applying the update via Portage, I am still on a 2010 microcode update.
??
Intel® Pentium® Processor E5400 (2M Cache, 2.70 GHz, 800 MHz FSB) is in the list.

I think that's because they just say here's the latest archive for download with all cpu's microcode files inside, your cpu is on the list (like any that has microcode produced ever) but it doesn't matter that the date is 2017, for your cpu the microcode file date is 2010, they just pack all microcode files inside no matter if only one file was actually updated in that archive.
That's how I see it, could be wrong though.

[Myu]

So looking at this page, there's no microcode update for Sandy Bridge ? Thanks Intel ...

[Thistled]

Forgive me for the conspiracy theory, but by Intel refusing to update microcode for older CPU's, and as a result forcing the user
to update to a newer CPU, is this not worthy of what Americans call a class action lawsuit?
Why should I be forced to buy a newer more expensive CPU when the current one I am using is fine and doing a great job? Albeit vulnerable
due to its age. Which could surely be mitigated by UPDATING the microcode?
Or am I missing something here, such as the age of the CPU means I DO have some level of mitigation?
This is a mess. Especially when the intel site states my CPU is covered by the latest microcode update. It clearly isn't.
I do know however that the TSX instruction set is not available in my CPU, so maybe Wolfdales are OK?

[Myu]

Forgive me for the conspiracy theory, but by Intel refusing to update microcode for older CPU's, and as a result forcing the user
to update to a newer CPU, is this not worthy of what Americans call a class action lawsuit?

Could be, not in the US anyway but I'll be voting with my wallet if I need to purchase a new CPU and it's gonna be AMD.

Why should I be forced to buy a newer more expensive CPU when the current one I am using is fine and doing a great job? Albeit vulnerable
due to its age. Which could surely be mitigated by UPDATING the microcode?

I'm still holding up but like you, I would be really disappointed if there's no microcode update for older CPU's, my CPU is doing FINE, my OS of choice is already patched against meltdown, AFAIK all I need is the Microcode by now (and some other mitigations from GCC8/LLVM and other programs)

[PrSo]

So looking at this page, there's no microcode update for Sandy Bridge ? Thanks Intel ...

I think that intel will upgrade cpu microcode in waves.

I have ThinkPad t530 (sandy bridge) with Windoze and Lenovo support page about Meltdown vulnerability stays that the new bios will be available from 2/2/2018. So there is a big probability that they will be sending microcodes for older families.

https://support.lenovo.com/us/en/solutions/len-18282

[Myu]

I think that intel will upgrade cpu microcode in waves.

I have ThinkPad t530 (sandy bridge) with Windoze and Lenovo support page about Meltdown vulnerability stays that new bios will be available from 2/2/2018. So there is big probability that they will be sending microcodes for older families.

https://support.lenovo.com/us/en/solutions/len-18282

That's some valuable intel (ha!) you brought here PrSo, thanks, will keep an eye on this, all hope may not be lost.

[Pearlseattle]

So looking at this page, there's no microcode update for Sandy Bridge ? Thanks Intel ...

I think that intel will upgrade cpu microcode in waves.

I have ThinkPad t530 (sandy bridge) with Windoze and Lenovo support page about Meltdown vulnerability stays that the new bios will be available from 2/2/2018. So there is a big probability that they will be sending microcodes for older families.

https://support.lenovo.com/us/en/solutions/len-18282

This is as well my understanding.
More precisely, the promise is that by Sunday 14.Jan "Intel expects to have issued updates for more than 90 percent of processor products introduced within the past five years" (stated here).
E.g. my "Xeon(R) CPU E3-1260L v5" hasn't been patched yet

[dmpogo]

To those of you who have patched/upgraded everything - can you comment on the performance, is there a noticable hit ?

[saboya]

To those of you who have patched/upgraded everything - can you comment on the performance, is there a noticable hit ?

Unnoticeable outside synthetic benchmarks / very specific server usage.