Gentoo Forums :: View topic - spectre and meltdown questions

spectre and meltdown questions

View unanswered posts
View posts from last 24 hours

Goto page 1, 2, 3 Next

Gentoo Forums Forum Index

Networking & Security

View previous topic :: View next topic

Author

Message

Mgiese
Veteran
Veteran

Joined: 23 Mar 2005
Posts: 1630
Location: indiana

Posted: Mon Feb 05, 2018 1:33 am Post subject: spectre and meltdown questions

according to :

Code:

# 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:Vulnerable: Minimal generic ASM retpoline

my system is still vulnerable to the spectre flaws, although i used this guide to update my processors microcode as described here :

https://wiki.gentoo.org/wiki/Intel_microcode#New_method_without_initram-fs.2Fdisk

i used the "New method without initram-fs/disk"

i am running linux-4.15.0-gentoo. any suggestions ? i know i could dig some more into guides and forum topics
but in the end it is confusing and inscrutable atm, at least for me

any help is very much appreciated!
_________________
I do not have a Superman complex, for I am God not Superman

Ryzen9 7950x (powersave governor) ; Radeon 7900XTX ; kernel 6.11.3 ; XFCE

The Main Man
Veteran
Veteran

Joined: 27 Nov 2014
Posts: 1172
Location: /run/user/1000

Posted: Mon Feb 05, 2018 2:35 am Post subject:

For Spectre v2 you will need to compile kernel with gcc 7.3.0 Currently there's no cure for Spectre v1

Atha
Apprentice

Joined: 22 Sep 2004
Posts: 243

Posted: Tue Feb 06, 2018 3:43 pm Post subject:

kajzer wrote:

For Spectre v2 you will need to compile kernel with gcc 7.3.0

Right.

kajzer wrote:

Currently there's no cure for Spectre v1

Actually there is. But you'd have to recompile your whole system, i.e. "emerge -e @world", with a new set of CFLAGS/CXXFLAGS and LDFLAGS that include something like "-mfunction-return=thunk"... And there is will be a performance penelty when doing so.

If you're interested, this posting in the forum has some nice suggestions, but be warned that not all packages will work with this modification. Namely Firefox seems to not run when compiled with "-mfunction-return=thunk"...

They plan to include a Spectre v1 patch for the next kernel release 4.16 (as Phoronix reported).

Mgiese
Veteran
Veteran

Joined: 23 Mar 2005
Posts: 1630
Location: indiana

Posted: Tue Feb 06, 2018 10:48 pm Post subject:

kajzer wrote:

For Spectre v2 you will need to compile kernel with gcc 7.3.0
Currently there's no cure for Spectre v1

after updating to gcc 7.3.0 and recompiling the kernel the info changed :

Code:

so i fixed meldown and spectreV2 and wait for spectreV1 fix in kernel 4.16 ?? am i right?

i installed latest intel-microcode-20180108-r1 and build the firmware into the kernel, but

Code:

# dmesg | grep microcode
[ 0.000000] microcode: microcode updated early to revision 0x1c, date = 2015-02-26
[ 0.358586] microcode: sig=0x306a9, pf=0x2, revision=0x1c
[ 0.358888] microcode: Microcode Update Driver: v2.2.

reports a very old firmware.
intel reports here https://downloadcenter.intel.com/product/68316/Intel-Core-i5-3470-Processor-6M-Cache-up-to-3-60-GHz- that there has been a new firmware released on 11/27/2017... what am i doing wrong ? could i even fix spectreV1 with a newer firmware ?

thanks again
_________________
I do not have a Superman complex, for I am God not Superman

Ryzen9 7950x (powersave governor) ; Radeon 7900XTX ; kernel 6.11.3 ; XFCE

Atha
Apprentice

Joined: 22 Sep 2004
Posts: 243

Posted: Wed Feb 07, 2018 12:30 am Post subject:

Mgiese wrote:

Code:

You're doing everything right. There is no fix for Spectre v1 just yet. You've got Meltdown fixed, which is the easiest way to compromise your system. Just make sure you have an updated version of your favorite browser. Firefox and Chromium have been patched to make Spectre no longer possible. Using NoScript and an Adblocker can also be an additional security action.

Other than that, everyone on the planet currently has an unpatched system when it comes to Spectre v1. Be it Intel or AMD.

Intel retracted the microcode update it had released before because of system instabilities (random restarts). Newer microcode with stable Spectre fixes is being made at the moment, but AFAIK it needs an updated kernel as well, which will be 4.16 or a later version of 4.15 with the fix backported.

