# spectre and meltdown questions

## Mgiese

according to : 

```
# 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!

----------

## The Main Man

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

Currently there's no cure for Spectre v1

----------

## Atha

 *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

 *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 :

```
# 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

```

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 

```
# 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

----------

## Atha

 *Mgiese wrote:*   

> 
> 
> ```
> # grep . /sys/devices/system/cpu/vulnerabilities/* 
> 
> ...

 

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

BTW, this is my system:

```
# 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:]  :Shocked: 

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

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

 *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 :
> ...

 

 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...

```
[    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

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

```
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

```
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

As of 4.15.2,

```

/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

```

```

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

hello is there yet a fix for the new spectre vulnerability:

/sys/devices/system/cpu/vulnerabilities/spec_store_bypass 

?? thanks in advance

----------

## Atha

```
# 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?

```
# 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

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

```
# 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

 *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

 *mike155 wrote:*   

>  *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/

 

howto mitigate system ??

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

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

thanks a lot

----------

## Mgiese

 *Atha wrote:*   

> 
> 
> ```
> # grep . /sys/devices/system/cpu/vulnerabilities/*
> 
> ...

 

output was from ubuntu server 18.04. my 4.16 gentoo system doesnt show this output either

----------

## mike155

 *Quote:*   

> howto mitigate system ??

 

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

----------

## till

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.

----------

## j_c_p

```
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
```

```
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
```

```
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]

----------

## Atha

```
# 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   :Rolling Eyes: 

----------

## candrews

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.

----------

## ChrisJumper

```
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.

```
 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: 

```
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

 *ChrisJumper wrote:*   

> 
> 
> ```
>  dmesg | grep microcode
> 
> ...

 

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.

```
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

 *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:

```
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.):

```
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:

```
# 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:

```
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:

```
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.

```
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:]  :Shocked: 

 :Exclamation:  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.   :Embarassed: Last edited by Atha on Sun Jan 06, 2019 11:42 pm; edited 1 time in total

----------

## ChrisJumper

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 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

 *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.

----------

## Atha

Thanks, mv. I was not fully aware that spec_store_bypass_disable=on is needed to get a full i.e. real mitigation.

```
# 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

/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization

