| View previous topic :: View next topic |
| Author |
Message |
tholin
Apprentice
Joined: 04 Oct 2008
Posts: 203
|
 Posted: Mon Jan 08, 2018 2:11 pm Post subject: |
 |
|
| Naib wrote: | | NeddySeagoon wrote: | | That will be another 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. |
|
| Back to top |
|
 |
PrSo
Tux's lil' helper
Joined: 01 Jun 2017
Posts: 136
|
| Posted: Mon Jan 08, 2018 3:09 pm Post subject: |
|
|
| Ant P. wrote: |
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.
Last edited by PrSo on Mon Jan 08, 2018 9:27 pm; edited 1 time in total |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
|
| Back to top |
|
|
tholin
Apprentice
Joined: 04 Oct 2008
Posts: 203
|
| Posted: Mon Jan 08, 2018 3:20 pm Post subject: |
|
|
| Naib wrote: | | 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-kernel@vger.kernel.org/msg1578797.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: |
$ 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: |
$ 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. |
|
| Back to top |
|
|
EasterParade
l33t
Joined: 26 Jul 2003
Posts: 938
|
| Posted: Mon Jan 08, 2018 3:36 pm Post subject: |
|
|
| Code: | ./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 |
|
| Back to top |
|
|
Thistled
Guru
Joined: 06 Jan 2011
Posts: 572
Location: Scotland
|
| Posted: Mon Jan 08, 2018 5:57 pm Post subject: |
|
|
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.
_________________
Whatever you do, do it properly! |
|
| Back to top |
|
|
albright
Advocate
Joined: 16 Nov 2003
Posts: 2588
Location: Near Toronto
|
| Posted: Mon Jan 08, 2018 6:09 pm Post subject: |
|
|
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: | 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: | 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: | cpuid -1r:
edx=0x0c000000 |
But the 6700 does not seem to take the update:
| Code: | 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: | 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
_________________
.... there is nothing - absolutely nothing - half so much worth
doing as simply messing about with Linux ...
(apologies to Kenneth Graeme) |
|
| Back to top |
|
|
Thistled
Guru
Joined: 06 Jan 2011
Posts: 572
Location: Scotland
|
| Posted: Mon Jan 08, 2018 7:19 pm Post subject: |
|
|
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.
_________________
Whatever you do, do it properly! |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Mon Jan 08, 2018 11:50 pm Post subject: |
|
|
| albright wrote: | But the 6700 does not seem to take the update:
| Code: | 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:Security/Vulnerabilities/Meltdown_and_Spectre
| Quote: | | 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? |
|
| Back to top |
|
|
albright
Advocate
Joined: 16 Nov 2003
Posts: 2588
Location: Near Toronto
|
| Posted: Tue Jan 09, 2018 1:08 am Post subject: |
|
|
| Quote: | eix -I intel-microcode
[I] 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_Desc.aspx?DwnldID=27337
Description: Intel IA32/IA64 microcode update data
|
looks like the latest to me ... (I could try the initrd route I guess ...)
_________________
.... there is nothing - absolutely nothing - half so much worth
doing as simply messing about with Linux ...
(apologies to Kenneth Graeme) |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Tue Jan 09, 2018 2:10 am Post subject: |
|
|
albright: you are right, the wiki page seems incorrect with 0xc2
| Code: | iucode_tool -l /lib/firmware/intel-ucode/* | grep 506e3
066/001: sig 0x000506e3, pf_mask 0x36, 2017-04-09, rev 0x00ba, size 98304
|
|
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9679
Location: almost Mile High in the USA
|
| Posted: Tue Jan 09, 2018 4:25 am Post subject: |
|
|
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...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
fedeliallalinea
Administrator
Joined: 08 Mar 2003
Posts: 30923
Location: here
|
| Posted: Tue Jan 09, 2018 7:20 am Post subject: |
|
|
| krinn wrote: | albright: you are right, the wiki page seems incorrect with 0xc2
| Code: | 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: | 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
_________________
Questions are guaranteed in life; Answers aren't. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9679
Location: almost Mile High in the USA
|
| Posted: Tue Jan 09, 2018 11:06 am Post subject: |
|
|
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.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Tue Jan 09, 2018 12:42 pm Post subject: |
|
|
| fedeliallalinea wrote: | I don't understand anymore, my Ivybridge (306e4) must be revision 0x42a from wiki page but
| Code: | 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/download/27337/Linux-Processor-Microcode-Data-File?product=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/bugreport.cgi?bug=886367
| Code: | + 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. |
|
| Back to top |
|
|
fedeliallalinea
Administrator
Joined: 08 Mar 2003
Posts: 30923
Location: here
|
| Posted: Tue Jan 09, 2018 1:11 pm Post subject: |
|
|
| krinn wrote: | 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!
_________________
Questions are guaranteed in life; Answers aren't. |
|
| Back to top |
|
|
The Main Man
Veteran
Joined: 27 Nov 2014
Posts: 1166
Location: /run/user/1000
|
| Posted: Tue Jan 09, 2018 1:39 pm Post subject: |
|
|
| Thistled wrote: | 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. |
|
| Back to top |
|
|
Myu
Apprentice
Joined: 22 Oct 2014
Posts: 164
Location: Belgium
|
| Posted: Tue Jan 09, 2018 2:22 pm Post subject: |
|
|
So looking at this page, there's no microcode update for Sandy Bridge ? Thanks Intel ... 
_________________
Gentoo stable with bits of ~amd64 // Xfce 4.13 + Compiz Reloaded. |
|
| Back to top |
|
|
Thistled
Guru
Joined: 06 Jan 2011
Posts: 572
Location: Scotland
|
| Posted: Tue Jan 09, 2018 2:53 pm Post subject: |
|
|
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?
_________________
Whatever you do, do it properly! |
|
| Back to top |
|
|
Myu
Apprentice
Joined: 22 Oct 2014
Posts: 164
Location: Belgium
|
| Posted: Tue Jan 09, 2018 3:03 pm Post subject: |
|
|
| Quote: | 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.
| Quote: | 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)
_________________
Gentoo stable with bits of ~amd64 // Xfce 4.13 + Compiz Reloaded. |
|
| Back to top |
|
|
PrSo
Tux's lil' helper
Joined: 01 Jun 2017
Posts: 136
|
| Posted: Tue Jan 09, 2018 3:05 pm Post subject: |
|
|
| Myu wrote: | | 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
Last edited by PrSo on Tue Jan 09, 2018 6:26 pm; edited 1 time in total |
|
| Back to top |
|
|
Myu
Apprentice
Joined: 22 Oct 2014
Posts: 164
Location: Belgium
|
| Posted: Tue Jan 09, 2018 3:08 pm Post subject: |
|
|
| Quote: | 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.
_________________
Gentoo stable with bits of ~amd64 // Xfce 4.13 + Compiz Reloaded. |
|
| Back to top |
|
|
Pearlseattle
Apprentice
Joined: 04 Oct 2007
Posts: 162
Location: Switzerland
|
| Posted: Tue Jan 09, 2018 7:44 pm Post subject: |
|
|
| PrSo wrote: | | Myu wrote: | | 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  |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3267
Location: Canada
|
| Posted: Tue Jan 09, 2018 9:36 pm Post subject: So how is the performance after patches ? |
|
|
| To those of you who have patched/upgraded everything - can you comment on the performance, is there a noticable hit ? |
|
| Back to top |
|
|
saboya
Guru
Joined: 28 Nov 2006
Posts: 552
Location: Brazil
|
| Posted: Tue Jan 09, 2018 11:08 pm Post subject: Re: So how is the performance after patches ? |
|
|
| dmpogo wrote: | | 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. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