Atha
Apprentice

Joined: 22 Sep 2004
Posts: 243

Posted: Wed Feb 07, 2018 12:49 am Post subject:

BTW, this is my system:

Code:

# grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline

Nevertheless, I am currently recompiling my whole system with CFLAGS/CXXFLAGS that include: "-mindirect-branch=thunk -fstack-protector-strong -fstack-check=specific -mindirect-branch=thunk -fno-plt -mfunction-return=thunk" and all packages, that can handle it, addtitionally with "-pie -fPIE".

I also use LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--sort-common -Wl,--hash-style=both -Wl,-z,-relro -Wl,-znow -fstack-protector-strong -pie -fPIE -fstack-check=specific -mindirect-branch=thunk -fno-plt -mfunction-return=thunk"

This should make my system as much as possible invulnerable to Spectre v1, dispite what the kernel has to say about it. I don't recommend this to you though, as this recompilation a) is quite complicated (I manually have to switch to a non-pie-env in case a package doesn't work with position-independent code) and b) it takes a great amount of compile time (and energy) and c) it slows the system down.

[Edit:]

Sorry, I had a typo in the LDFLAGS: "-Wl,Ol" is totally wrong, it ought to be "-Wl,-O1". :!:

Compiling stuff with the wrong LDFLAGS causes compilation failures!

Last edited by Atha on Sun Jan 06, 2019 11:57 pm; edited 1 time in total

laizzn
n00b
n00b

Joined: 24 Feb 2015
Posts: 25

Posted: Fri Feb 09, 2018 2:04 pm Post subject:

Mgiese wrote:

kajzer wrote:

For Spectre v2 you will need to compile kernel with gcc 7.3.0
Currently there's no cure for Spectre v1

after updating to gcc 7.3.0 and recompiling the kernel the info changed :

Code:

so i fixed meldown and spectreV2 and wait for spectreV1 fix in kernel 4.16 ?? am i right?

i installed latest intel-microcode-20180108-r1 and build the firmware into the kernel, but

Code:

I have the same problem... I have also updated intel-microcode but the revision/date remains unchanged even though according to intel my processor (Ivy Bridge, Intel(R) Core(TM) i7-3770 CPU) should have received a fix/update.
However on another site I read that 22nm cpus aren't affected after all. I don't know what's true...

Code:

[ 0.000000] microcode: microcode updated early to revision 0x1c, date = 2015-02-26
[ 0.796304] microcode: sig=0x306a9, pf=0x2, revision=0x1c
[ 0.796462] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

The Main Man
Veteran
Veteran

Joined: 27 Nov 2014
Posts: 1172
Location: /run/user/1000

Posted: Fri Feb 09, 2018 6:16 pm Post subject:

There's a change regarding Spectre v1, with kernel 4.15.2 this is what I get :

Code:

grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline

spectre-meltdown-checker