/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline, IBPB
```

I didn't feel a real performance loss yet, but I've not yet had the demand to run such applications, like games. Anyway, how would I measure the real performance loss anyway? Is kompiling a kernel under the exact same conditions with the utility time enough to see the difference? Or is it the indicated FPS when playing a game?

----------

## ChrisJumper

 *Atha wrote:*   

>  Or is it the indicated FPS when playing a game?

 

Hey thats not the issue. If you play your game offline. Start the Kernel without patches. If your game is Online. Start the patched Kernel or do not store important Data.

However, buy other Hardware. We need just more time for Hardware without this possible harm. And there will be new harm in the future if you stay online.

The performance loss should be a minior issue. Because new Hardware will be so fast that it is enough for the next X years of Gaming or Computing. Except some Mobile Power-Issues.

However, i am a little pissed about Intel. Its nearly like google or Qualcomm with there Hardware Support or Security Patches... you can't sell hardware and security as service at the owners expense as operate model.

----------

## Atha

 *ChrisJumper wrote:*   

> Hey thats not the issue. If you play your game offline. Start the Kernel without patches. If your game is Online. Start the patched Kernel or do not store important Data.

 

I already do that. If I want to play a game, I restart with another kernel. Let me call it Windows 7/10. I play games on that other system that does not contain important data. I then have to restart to do stuff like E-Mails, Internet including Internet banking and all that other stuff that is not gaming, but sometimes gaming too (because there are Linux games, so why not play them?). Let me call this kernel Gentoo Linux.

But that is not a very satisfying situation. Restarts disturb your workflow. For instance, you might want to play a bit inbetween, then continue with "your work". I don't care if I have to restart into Windows or another not-so-safe Linux, it is a disruptive restart nevertheless and with Linux games available this restart would have been unneccessary, which is the great thing about Linux games!

 *Quote:*   

> However, buy other Hardware. We need just more time for Hardware without this possible harm. And there will be new harm in the future if you stay online.

 

That's a big problem. I just (in 2017) spent >1800 $/€ on hardware. My system is a one year old (or less) Ryzen 7 1800X + Vega10 graphics card. I am not willing to invest this amount of money again for at least 4 more years to come. The longer the better. But the bugs are not even fixed yet in now new systems anyhow. AFAIK Ryzen 2 has the same issues. Fixes are in firmware, microcode and software only.

 *Quote:*   

> The performance loss should be a minior issue. Because new Hardware will be so fast that it is enough for the next X years of Gaming or Computing. Except some Mobile Power-Issues.

 

The Ryzen 7 1800X is my new hardware. It has the performance loss, which may be or may not be minor, I don't know. But what is most important is that the security issues must finally be fixed!

Actually, why must it be new systems at all? I cannot understand why old systems are left out of this. They should be fixed as well. It is disastrous and a shame how older hardware doesn't get those firmware and microcode updates! And they should get them fast and free of charge! If I were the government, I would force the industry to release those updates. If they don't do it, I would force them to release the sources so others can fix it for them. Sadly, I am not a government, and I guess that lobbyist already convinced politicians to not intervene at all...

 *Quote:*   

> However, i am a little pissed about Intel. Its nearly like google or Qualcomm with there Hardware Support or Security Patches... you can't sell hardware and security as service at the owners expense as operate model.

 

I'm not with Intel since they got caught using illegal methods to push AMD out of the market. In other words: I use AMD CPUs and GPUs because of what Intel did in the past.

(GPUs... Nvidia is also not an option since they will never provide free graphics drivers... Intel actually has great free driver support, but again, I choose AMD for the mentioned reasons.)

----------

## ChrisJumper

There is a new Version through portage available: sys-firmware/intel-microcode-20180527-r1

As suggested i set in the bugreport for ebuild 20180426-r1 i set MICROCODE_SIGNATURES="-S" in make.conf, however it did not automatically install the File in /boot and i think thats the issue why it did not work on my system.

So i try to install it as suggested in wiki.gentoo.org/wiki/Intel_microcode but:

```
# iucode_tool -S --write-earlyfw=/boot/early_ucode.cpio /lib/firmware/intel-ucode/*

iucode_tool: system has processor(s) with signature 0x000906e9

iucode_tool: Writing selected microcodes to: /boot/early_ucode.cpio

iucode_tool: /boot/early_ucode.cpio: cannot write to, or create file: File exists
```

The script did not work too, i have to delete /boot/early_ucode.cpio to update it, i'll report later if it work as exacted.

Edit: Still no update for my processor, all the same.

----------

## ChrisJumper

Thank you Intel that i am still vulnerable to the spec_store_bypass.

I write here cause of the new (14. June 2018) Lazy FP State Restore, Spectre Issue. That one that got famous by openBSD Mastermind Theo de Raadt.

However it seemed to be fixed in the Linux Kernel in early 2016:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=58122bf1d856a4ea9581d62a07c557d997d46a19

Some more Links:

http://blog.cyberus-technology.de/posts/2018-06-06-intel-lazyfp-vulnerability.html

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00145.html

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3665 (as i post this, its still reserved and empty).

----------

## eccerr0r

```
chii /tmp # uname -a

Linux chii 4.9.95-gentoo #1 SMP Mon Jun 18 21:51:25 MDT 2018 i686 Intel(R) Atom(TM) CPU N270 @ 1.60GHz GenuineIntel GNU/Linux

chii /tmp # cat /sys/devices/system/cpu/vulnerabilities/*

Not affected

Not affected

