spectre and meltdown questions

[Atha]

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

Code: Select all

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

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]

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!

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.

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

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:

Code: Select all

# 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/ke ... d997d46a19

Some more Links:

http://blog.cyberus-technology.de/posts ... ility.html
https://www.intel.com/content/www/us/en ... 00145.html
https://cve.mitre.org/cgi-bin/cvename.c ... -2018-3665 (as i post this, its still reserved and empty).

[eccerr0r]

Code: Select all

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

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]

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.

Code: Select all

 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 :

Code: Select all

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

Code: Select all

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

[j_c_p]

Code: Select all

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

Code: Select all

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 :

Code: Select all

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

Code: Select all

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

Code: Select all

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

Code: Select all

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

On Intel:

Code: Select all

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?

Code: Select all

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]

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

$ 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
/sys/devices/system/cpu/vulnerabilities/mds:Vulnerable; SMT vulnerable
/sys/devices/system/cpu/vulnerabilities/meltdown:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable, IBPB: disabled, STIBP: disabled
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Vulnerable

[Tony0945]

Code: Select all

 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]

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.

[Tony0945]

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

I do keep the BIOS updated.

[Ionen]

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]

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

$ 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
/sys/devices/system/cpu/vulnerabilities/mds:Vulnerable; SMT vulnerable
/sys/devices/system/cpu/vulnerabilities/meltdown:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable, IBPB: disabled, STIBP: disabled
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort: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/ ... ectre.html for details.