Code:

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Kernel has array_index_mask_nospec: YES (1 occurence(s) found of 64 bits array_index_mask_nospec())
> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Mitigation 1
* Kernel is compiled with IBRS/IBPB support: NO
* Currently enabled features
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* IBPB enabled: NO
* Mitigation 2
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
* Retpoline enabled: NO
> STATUS: NOT VULNERABLE (Mitigation: Full generic retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (Mitigation: PTI)

saellaven
l33t
l33t

Joined: 23 Jul 2006
Posts: 655

Posted: Fri Feb 09, 2018 6:18 pm Post subject:

As of 4.15.2,

Code:

/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline

Code:

Spectre and Meltdown mitigation detection tool v0.34+

Checking for vulnerabilities against specified kernel
CPU is AMD FX(tm)-8350 Eight-Core Processor
Will use vmlinux image /boot/EFI/EFI/Boot/linux-current.efi
Will use kconfig /usr/src/linux/.config
Will use System.map file /boot/System.map-4.15.2
Kernel image is Linux version 4.15.2 (root@alpha) (gcc version 7.3.0 (Gentoo 7.3.0 p1.0)) #1 SMP PREEMPT Wed Feb 7 22:52:37 EST 2018

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: NO
* CPU indicates IBRS capability: NO
* Kernel has set the spec_ctrl flag in cpuinfo: N/A (not testable in offline mode)
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: NO
* CPU indicates IBPB capability: NO
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: NO
* CPU indicates STIBP capability: NO
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU microcode is known to cause stability problems: NO
* CPU vulnerability to the three speculative execution attacks variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: NO

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Kernel has array_index_mask_nospec: YES (1 occurence(s) found of 64 bits array_index_mask_nospec())
* Checking count of LFENCE instructions following a jump in kernel... NO (only 5 jump-then-lfence instructions found, should be >= 30 (heuristic))
> STATUS: NOT VULNERABLE (Kernel source has been patched to mitigate the vulnerability (array_index_mask_nospec))

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
* Kernel is compiled with IBRS/IBPB support: NO
* Currently enabled features
* IBRS enabled for Kernel space: N/A (not testable in offline mode)
* IBRS enabled for User space: N/A (not testable in offline mode)
* IBPB enabled: N/A (not testable in offline mode)
* Mitigation 2
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
* Retpoline enabled: N/A (can't check this in offline mode)
> STATUS: NOT VULNERABLE (retpoline mitigates 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: N/A (can't verify if PTI is enabled in offline mode)
* Performance impact if PTI is enabled
* CPU supports PCID: NO (no security impact but performance will be degraded with PTI)
* CPU supports INVPCID: NO (no security impact but performance will be degraded with PTI)
> STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)

Mgiese
Veteran
Veteran

Joined: 23 Mar 2005
Posts: 1630
Location: indiana

Posted: Tue May 22, 2018 10:20 am Post subject:

hello is there yet a fix for the new spectre vulnerability: /sys/devices/system/cpu/vulnerabilities/spec_store_bypass ?? thanks in advance _________________ I do not have a Superman complex, for I am God not Superman Ryzen9 7950x (powersave governor) ; Radeon 7900XTX ; kernel 6.11.3 ; XFCE

Atha
Apprentice

Joined: 22 Sep 2004
Posts: 243

Posted: Tue May 22, 2018 11:27 am Post subject:

Code:

# grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline, IBPB

I don't see spec_store_bypass on my AMD system, kernel 4.16.9. Is this Intel-only? Or will this be indicated in a later kernel?

Code:

# cat /proc/cpuinfo | grep -m 2 -e bugs -e "model name"
model name : AMD Ryzen 7 1800X Eight-Core Processor
bugs : sysret_ss_attrs null_seg spectre_v1 spectre_v2

Atha
Apprentice

Joined: 22 Sep 2004
Posts: 243

Posted: Tue May 22, 2018 11:55 am Post subject:

So, I checked my other machine, a ThinkPad X230 with the latest UEFI BIOS update. This one doesn't run Gentoo but Debian.

Code:

# uname -r -v
4.16.0-1-amd64 #1 SMP Debian 4.16.5-1 (2018-04-29)

# dmesg -t | grep "LENOVO 2325AZ8"
DMI: LENOVO 2325AZ8/2325AZ8, BIOS G2ETB2WW (2.72 ) 04/11/2018

# dmesg -t | grep "microcode"
microcode: sig=0x306a9, pf=0x10, revision=0x1f
microcode: Microcode Update Driver: v2.2.

# grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB, IBRS_FW

# cat /proc/cpuinfo | grep -m 2 -e "bugs" -e "model name"
model name : Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz
bugs : cpu_meltdown spectre_v1 spectre_v2

I cannot see spec_store_bypass there as well. But again, this will likely be too new for this kernel to pick it up. Is spec_store_bypass one of the 8 new flaws that were announced as Spectre NG?

mike155
Advocate

Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany

Posted: Tue May 22, 2018 12:11 pm Post subject:

Quote:

Is spec_store_bypass one of the 8 new flaws that were announced as Spectre NG?

Yes, it's called Spectre V4 (Speculative Store Bypass, CVE-2018-3639). Unfortunately, the proposed mitigation will slow down your computer by approximately 2 to 8 percent: https://newsroom.intel.com/editorials/addressing-new-research-for-side-channel-analysis/

Mgiese
Veteran
Veteran

Joined: 23 Mar 2005
Posts: 1630
Location: indiana

Posted: Tue May 22, 2018 7:34 pm Post subject:

mike155 wrote:

Quote:

Is spec_store_bypass one of the 8 new flaws that were announced as Spectre NG?

howto mitigate system ??

Code:

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

even does not shown output mentioned above... the output was from ubuntu 18.04 server

thanks a lot
_________________
I do not have a Superman complex, for I am God not Superman

Ryzen9 7950x (powersave governor) ; Radeon 7900XTX ; kernel 6.11.3 ; XFCE

Mgiese
Veteran
Veteran

Joined: 23 Mar 2005
Posts: 1630
Location: indiana

Posted: Tue May 22, 2018 7:35 pm Post subject:

Atha wrote:

Code:

# grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline, IBPB

I don't see spec_store_bypass on my AMD system, kernel 4.16.9. Is this Intel-only? Or will this be indicated in a later kernel?

Code:

# cat /proc/cpuinfo | grep -m 2 -e bugs -e "model name"
model name : AMD Ryzen 7 1800X Eight-Core Processor
bugs : sysret_ss_attrs null_seg spectre_v1 spectre_v2

output was from ubuntu server 18.04. my 4.16 gentoo system doesnt show this output either
_________________
I do not have a Superman complex, for I am God not Superman

Ryzen9 7950x (powersave governor) ; Radeon 7900XTX ; kernel 6.11.3 ; XFCE

mike155
Advocate

Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany

Posted: Tue May 22, 2018 7:59 pm Post subject:

Quote:

howto mitigate system ??

Patches have not been released. You'll have to wait...

till
n00b
n00b

Joined: 19 Sep 2007
Posts: 22

Posted: Wed May 23, 2018 12:54 pm Post subject:

Just for the record: Linux 4.9, 4.14, 4.16 Point Releases Bring SSBD For Spectre V4: https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.9-To-4.16-SSBD beside a recent kernel you need a new microcode to display /sys/devices/system/cpu/vulnerabilities/spec_store_bypass you will also need a recent kernel. _________________ Greetings Till

j_c_p
Guru
Guru

Joined: 30 Aug 2003
Posts: 319
Location: France - Colmar

Posted: Wed May 23, 2018 3:15 pm Post subject:

Code:

jcp@phoenix64 ~ $ grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Not affected
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline

Code:

jcp@phoenix64 ~ $ cat /proc/cpuinfo | grep -m 2 -e bugs -e "model name"
model name : AMD Phenom(tm) II X6 1100T Processor
bugs : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs null_seg amd_e400 spectre_v1 spectre_v2

Code:

jcp@phoenix64 ~ $ uname -a
Linux phoenix64 4.16.11 #1 SMP PREEMPT Wed May 23 14:47:16 CEST 2018 x86_64 AMD Phenom(tm) II X6 1100T Processor AuthenticAMD GNU/Linux

[Moderator edit: changed [quote] tags to [code] tags to preserve output layout. -Hu]
_________________
Lian Li PC60 - AMD FX 8300 - Asrock 990FX EXTREME9 - Gigabyte GTX960 G1 Gaming 4Go

Atha
Apprentice

Joined: 22 Sep 2004
Posts: 243

Posted: Wed May 23, 2018 5:05 pm Post subject:

Code:

# uname -r -v
4.16.11-gentoo #1 SMP Wed May 23 01:20:37 CEST 2018

# cat /proc/cpuinfo | grep -m 2 -e "bugs" -e "model name"
model name : AMD Ryzen 7 1800X Eight-Core Processor
bugs : sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass

# grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline, IBPB

Yes, a fix is here, also on 4.16.11...

[Edit] But that's only 1 out of 8, right? There's more to come, if the article on Spectre NG is correct. According to this source Intel classified 4/8 as high risk and the remaining 4 as medium. One of the high risk ones could potentially be a signigicantly higher risk than the already fixed Spectre (V1/V2) was. Each of the flaws got their own CVE number.

Maybe the fixed one is the higher than Spectre flaw? Hopefully. Anyway, 7/8 unfixed :roll:

candrews
Developer

Joined: 10 Aug 2005
Posts: 162

Posted: Thu May 24, 2018 1:28 pm Post subject: spectre-meltdown-checker

I've found https://github.com/speed47/spectre-meltdown-checker to be quite helpful in understanding the status of the vulnerabilities and mitigations. The project seems to be keeping up to date as more information becomes available and new vulnerabilities are reported. _________________ I'm working on a variety of random things throughout Gentoo.

ChrisJumper
Advocate

Joined: 12 Mar 2005
Posts: 2403
Location: Germany

Posted: Thu May 24, 2018 3:56 pm Post subject:

Code:

grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB, IBRS_FW

With Kernel 4.16.11 and the latest intel-microcode Ebuild (20180426-r1) from bug 65463 through an local overlay.

Code:

dmesg | grep microcode
[ 0.000000] microcode: microcode updated early to revision 0x84, date = 2018-01-21
[ 0.578849] microcode: sig=0x906e9, pf=0x2, revision=0x84
[ 0.578868] microcode: Microcode Update Driver: v2.2.

Seems like there is no microcode Update available for this Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz.

I don't like to say this but Intel had month to prepare this microcode patches. However could be worse.

Edit:

Code:

Speculative Store Bypass disabled via prctl and seccomp

Atha, even if you have an AMD-CPU. Have i missed a Kernel-Configuration to apply this?

Last edited by ChrisJumper on Thu May 24, 2018 4:06 pm; edited 1 time in total

mv
Watchman

Joined: 20 Apr 2005
Posts: 6780

Posted: Thu May 24, 2018 4:04 pm Post subject:

ChrisJumper wrote:

Code:

Seems like there is no microcode Update available for this Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz

Same vulnerabilities here for i3-4130 CPU @ 3.40GHz (gentoo-sources-4.16.11 and intel-microcode-20180426-r1).
Also passing spec_store_bypass_disable=on on the kernel command line doesn't improve the situation.

Code:

dmesg | grep microcode
[ 0.234388] microcode: sig=0x306c3, pf=0x2, revision=0x24
[ 0.234407] microcode: Microcode Update Driver: v2.2.

I am also wondering whether I missed to activate some kernel option.

Atha
Apprentice

Joined: 22 Sep 2004
Posts: 243

Posted: Thu May 24, 2018 6:16 pm Post subject:

ChrisJumper wrote:

Atha, even if you have an AMD-CPU. Have i missed a Kernel-Configuration to apply this?

I didn't change my configuration from the previous versions. For me the last change was necessary with 4.16.6. No, I don't think you missed something, I didn't find a specific kernel configuration for this as well.

Maybe it is because of gcc: As an experiment, completely unrelated to the recent security flaws, I compiled the kernel with gcc-8.1.0 instead of 7.3.0. Maybe it's due to that?
(The unrelated experiment is that I had read that GCC 8 would finally receive AMD Ryzen optimizations. As of now, the Linux kernel was the only thing I compiled with it though...)

In order to install gcc-8.1.0-r3 it has to be unmasked first:

Code:

echo "=sys-devel/gcc-8.1.0-r3 **" >> /etc/portage/package.accept_keywords

OR, if /etc/portage/package.accept_keywords is a directory, like this (e.g.):

Code:

echo "=sys-devel/gcc-8.1.0-r3 **" >> /etc/portage/package.accept_keywords/50gcc-8.1.0

For the kernel I used genkernel, which provides means to compile the kernel with the gcc of your choosing:

Code:

# genkernel --kernel-cc=/usr/bin/gcc-8.1.0 --utils-cc=/usr/bin/gcc-8.1.0 all
# emerge -1 @module-rebuild

Naturally, the kernel modules only build when they also use the same gcc version used for compiling the kernel. I had to add a new build environment, like this:

Code:

local ~ # cat /etc/portage/env/compiler-gcc-8-spectrev1
# Spectre v1 counteraction (including -pie -fPIE):
CFLAGS="-O2 -march=znver1 -pipe -mindirect-branch=thunk -fstack-protector-strong -pie -fPIE -fstack-check=specific -mindirect-branch=thunk -fno-plt -mfunction-return=thunk"
CXXFLAGS="${CFLAGS}"

LDFLAGS="-Wl,-O2 -Wl,--as-needed -Wl,--sort-common -Wl,--hash-style=both -Wl,-z,relro -Wl,-znow -fstack-protector-strong -pie -fPIE -fstack-check=specific -mindirect-branch=thunk -fno-plt -mfunction-return=thunk"

CC="gcc-8.1.0"
CXX="g++"
AR="ar"
NM="nm"
RANLIB="ranlib"

The important line is CC="gcc-8.1.0"... The rest should be a 1:1 copy from you /etc/portage/make.conf file.

In order to use this build environment, add another file (or directory, containing files) /etc/portage/make.env. I have a directory:

Code:

local ~ # cat /etc/portage/package.env/51spectrev1-gcc8
# USE WITH:
#
# genkernel --kernel-cc=gcc-8.1.0 --utils-cc=gcc-8.1.0 --no-splash all && emerge @module-rebuild && grub-mkconfig -o /boot/grub/grub.cfg && umount /boot
#
# EXPERIMENTAL gcc-8.1.0-r3

app-emulation/virtualbox-modules compiler-gcc-8-spectrev1

(I wrote a reminder of how to use it as comment...) Afterwards I always deactivate it by commenting the modules, as this is just an experiment for now.

BUT it is just a guess that this could be gcc related... maybe it is AMD-only for now. I have no idea...

[Edit:]

candrews wrote:

I've found https://github.com/speed47/spectre-meltdown-checker to be quite helpful in understanding the status of the vulnerabilities and mitigations. The project seems to be keeping up to date as more information becomes available and new vulnerabilities are reported.

According to speed47/spectre-meltdown-checker on github, speculative store bypass is CVE-2018-3639 or Variant 4. Quote: "Mitigation: microcode update + kernel update making possible for affected software to protect itself"

So you'd need a microcode update additionally to the kernel update. My board is an ASUS PRIME X370 Pro, and I just recently updated the UEFI firmware.

Code:

DMI: System manufacturer System Product Name/PRIME X370-PRO, BIOS 4011 04/19/2018

I guess you can forget about the experimental gcc-8.1.0 update then...

[Edit:]

Fixed stupid typo "-Ol" (letter "L") instead of "-O1" (the number "1")... If you used the wrong one, you likely got compilation failures! Either use "-O1" or any other number. I now use "-O2"...
Sorry for any inconvenience. :oops:

Last edited by Atha on Sun Jan 06, 2019 11:42 pm; edited 1 time in total

ChrisJumper
Advocate

Joined: 12 Mar 2005
Posts: 2403
Location: Germany

Posted: Thu May 24, 2018 10:02 pm Post subject:

Atha, thank you!

I am not sure if intels microcode update is highly related to the cpu hardware, and the one that i checked just have to wait.

gcc 8.1, i am not sure. Suse Support wrote:

Quote:

On Intel x86 systems, updated CPU microcode is required to enable this mitigation. This microcode is either supplied by your hardware / BIOS vendor or by SUSE using the official Intel released microcode packages.

Mitigations need to be implemented for the Linux Kernel and for Hypervisors, both for passing through new CPU flags and MSR registers (on x86) and supporting of switching off/on the mitigation.

However the interesting Part of the Post is:

Quote:

- Not affected
The processor is not affected by this problem.

- Vulnerable
The processor is vulnerable.

- Mitigation: Speculative Store Bypass disabled
The processor is vulnerable and the mitigation is enabled by default.

- Mitigation: Speculative Store Bypass disabled via prctl
The processor is vulnerable and the mitigation needs to be enabled by using prctl().

- Mitigation: Speculative Store Bypass disabled via prctl and seccomp
The processor is vulnerable and the mitigation needs to be enabled by using prctl() or seccomp().

The manual Page of prctl and seccomp looks like they are common functions/system calls to handle processes/threds. Seccomp stands for Secure Computing, its a userspace-api to create rules and manage filters, defined in scripts or c-code.

Looks like i have to check my microcode.

For this Speculative Store Bypass, Red Hat have a long Blog post with a nice description "Suppose a group of coworker friends take turns stopping at a local coffee shop on the way to work. ..." and more background information too.

mv
Watchman

Joined: 20 Apr 2005
Posts: 6780

Posted: Fri May 25, 2018 4:03 am Post subject:

ChrisJumper wrote:

gcc 8.1

It's certainly not related. I didn't post this information previously, but I only have gcc-8.1 on my system.

Quote:

- Mitigation: Speculative Store Bypass disabled via prctl and seccomp

That's why I emphasized that it doesn't work even if I pass spec_store_bypass_disable=on on the kernel command line:

The default "auto" means that the relevant processor bit is enabled only in seccomp code - which means essentially only for virtual machines making use of that code: The kernel developers apparently have chosen this default, because in view of the speed loss they consider only these applications worth protecting. I don't know why Linus agreed with such a dangerous default now while for the other mitigations he complained the opting-in instead of opting-out is the wrong way. IMHO this is now a very wrong decision.

Atha, I would recommend that you also use the above mentioned kernel command line parameter if you can afford the speed loss.

Display posts from previous:

	Gentoo Forums Forum Index Networking & Security	All times are GMT Goto page 1, 2, 3 Next
Page 1 of 3

Jump to:

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

Copyright 2001-2025 Gentoo Foundation, Inc. Designed by Kyle Manna © 2003; Style derived from original subSilver theme. | Hosting by Gossamer Threads Inc. © | Powered by phpBB 2.0.23-gentoo-p11 © 2001, 2002 phpBB Group
Privacy Policy