Not affected
```

Woohoo!  I don't really need this machine any slower than it already is  :Sad:  (I just updated to profile 17, gcc-6.4.  Took 3 days of just about constant compiling, no distcc, and still not quite done yet.  VLC qt5 upgrade from qt4 is going to take a while still)

----------

## szatox

Alright, it's time to get some new laptop. Any idea what to look for so I can avoid recent vulnerabilities?

Any news about patched hardware?

----------

## mv

 *ChrisJumper wrote:*   

> Thank you Intel that i am still vulnerable to the spec_store_bypass.

 

20180616 finally seems to fix it for most processors.

(Well, the corresponding processor bit can be set. Whether it really helps and how much is a different question.)

----------

## ChrisJumper

 *mv wrote:*   

> 
> 
> 20180616 finally seems to fix it for most processors.
> 
> (Well, the corresponding processor bit can be set. Whether it really helps and how much is a different question.)

 

I got protection and updates on the important Servers.

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

/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI

/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 generic retpoline, IBPB, IBRS_FW
```

The System i posted in my previous post is still vulnerable. I just hope the Intel engineer's work slowly from top to bottom... and i will get some Update on Client Desktop Systems before the new hardware arrives hopefully early 2019 (10 nm technology).

However its a big mess, with the new announces and still unreleased spectre issues. The good part is - that make it easy to not (fully) trust a computer or to retain a good suspiciousness. Even if the probability of an incident is low.

@szatox

I am not sure. I think they announces some patched Hardware - like a small hot fix for the End of 2018. However i did not expect that the new announced 10nm Chips that delayed to mid or late 2019, will have hardware fixes. The time span is too short, but i hope that the new cpus have a fully patched mitigation microcode from the start.

I can't give a hardware advice.. because the unaffected baytrail Intel-CPU i have is just enough to read mails and open ssh connections or code with vim. Its not that fast satisfy today's desktop user. :)

----------

## Mgiese

as of today i run gentoo-sources-4.19.8 and the output is as follows :

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

/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion

/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, STIBP: disabled

```

is there any fix for ""/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Vulnerable"" yet ?? and what with the rest, is everything looking good for now ?

thanks as always

edit : just saw that for spec_store_bypass is a fix, but what to do, which specific kernel option do i have to turn on in order to be protect as this :

spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp  ?? Thanks a lot !

edit2 : i pass "spec_store_bypass_disable=on" to the kernel in grub.cfg and switched to gcc-8.2 plus make clean and make (thus i recompiled the kernel with the new gcc), still the same here :

```

/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Vulnerable 

