| View previous topic :: View next topic |
| Author |
Message |
Atha
Apprentice
Joined: 22 Sep 2004
Posts: 229
|
 Posted: Fri May 25, 2018 1:24 pm Post subject: |
 |
|
Thanks, mv. I was not fully aware that spec_store_bypass_disable=on is needed to get a full i.e. real mitigation.
| Code: | # 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? |
|
| Back to top |
|
 |
ChrisJumper
Advocate
Joined: 12 Mar 2005
Posts: 2390
Location: Germany
|
| Posted: Mon May 28, 2018 9:50 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Atha
Apprentice
Joined: 22 Sep 2004
Posts: 229
|
| Posted: Wed May 30, 2018 7:39 pm Post subject: |
|
|
| 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.) |
|
| Back to top |
|
|
ChrisJumper
Advocate
Joined: 12 Mar 2005
Posts: 2390
Location: Germany
|
| Posted: Tue Jun 05, 2018 8:43 pm Post subject: |
|
|
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: | # 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. |
|
| Back to top |
|
|
ChrisJumper
Advocate
Joined: 12 Mar 2005
Posts: 2390
Location: Germany
|
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9677
Location: almost Mile High in the USA
|
| Posted: Wed Jun 20, 2018 7:26 pm Post subject: |
|
|
| Code: | 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)
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3131
|
| Posted: Wed Jun 20, 2018 7:34 pm Post subject: |
|
|
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? |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Thu Jun 21, 2018 6:21 am Post subject: |
|
|
| 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.) |
|
| Back to top |
|
|
ChrisJumper
Advocate
Joined: 12 Mar 2005
Posts: 2390
Location: Germany
|
| Posted: Sun Jun 24, 2018 11:29 pm Post subject: |
|
|
| 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.
| Code: | 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. :) |
|
| Back to top |
|
|
Mgiese
Veteran
Joined: 23 Mar 2005
Posts: 1607
Location: indiana
|
| Posted: Tue Dec 11, 2018 11:15 pm Post subject: |
|
|
as of today i run gentoo-sources-4.19.8 and the output is as follows :
| Code: | $ 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: |
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Vulnerable
|
_________________
I do not have a Superman complex, for I am God not Superman 
Ryzen9 7950x ; Geforce1650 ; kernel 6.5 ; XFCE |
|
| Back to top |
|
|
j_c_p
Guru
Joined: 30 Aug 2003
Posts: 319
Location: France - Colmar
|
| Posted: Wed Dec 12, 2018 1:50 pm Post subject: |
|
|
| Code: | 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: | | 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 |
_________________
Lian Li PC60 - AMD FX 8300 - Asrock 990FX EXTREME9 - Gigabyte GTX960 G1 Gaming 4Go |
|
| Back to top |
|
|
Mgiese
Veteran
Joined: 23 Mar 2005
Posts: 1607
Location: indiana
|
| Posted: Wed May 15, 2019 6:37 pm Post subject: |
|
|
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: | # 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
_________________
I do not have a Superman complex, for I am God not Superman
Ryzen9 7950x ; Geforce1650 ; kernel 6.5 ; XFCE |
|
| Back to top |
|
|
Mgiese
Veteran
Joined: 23 Mar 2005
Posts: 1607
Location: indiana
|
| Posted: Wed May 15, 2019 9:22 pm Post subject: |
|
|
| Code: | 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: | /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
|
_________________
I do not have a Superman complex, for I am God not Superman
Ryzen9 7950x ; Geforce1650 ; kernel 6.5 ; XFCE |
|
| Back to top |
|
|
Atha
Apprentice
Joined: 22 Sep 2004
Posts: 229
|
| Posted: Mon Nov 11, 2019 7:33 pm Post subject: mitigations=auto |
|
|
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: | | mitigations=auto,nosmt spec_store_bypass_disable=on vsyscall=none init_on_alloc=1 init_on_free=1 |
On Intel:
| Code: | | 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...
_________________
Think for yourself and let others enjoy the privilege of doing so too. – Voltaire |
|
| Back to top |
|
|
elover
Apprentice
Joined: 20 Nov 2019
Posts: 159
Location: Spain
|
| Posted: Tue Jan 14, 2020 5:11 pm Post subject: |
|
|
I seem to have vulnerabilities, don't I?
| Code: | 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] |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54220
Location: 56N 3W
|
| Posted: Tue Jan 14, 2020 5:13 pm Post subject: |
|
|
elover,
You have some and mitigation is in place.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
elover
Apprentice
Joined: 20 Nov 2019
Posts: 159
Location: Spain
|
| Posted: Tue Jan 14, 2020 5:19 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2717
|
| Posted: Tue Jan 14, 2020 8:38 pm Post subject: |
|
|
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
/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 |
|
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Tue Jan 14, 2020 11:06 pm Post subject: |
|
|
| Code: | 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? |
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2717
|
| Posted: Tue Jan 14, 2020 11:10 pm Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Tue Jan 14, 2020 11:14 pm Post subject: |
|
|
| Ionen wrote: | | Your BIOS is likely already updating it but unlikely to be latest. |
I do keep the BIOS updated. |
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2717
|
| Posted: Tue Jan 14, 2020 11:20 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21607
|
| Posted: Wed Jan 15, 2020 1:36 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
The Main Man
Veteran
Joined: 27 Nov 2014
Posts: 1165
Location: /run/user/1000
|
| Posted: Wed Jan 15, 2020 10:07 am Post subject: |
|
|
| 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
/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 ? |
|
| Back to top |
|
|
Atha
Apprentice
Joined: 22 Sep 2004
Posts: 229
|
| Posted: Wed Jan 15, 2020 7:38 pm Post subject: |
|
|
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.
_________________
Think for yourself and let others enjoy the privilege of doing so too. – Voltaire |
|
| Back to top |
|
|
|
Networking & Security