```

----------

## j_c_p

```
jcp@phoenix64 ~ $ grep . /sys/devices/system/cpu/vulnerabilities/*

/sys/devices/system/cpu/vulnerabilities/l1tf:Not affected

/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, STIBP: disabled, RSB filling

```

```
Linux phoenix64 4.19.8 #1 SMP PREEMPT Sun Dec 9 14:38:28 CET 2018 x86_64 AMD FX(tm)-8300 Eight-Core Processor AuthenticAMD GNU/Linux
```

----------

## Mgiese

hi guys, still i have got no fix against -- spec_store_bypass -- i asked this question, here, several months ago, but got no answer since then.

i upgraded 2 weeks ago to 5.0.7 and my current vulnerability output is the following :

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

/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion

/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, STIBP: disabled, RSB filling

```

i`d be happy to fix it soon and get it off the table

tyvm

CPU : Intel Core i5-3470

----------

## Mgiese

```
General setup  --->

    [*] Initial RAM filesystem and RAM disk (initramfs/initrd) support

Processor type and features  --->

    <*> CPU microcode loading support

    [*]   Intel microcode loading support

emerge --ask --noreplace sys-firmware/intel-microcode sys-apps/iucode_tool

iucode_tool -S --write-earlyfw=/boot/early_ucode.cpio /lib/firmware/intel-ucode/*

grub-mkconfig -o /boot/grub/grub.cfg
```

and reboot did the trick  :Smile: 

```
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp

```

----------

## Atha

Hi!

With recent kernels including the new mitigations=[off|auto|auto,nosmt] kernel paramenter, I thought I'd post the options I use for a system as secure as possible... (though I might have gotten them wrong...)

On AMD:

```
mitigations=auto,nosmt spec_store_bypass_disable=on vsyscall=none init_on_alloc=1 init_on_free=1
```

On Intel:

```
mitigations=auto,nosmt kvm-intel.vmentry_l1d_flush=always l1tf=flush,nosmt mds=full,nosmt spec_store_bypass_disable=on vsyscall=none init_on_alloc=1 init_on_free=1
```

All kernel boot parameters are listed in /usr/src/linux/Documentation/admin-guide/kernel-parameters.txt. I added those shown above to GRUB_CMDLINE_LINUX in /etc/default/grub. After running grub-mkconfig -o /boot/grub/grub.cfg (or whatever you're using, naturally /boot must be mounted) GRUB then uses the new boot parameters for the kernel.

I find mitigations=auto is not enough for a really secure system. For what I'm using my PC for, I don't feel a big performance impact at all...

----------

## elover

I seem to have vulnerabilities, don't I?

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

/sys/devices/system/cpu/vulnerabilities/itlb_multihit:Not affected

/sys/devices/system/cpu/vulnerabilities/l1tf:Not affected

/sys/devices/system/cpu/vulnerabilities/mds:Not affected

/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: usercopy/swapgs barriers and __user pointer sanitization

/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline, IBPB: conditional, STIBP: disabled, RSB filling

/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Not affected
```

[Moderator edit: added [code] tags to preserve output layout. -Hu]

----------

## NeddySeagoon

elover,

You have some and mitigation is in place.

----------

## elover

 *NeddySeagoon wrote:*   

> elover,
> 
> You have some and mitigation is in place.

 

You leave me alone, I don't have to do anything. 

The messages scared me.

----------

## Ionen

No worries, as long as you're not me it's fine *Quote:*   

> $ grep . /sys/devices/system/cpu/vulnerabilities/* 
> 
> /sys/devices/system/cpu/vulnerabilities/itlb_multihit:KVM: Vulnerable
> 
> /sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: vulnerable
> ...

 

----------

## Tony0945

```
 MSI ~ # grep . /sys/devices/system/cpu/vulnerabilities/*

/sys/devices/system/cpu/vulnerabilities/itlb_multihit:Not affected

/sys/devices/system/cpu/vulnerabilities/l1tf:Not affected

/sys/devices/system/cpu/vulnerabilities/mds:Not affected

/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: usercopy/swapgs barriers and __user pointer sanitization

/sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable, IBPB: disabled, STIBP: disabled

/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Not affected

```

Never knowingly did anything about them. Don't know where the mitigations came from. The kernel?

----------

## Ionen

 *Tony0945 wrote:*   

> Never knowingly did anything about them. Don't know where the mitigations came from. The kernel?

 Yes, most of it is done by default and you have to go out of your way to stop it, not the other way around (but it does trade performance for security). Although you still need to update microcode for some things. Your BIOS is likely already updating it but unlikely to be latest.Last edited by Ionen on Tue Jan 14, 2020 11:55 pm; edited 1 time in total

----------

## Tony0945

 *Ionen wrote:*   

>  Your BIOS is likely already updating it but unlikely to be latest.

  I do keep the BIOS updated.

----------

## Ionen

 *Tony0945 wrote:*   

> I do keep the BIOS updated.

 Well, it's hard to say what a bios is really doing. You can check the revision in "grep microcode /proc/cpuinfo" although the code is probably not going to mean much without some digging or if you attempt to update it and get the same version either way.

----------

## Hu

Depending on your BIOS maintainer, a currently maintained BIOS may or may not exist and may or may not load the relevant microcode.  If you want to be sure the microcode is loaded, you can embed a copy of the relevant microcode in the kernel using the Kconfig option CONFIG_EXTRA_FIRMWARE, then set CONFIG_MICROCODE=y and CONFIG_MICROCODE_INTEL=y (or _AMD, as appropriate).  The kernel should then load microcode very early during boot.  The log message announcing it will be right at the start of dmesg.

----------

## The Main Man

 *Ionen wrote:*   

> No worries, as long as you're not me it's fine *Quote:*   $ grep . /sys/devices/system/cpu/vulnerabilities/* 
> 
> /sys/devices/system/cpu/vulnerabilities/itlb_multihit:KVM: Vulnerable
> 
> /sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: vulnerable
> ...

 

I'm curious, did you notice real performance gain when turning off all the mitigations ?

Did you make some tests ?

----------

## Atha

Mitigations for IBPB, IBRS and STIBP need microcode updates before the kernel can provide them - with the exception of Retpoline, which is generic.. If the updated microcode wasn't released as a part of a firmware update (BIOS or UEFI update), it's still possible to get the updated microcode in the form of files that are loaded at boot time. (E.g. this has been done on Debian Linux, here).

If you see "IBPB: disabled, STIBP: disabled" for Spectre v2 I would encourage you to get the microcode loaded by Linux. Unless your Intel-CPU is pre-Core-i, because then Intel did not provide a microcode update with the required functions. Likewise AMD didn't publish a microcode update for older CPUs.

See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/spectre.html for details.

----------

## rogge

 *Atha wrote:*   

> With recent kernels including the new mitigations=[off|auto|auto,nosmt] kernel paramenter, I thought I'd post the options I use for a system as secure as possible... (though I might have gotten them wrong...)
> 
> All kernel boot parameters are listed in /usr/src/linux/Documentation/admin-guide/kernel-parameters.txt. I added those shown above to GRUB_CMDLINE_LINUX in /etc/default/grub. After running grub-mkconfig -o /boot/grub/grub.cfg (or whatever you're using, naturally /boot must be mounted) GRUB then uses the new boot parameters for the kernel.

 

Hi,

is there any chance for lilo users, too?

Regards, rogge

----------

## saellaven

 *rogge wrote:*   

>  *Atha wrote:*   With recent kernels including the new mitigations=[off|auto|auto,nosmt] kernel paramenter, I thought I'd post the options I use for a system as secure as possible... (though I might have gotten them wrong...)
> 
> All kernel boot parameters are listed in /usr/src/linux/Documentation/admin-guide/kernel-parameters.txt. I added those shown above to GRUB_CMDLINE_LINUX in /etc/default/grub. After running grub-mkconfig -o /boot/grub/grub.cfg (or whatever you're using, naturally /boot must be mounted) GRUB then uses the new boot parameters for the kernel. 
> 
> Hi,
> ...

 

Just add it under your append line...

for example:

```

image=/boot/linux-5.6.2

       label=gentoo

       root=/dev/sda2

       append="mitigations=off"

```

----------

## Ionen

^ alternatively when building yourself you can also embed command line options in the kernel that will work regardless of how you boot, like:

```
CONFIG_CMDLINE_BOOL=y

CONFIG_CMDLINE="threadirqs mitigations=off snd_hda_intel.enable=1,0 root=..."
```

----------

## Atha

Special Register Buffer Data Sampling (SRBDS), CVE-2020-0543, also known as "Crosstalk". 

```
# uname -r -v

5.7.8-gentoo #1 SMP Sat Jul 11 18:55:39 CEST 2020

# dmesg -t | grep "LENOVO 2325AZ8"

DMI: LENOVO 2325AZ8/2325AZ8, BIOS G2ETB7WW (2.77 ) 09/24/2019

# dmesg -t | grep "microcode"

SRBDS: Vulnerable: No microcode

microcode: sig=0x306a9, pf=0x10, revision=0x21

microcode: Microcode Update Driver: v2.2.

# 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 spec_store_bypass l1tf mds swapgs itlb_multihit srbds

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

/sys/devices/system/cpu/vulnerabilities/itlb_multihit:KVM: Mitigation: Split huge pages

/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: cache flushes, SMT disabled

/sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU buffers; SMT disabled

/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI

/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled

/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization

/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, RSB filling

/sys/devices/system/cpu/vulnerabilities/srbds:Vulnerable: No microcode

/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Not affected

```

Great. I don't see any new firmware/microcode for this Sandy Bridge Intel Core i 2nd generation CPU coming, although according to Phoronix Intel shipped new microcode in May 2020 specifically for Sandy Bridge Xeons.

What's wrong with you, Intel?!? Why not supply new microcode and continue fixing a failure that was detected almost two years ago (in Sept. 2018)?!?

BTW, Phoronix also benchmarked the impact of the SRBDS fix, showing high theoretical but low real-life impact. I wonder what's keeping Intel from providing this fix for every affected CPU... (mine is 06-58-09 - no microcode yet...)

Update: I just realized, the Sandy Bridge CPU is in the other computer...   :Rolling Eyes: 

The Core i5-3320M is Ivy Bridge, 3rd generation Core i, but still: no microcode...

----------

## Ant P.

 *Atha wrote:*   

> What's wrong with you, Intel?!? Why not supply new microcode and continue fixing a failure that was detected almost two years ago?!?

 

To be fair here, Intel isn't the only company that sucks at supporting old chips:

```
Model name:                      AMD E-350 Processor

Vulnerability Itlb multihit:     Not affected

Vulnerability L1tf:              Not affected

Vulnerability Mds:               Not affected

Vulnerability Meltdown:          Not affected

Vulnerability Spec store bypass: Vulnerable               <----

Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization

Vulnerability Spectre v2:        Mitigation; Full AMD retpoline, STIBP disabled, RSB filling

Vulnerability Srbds:             Not affected

Vulnerability Tsx async abort:   Not affected
```

----------

## Atha

 *Ant P. wrote:*   

> To be fair here, Intel isn't the only company that sucks at supporting old chips:
> 
> ```
> Model name:                      AMD E-350 Processor
> 
> ...

 

There is no way to fix spec_store_bypass, the only mitigation is to disable it. This works for AMD as it does for Intel, by configuring the kernel or by using the appropriate kernel commandline parameter spec_store_bypass_disable=on, e.g. in /etc/default/grub.

```
GRUB_CMDLINE_LINUX="mitigations=auto,nosmt spec_store_bypass_disable=on"
```

Then you should get this:

```
spec_store_bypass:Mitigation: Speculative Store Bypass disabled
```

I recommend the safest possible settings, which are different for Intel and AMD (please refer to this posting). The kernel developers don't preset the safest mitigations by default, because of the likelyness of them being exploited vs. the impact on performance.

And to be completely fair:

AMD is vunlerable to three design flaws: Spectre v1 and v2 as well as Speculative Store Bypass. All of them can be mitigated. For Spectre v2 some older CPUs did not get firmware/ucode updates, which would have been required for the mitigation to fully work.

Intel is vulnerable to 5 or 6 more flaws in the design, i.e. the situation is 2-3 times worse. Meltdown alone is the worst flaw a CPU can have, because it actively helps when an exploit of the other flaws takes place. The other vulnerabilities are just different variations of the same design flaws, and it is not comprehensible to me that they fix one but not the other. E.g. they fixed Microarchitectural Data Sampling (MDS), and SRBDS is just one special variant of the same thing, but needing a different mitigation. It needs firmware/microcode. See also CrossTalk/SRBDS Shows Possibility Of Leaking Information Across Physical CPU Cores.

Like AMD, older Intel CPUs did not get new microcode either, leaving the complete Core 2 Duo series unpatched. As more and more flaws hit the news, even previously patched CPUs are left behind, like the first Core i generations.

I think they should be forced to make microcode for those CPUs. Older CPUs are not bad and people continue using systems powered by them. Especially with Linux you can keep using 64-Bit systems, only 32-Bit is currently phased out, more and more every year. A pitty, but okay.

No microcode: not okay.

[Edit]: typos

----------

## Tony0945

I'm sure Intel/AMD's response would be something like "These older CPU's are no longer in production. For the greatest protection buy a current production CPU."

These is analogous to Microsoft "These older OS's, XP & window 7 are no longer for sale. For the greatest protection purchase Windows 10."

At least MSFT gives a discount to current holders of Windows licenses. Intel and AMD do not.

I do see your point. At least automakers don't say "Your ten year-old-car is vulnerable to explosion in a rear end collision. For the greatest protection purchase a new {insert name} from your authorized dealer."  But then there is a law requiring automobile recalls. No such law for CPU's.

----------

## Atha

The fact that Intel and AMD provided microcode/ucode updates for CPU around 8 years old shows that it is important. And for the systems it is not as simple as replacing the CPU, so you'd have to also replace at least the mainboard and the DIMMs, possibly more. For embedded systems and laptops it is (to 99.99%) impossible.

Most people will either leave it and live with the vulnerabilities, or they will [need|have|want] to buy a new system. But, if I personally were to buy a new system, I would go for AMD. Intel has made a bad reputation of itself lately, but it is really a decade ago (or more) when Intel misbehaved. It is only now that we see the consequences.

While I can understand that Intel and AMD abondoned some older architectures from before 2010, I think it would have been wise to at least try to provide microcode updates for at least starting from the Core i series (Intel) and the K10 (AMD) onward. And while this may be inacceptable for some companies, due to the performance impact, security may well be a top priority for others. Not to mention private customers.

So I ask you: if you had a 2012 Intel CPU running, and you had planned to keep it running because it's absolutely sufficient for your needs, and security IS a thing for you: What would you buy to replace it with? Intel or AMD?

Not only would it be great to have laws for continued support in such a case, it is IMHO also in the utter most interest of Intel – to show their customers that they can rely on the company and that it is a good idea to buy an Intel processor. Even now that AMD is clearly winning the race with its Ryzen and Threadripper – and AMD is winning without the tricks that Intel apparently used over a decade ago!

----------

## NeddySeagoon

Atha,

You would replace it with an arm or arm64 CPU that did not offer out of order or speculative execution.

Arm is not immune to these thing either but they are less affected than x86.

----------

## Atha

Good point. I would use ARM, but I like to keep my legacy software running as well, and this happens to be DOS games (DOSBox) and Windows games (dual boot with Windows 10). I assume that some companies may have legacy installations (not games!) as well...

But thinking about it: is there an ARM64 laptop, as performant as a Ryzen laptop, with an open architecture (like UEFI or Open Firmware), with a good graphics card, good Linux support and standard connections (NVMe-PCIe, DDR4-DIMMs etc.), and all that at a price comparable to a standard laptop with FullHD display? (A friend just bought a new one after the old laptop died, it did cost around 600$...)

Because last I checked, stuff like the Librem was not having the specs and was quite expensive, even though I do find the concept intriguing. But the Librem is an Intel x86 system again...

Chromebooks? Aren't they locked in some way (firmware) into ChromeOS?

----------

## NeddySeagoon

Atha,

My Acer R13 Chromebook runs arm64 Gentoo.

There is a special dance to get into developer mode and enable non ChromeOS booting but it is documented and you only do it once.

Arm hardware supplied with Windows has secure boot permanently enabled.

That makes booting anything else much harder, so if you want to play with Gentoo on arm64, don't start there.

Is there a Intel/Ryzen laptop that does over 12 hours on a battery charge? 

Arm and x86 laptops aim at different use cases.

----------

## Atha

True. I guess I could do with a Chromebook, and I regularly look into it, but there are two things that keep me away:

Upgradeability. Most Chromebooks have something like 64 GB eMMC, which means it cannot be upgraded. I don't know if there are DIMM slots or if the RAM is also soldered. I say this because I do upgrade RAM and SSDs in my laptops when I find it necessary instead of purchasing a new laptop. Also I have lots and lots of files on my laptop for offline use, I don't use the cloud. Anything less then 512 GB is a nightmare for me, I normally go with 1 (at least) or 2 TB SSDs.

A non-reflective display. Most Chromebooks continue to have only glare displays. I hate this and will only buy a laptop with a non-glare display.

For a laptop-like Chromebook, PCIe-NVMe and DIMM slots on the mainboard, non-glare display, USB-3 and -C connectors as well as an Ethernet RJ-45 connector... I would buy it in an instant if the price isn't too high! I would even sacrafice my "legacy software" for such an ARM64 laptop...

I don't think that manufacturers think that there is a market for such a device. And I frankly don't know. I guess I'm not mainstream. Or too much mainstream, considering that there are plenty of x86 laptops with exactly those specs...

----------

## Ant P.

 *Atha wrote:*   

> There is no way to fix spec_store_bypass, the only mitigation is to disable it. This works for AMD as it does for Intel, by configuring the kernel or by using the appropriate kernel commandline parameter spec_store_bypass_disable=on, e.g. in /etc/default/grub.
> 
> ```
> GRUB_CMDLINE_LINUX="mitigations=auto,nosmt spec_store_bypass_disable=on"
> ```
> ...

 

Didn't know that. I assumed it was a no microcode thing because my zen2 seems to have that workaround by default, but I haven't done anything special to enable it.

----------

## Anon-E-moose

I don't use any cmd line overrides, just the normal config switches.

```
$ ls *

itlb_multihit  l1tf  mds  meltdown  spec_store_bypass  spectre_v1  spectre_v2  tsx_async_abort

/sys/devices/system/cpu/vulnerabilities $ cat *

Not affected

Not affected

Not affected

Not affected

Mitigation: Speculative Store Bypass disabled via prctl and seccomp

Mitigation: usercopy/swapgs barriers and __user pointer sanitization

Vulnerable, IBPB: disabled, STIBP: disabled

Not affected
```

----------

## Tony0945

Nor I. Grub legacy on Phenom II,  reFind on Ryzen & Bulldozer

Phenom II

```
tony@Casti vulnerabilities $ cat *

Not affected

Not affected

Not affected

Not affected

Not affected

Mitigation: usercopy/swapgs barriers and __user pointer sanitization

Vulnerable, STIBP: disabled

Not affected

Not affected

```

Ryzen

```
#  cd /sys/devices/system/cpu/vulnerabilities

MSI /sys/devices/system/cpu/vulnerabilities # cat *

Not affected

Not affected

Not affected

Not affected

Mitigation: Speculative Store Bypass disabled via prctl and seccomp

Mitigation: usercopy/swapgs barriers and __user pointer sanitization

Vulnerable, IBPB: disabled, STIBP: disabled

Not affected

```

Bulldozer

```
Trantor vulnerabilities #  cat *

Not affected

Not affected

Not affected

Not affected

Mitigation: Speculative Store Bypass disabled via prctl and seccomp

Mitigation: usercopy/swapgs barriers and __user pointer sanitization

Vulnerable, STIBP: disabled

Not affected

```

This sounds HIGHLY unlikely and if the attacker is this deep into your machine , you are fscked anyway. Seems more likley on a Windows Machine blindly downloading "updates" and "fixes" from non-Microsoft sources. On a Gentoo machine wouldn't the compiler have to be infected? And the attack code built into the compiler or the kernel?

----------

## Mgiese

as of now I dont use intel anymore, just upgraded to a AMD Ryzen 7 3700X and I must say I am really impressed, with kernel 5.7.2 all vulnerabilities are fixed without taking any extra care :

```
$ vuln

/sys/devices/system/cpu/vulnerabilities/itlb_multihit:Not affected

/sys/devices/system/cpu/vulnerabilities/l1tf:Not affected

/sys/devices/system/cpu/vulnerabilities/mds:Not affected

/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: usercopy/swapgs barriers and __user pointer sanitization

/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline, IBPB: conditional, STIBP: conditional, RSB filling

/sys/devices/system/cpu/vulnerabilities/srbds:Not affected

/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Not affected
```

and by the way, upgrading from simple 4 core without HT to this 16 HT core monster has a very huge impact on compile times...

----------

## Tony0945

 *Mgiese wrote:*   

> and by the way, upgrading from simple 4 core without HT to this 16 HT core monster has a very huge impact on compile times...

 

I went from an Athlon II X3 to Ryzen 2700X. AMAZING!

----------

