[opensuse-factory] Huge single-core performance loss with spectre v2 mitigation enabled (it's the default)
I use current TW on a Lenovo P72 laptop with a Core i7-8850H CPU. Some time ago, I decided it to compare Geekbench scores between kernel with (this is the default) and without vulnerability mitigations disabled. To disable mitigations, I used these kernel parameters: noibrs noibpb nopti https://browser.geekbench.com/v4/cpu/compare/12738676?baseline=12738264 nospectre_v1 I was astonished to see that the single-core score mitigated was 4579 vs 5843 the score with mitigations disabled, resulting in 21.6% performance loss ! Multi-core performance is unaffected. I finally isolated to nospectre_v2, which if specified is causing that huge bump in performance. So the spectre v2 mitigation is causing that huge single core performance loss. Geekbench comparison: default kernel vs kernel with nospectre_v2: https://browser.geekbench.com/v4/cpu/compare/12738751?baseline=12738676 Today, I tried Geekbench on Fedora 30 beta that got recently released. Without changing any kernel parameter it has the same performance than TW with nospectre_v2 !: TW default vs Fedora default: https://browser.geekbench.com/v4/cpu/compare/12738751?baseline=12738264 TW nospectre_v2 vs Fedora default https://browser.geekbench.com/v4/cpu/compare/12738676?baseline=12738264 So basically, TW has about 20% less single core performance by default, which in my opinion is some kind of bug. This seems to me a good candidate to explain why TW trailing in Phoronix recent benchmarks. And maybe an indication that there may be a performance issue with spectre v2 mitigation only in TW. For reference, here is the output of spectre-metldown-checker.sh on all systems compared: TW default: https://termbin.com/8p7z TW nospectre_v2: https://termbin.com/bb6t Fedora default: http://termbin.com/0u7o -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 4/10/19 1:46 AM, Michael Pujos wrote:
To disable mitigations, I used these kernel parameters:
noibrs noibpb nopti https://browser.geekbench.com/v4/cpu/compare/12738676?baseline=12738264 nospectre_v1
EDIT: should read: noibrs noibpb nopti nospectre_v2 nospectre_v1 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 2019-04-10 at 01:46 +0200, Michael Pujos wrote:
I finally isolated to nospectre_v2, which if specified is causing that huge bump in performance. So the spectre v2 mitigation is causing that huge single core performance loss.
For the record, there are hints that the spectre v2 mitigation is to blame for slowdowns in Gnome Shell on TW: https://bugzilla.opensuse.org/show_bug.cgi?id=1112824 Robert -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10. 04. 19, 1:46, Michael Pujos wrote:
And maybe an indication that there may be a performance issue with spectre v2 mitigation only in TW.
We do also IBRS, others AFAIK don't. What's in your /sys/devices/system/cpu/vulnerabilities/spectre_v2 ? thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 4/10/19 10:02 AM, Jiri Slaby wrote:
On 10. 04. 19, 1:46, Michael Pujos wrote:
And maybe an indication that there may be a performance issue with spectre v2 mitigation only in TW. We do also IBRS, others AFAIK don't.
What's in your /sys/devices/system/cpu/vulnerabilities/spectre_v2 ?
thanks,
Mitigation: Indirect Branch Restricted Speculation, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling Fedora 30 has spectre v2 mitigation enabled by default, but it does not affect single core performance. Here's the relevant differences in spectre-meltdown-checker.sh output (I posted the ful output in first post) for stock kernel (no parameter) in both cases. This confirms TW using IBRS vs Fedora not using it. In my opinion, that 20% performace loss in single-core by default (apparently caused by IBRS) is unacceptable. I did not buy a powerful laptop to see its performance reduced so much. And it will make TW look bad in benchmarks. SOmething should be done about it. --------- Tumbleweed: CVE-2017-5715 aka 'Spectre Variant 2, branch target injection' * Mitigated according to the /sys interface: YES (Mitigation: Indirect Branch Restricted Speculation, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling) * Mitigation 1 * Kernel is compiled with IBRS support: YES * IBRS enabled and active: YES (for kernel and firmware code) * Kernel is compiled with IBPB support: YES * IBPB enabled and active: YES * Mitigation 2 * Kernel has branch predictor hardening (arm): NO * Kernel compiled with retpoline option: YES * Kernel supports RSB filling: YES
STATUS: NOT VULNERABLE (IBRS + IBPB are mitigating the vulnerability)
--------- Fedora: CVE-2017-5715 aka 'Spectre Variant 2, branch target injection' * Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling) * Mitigation 1 * Kernel is compiled with IBRS support: YES * IBRS enabled and active: YES (for kernel and firmware code) * Kernel is compiled with IBPB support: YES * IBPB enabled and active: YES * Mitigation 2 * Kernel has branch predictor hardening (arm): NO * Kernel compiled with retpoline option: YES * Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation) * Kernel supports RSB filling: YES
STATUS: NOT VULNERABLE (Full retpoline + IBPB are mitigating the vulnerability)
----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10. 04. 19, 11:58, Michael Pujos wrote:
In my opinion, that 20% performace loss in single-core by default (apparently caused by IBRS) is unacceptable. I did not buy a powerful laptop to see its performance reduced so much.
You should complain to Intel that you threw your money out of window, not to us.
And it will make TW look bad in benchmarks. SOmething should be done about it.
So spectre_v2=retpoline,generic makes the benchmarks comparable? thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 4/10/19 12:08 PM, Jiri Slaby wrote:
On 10. 04. 19, 11:58, Michael Pujos wrote:
In my opinion, that 20% performace loss in single-core by default (apparently caused by IBRS) is unacceptable. I did not buy a powerful laptop to see its performance reduced so much. You should complain to Intel that you threw your money out of window, not to us.
Well, I'm not even going to respond to that.
And it will make TW look bad in benchmarks. SOmething should be done about it. So spectre_v2=retpoline,generic makes the benchmarks comparable?
Yes it (expectedly) restored performance: https://browser.geekbench.com/v4/cpu/compare/12738751?baseline=12743826 spectre_v2=retpoline,generic should be the default in my opinion. If good guys at Fedora (and other distros) are using it, so can openSUSE. Unless the people in charge want to murder single-core performance on people's computers and lament why it always comes last in Phoronix (and other) benchmarks. Thanks for taking this into consideration. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019-04-10T12:31:31, Michael Pujos <pujos.michael@gmail.com> wrote:
spectre_v2=retpoline,generic should be the default in my opinion. If good guys at Fedora (and other distros) are using it, so can openSUSE. Unless the people in charge want to murder single-core performance on people's computers and lament why it always comes last in Phoronix (and other) benchmarks.
It probably makes sense to discuss why "we" choose these settings vs what Fedora picked. I'm not clear that, when it comes to security, we should automatically go with those just because Fedora did and they are faster. Regards, Lars -- SUSE Linux GmbH, GF: Felix Imendörffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nürnberg) "Architects should open possibilities and not determine everything." (Ueli Zbinden) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 4/10/19 1:01 PM, Lars Marowsky-Bree wrote:
On 2019-04-10T12:31:31, Michael Pujos <pujos.michael@gmail.com> wrote:
spectre_v2=retpoline,generic should be the default in my opinion. If good guys at Fedora (and other distros) are using it, so can openSUSE. Unless the people in charge want to murder single-core performance on people's computers and lament why it always comes last in Phoronix (and other) benchmarks. It probably makes sense to discuss why "we" choose these settings vs what Fedora picked. I'm not clear that, when it comes to security, we should automatically go with those just because Fedora did and they are faster.
Maybe, but the defaults should not incur a 20% performance loss. Especially since there is an alternate spectre v2 mitigation. Maybe such loss is tolerable for datacenters as they can throw more hardware at it, but not on most personal computers. I really hope the defaults will be changed to something more sensible. I vaguely remember a post by Linus Torvalds stating that a mitigation that has a huge performance loss should be turned off by default. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Maybe, but the defaults should not incur a 20% performance loss.
I'd suggest the installer asks in a page "security and performance preferences". This is the second thread in a few weeks that makes me think such a page would be good to have. Joachim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019-04-10T13:18:45, Michael Pujos <pujos.michael@gmail.com> wrote:
It probably makes sense to discuss why "we" choose these settings vs what Fedora picked. I'm not clear that, when it comes to security, we should automatically go with those just because Fedora did and they are faster. Maybe, but the defaults should not incur a 20% performance loss. Especially since there is an alternate spectre v2 mitigation.
The default should be complete mitigation. The performance impact is not openSUSE's fault, but Intel's. Sorry. Disabling them needs to be a user choice, that admittedly needs to be made easier and with clear feedback on the performance/security trade-offs. Regards, Lars -- Architect SDS, Distinguished Engineer SUSE Linux GmbH, GF: Felix Imendörffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nürnberg) "Architects should open possibilities and not determine everything." (Ueli Zbinden) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
The default should be complete mitigation. The performance impact is not openSUSE's fault, but Intel's. Sorry.
Disabling them needs to be a user choice, that admittedly needs to be made easier and with clear feedback on the performance/security trade-offs.
This needs to be an option on install. The default should be to let the user chose, not to give them slowdowns for no good reason as spectre can never be fully mitigated with software. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, May 11, 2019 at 8:19 PM, simonizor <simonizorr@gmail.com> wrote:
The default should be complete mitigation. The performance impact is not openSUSE's fault, but Intel's. Sorry.
Disabling them needs to be a user choice, that admittedly needs to be made easier and with clear feedback on the performance/security trade-offs.
This needs to be an option on install. The default should be to let the user chose, not to give them slowdowns for no good reason as spectre can never be fully mitigated with software.
Actually, already is: https://github.com/yast/yast-bootloader/pull/562 You can test it out, it shows up in summary screen during installation ;) LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 5/11/19 2:19 PM, simonizor wrote:
The default should be complete mitigation. The performance impact is not openSUSE's fault, but Intel's. Sorry.
Disabling them needs to be a user choice, that admittedly needs to be made easier and with clear feedback on the performance/security trade-offs.
This needs to be an option on install. The default should be to let the user chose, not to give them slowdowns for no good reason as spectre can never be fully mitigated with software.
Simonizor, I've read that Intel has addressed the spectre issue with a hardware change in their newer CPUs. That is the only way. Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 21/05/2019 19.05, Roman Bysh wrote:
On 5/11/19 2:19 PM, simonizor wrote:
The default should be complete mitigation. The performance impact is not openSUSE's fault, but Intel's. Sorry.
Disabling them needs to be a user choice, that admittedly needs to be made easier and with clear feedback on the performance/security trade-offs.
This needs to be an option on install. The default should be to let the user chose, not to give them slowdowns for no good reason as spectre can never be fully mitigated with software.
Simonizor,
I've read that Intel has addressed the spectre issue with a hardware change in their newer CPUs. That is the only way.
Or switching to AMD. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 5/21/19 4:54 PM, Carlos E.R. wrote:
On 21/05/2019 19.05, Roman Bysh wrote:
On 5/11/19 2:19 PM, simonizor wrote:
The default should be complete mitigation. The performance impact is not openSUSE's fault, but Intel's. Sorry.
Disabling them needs to be a user choice, that admittedly needs to be made easier and with clear feedback on the performance/security trade-offs.
This needs to be an option on install. The default should be to let the user chose, not to give them slowdowns for no good reason as spectre can never be fully mitigated with software.
Simonizor,
I've read that Intel has addressed the spectre issue with a hardware change in their newer CPUs. That is the only way.
Or switching to AMD.
Absolutely. I was thinking about building a new desktop with the Ryzen 2700x with RX580. And it's immune from the vulnerabilities that Intel is experiencing. Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 22/05/2019 21.26, Roman Bysh wrote:
On 5/21/19 4:54 PM, Carlos E.R. wrote:
On 21/05/2019 19.05, Roman Bysh wrote:
On 5/11/19 2:19 PM, simonizor wrote:
The default should be complete mitigation. The performance impact is not openSUSE's fault, but Intel's. Sorry.
Disabling them needs to be a user choice, that admittedly needs to be made easier and with clear feedback on the performance/security trade-offs.
This needs to be an option on install. The default should be to let the user chose, not to give them slowdowns for no good reason as spectre can never be fully mitigated with software.
Simonizor,
I've read that Intel has addressed the spectre issue with a hardware change in their newer CPUs. That is the only way.
Or switching to AMD.
Absolutely. I was thinking about building a new desktop with the Ryzen 2700x with RX580.
Wow. Same combination I'm looking at.
And it's immune from the vulnerabilities that Intel is experiencing.
Cheers! -- Cheers / Saludos,
Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 5/22/19 4:11 PM, Carlos E. R. wrote:
On 22/05/2019 21.26, Roman Bysh wrote:
On 5/21/19 4:54 PM, Carlos E.R. wrote:
On 21/05/2019 19.05, Roman Bysh wrote:
On 5/11/19 2:19 PM, simonizor wrote:
The default should be complete mitigation. The performance impact is not openSUSE's fault, but Intel's. Sorry.
Disabling them needs to be a user choice, that admittedly needs to be made easier and with clear feedback on the performance/security trade-offs.
This needs to be an option on install. The default should be to let the user chose, not to give them slowdowns for no good reason as spectre can never be fully mitigated with software.
Simonizor,
I've read that Intel has addressed the spectre issue with a hardware change in their newer CPUs. That is the only way.
Or switching to AMD.
Absolutely. I was thinking about building a new desktop with the Ryzen 2700x with RX580.
Wow. Same combination I'm looking at.
Great. I'm keeping an eye out for *towers* that are already put together and barebones PCs. Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 22/05/2019 22.24, Roman Bysh wrote:
On 5/22/19 4:11 PM, Carlos E. R. wrote:
On 22/05/2019 21.26, Roman Bysh wrote:
On 5/21/19 4:54 PM, Carlos E.R. wrote:
On 21/05/2019 19.05, Roman Bysh wrote:
On 5/11/19 2:19 PM, simonizor wrote:
> The default should be complete mitigation. The performance impact is not > openSUSE's fault, but Intel's. Sorry. > > Disabling them needs to be a user choice, that admittedly needs to be > made easier and with clear feedback on the performance/security > trade-offs.
This needs to be an option on install. The default should be to let the user chose, not to give them slowdowns for no good reason as spectre can never be fully mitigated with software.
Simonizor,
I've read that Intel has addressed the spectre issue with a hardware change in their newer CPUs. That is the only way.
Or switching to AMD.
Absolutely. I was thinking about building a new desktop with the Ryzen 2700x with RX580.
Wow. Same combination I'm looking at.
Great. I'm keeping an eye out for *towers* that are already put together and barebones PCs.
I seek to keep the box, but replace the MB, CPU, RAM, and GPU. Maybe I will have to replace the PSU as well. But I'm afraid this is OffTopic here, so if you wish to continue, just reply on the standard opensuse.org mail list or the offtopic one. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 5/22/19 4:33 PM, Carlos E.R. wrote:
On 22/05/2019 22.24, Roman Bysh wrote:
On 5/22/19 4:11 PM, Carlos E. R. wrote:
On 22/05/2019 21.26, Roman Bysh wrote:
On 5/21/19 4:54 PM, Carlos E.R. wrote:
On 21/05/2019 19.05, Roman Bysh wrote:
On 5/11/19 2:19 PM, simonizor wrote: >> The default should be complete mitigation. The performance impact is not >> openSUSE's fault, but Intel's. Sorry. >> >> Disabling them needs to be a user choice, that admittedly needs to be >> made easier and with clear feedback on the performance/security >> trade-offs. > > This needs to be an option on install. The default should be to let the user chose, not to give them slowdowns for no good reason as spectre > can never be fully mitigated with software. > Simonizor,
I've read that Intel has addressed the spectre issue with a hardware change in their newer CPUs. That is the only way.
Or switching to AMD.
Absolutely. I was thinking about building a new desktop with the Ryzen 2700x with RX580.
Wow. Same combination I'm looking at.
Great. I'm keeping an eye out for *towers* that are already put together and barebones PCs.
I seek to keep the box, but replace the MB, CPU, RAM, and GPU. Maybe I will have to replace the PSU as well.
But I'm afraid this is OffTopic here, so if you wish to continue, just reply on the standard opensuse.org mail list or the offtopic one.
Right! Very strict on this ML ;-) Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10. 04. 19, 12:31, Michael Pujos wrote:
On 4/10/19 12:08 PM, Jiri Slaby wrote:
And it will make TW look bad in benchmarks. SOmething should be done about it. So spectre_v2=retpoline,generic makes the benchmarks comparable?
Yes it (expectedly) restored performance:
https://browser.geekbench.com/v4/cpu/compare/12738751?baseline=12743826
spectre_v2=retpoline,generic should be the default in my opinion. If good guys at Fedora (and other distros) are using it, so can openSUSE.
They don't even have IBRS support in their kernels AFAIR. retpolines are not complete protection on skylake+. Coffee lake has EIBRS which should restore the performance a bit. Perhaps, one day, Intel will add EIBRS support also to Skylake, if possible (I don't remember the details). What processor model do you have?
Unless the people in charge want to murder single-core performance on people's computers and lament why it always comes last in Phoronix (and other) benchmarks.
We don't lament on Phoronix results. Phoronix results are mostly crap not requiring a single comment. thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 4/10/19 1:31 PM, Jiri Slaby wrote:
They don't even have IBRS support in their kernels AFAIR.
retpolines are not complete protection on skylake+. Coffee lake has EIBRS which should restore the performance a bit. Perhaps, one day, Intel will add EIBRS support also to Skylake, if possible (I don't remember the details).
What processor model do you have?
It's a Core i7-8850H, so Cofee lake. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 2019-04-10 at 13:31 +0200, Jiri Slaby wrote:
> On 10. 04. 19, 12:31, Michael Pujos wrote:
> >
> > spectre_v2=retpoline,generic should be the default in my opinion.
> > If
> > good guys at Fedora (and other distros) are using it, so can
> > openSUSE.
>
> They don't even have IBRS support in their kernels AFAIR.
>
FWIW, they seem to have that now, at least, according to this:
> Fedora default: http://termbin.com/0u7o
* Kernel is compiled with IBRS support: YES
* IBRS enabled and active: YES (for kernel and firmware code)
Out of curiosity, I installed kernel-vanilla on Tumbleweed, and there I
have:
$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling
# sudo spectre-meltdown-checker.sh
...
CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
* Mitigation 2
> STATUS: NOT VULNERABLE (Full retpoline + IBPB are mitigating the vulnerability)
Which confirms (if there were any need for that) that it's our own
doing, e.g., in kernel-default...
> retpolines are not complete protection on skylake+.
>
... For this reason, indeed. :-)
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)
On 10. 04. 19, 17:56, Dario Faggioli wrote: > On Wed, 2019-04-10 at 13:31 +0200, Jiri Slaby wrote: >> On 10. 04. 19, 12:31, Michael Pujos wrote: >>> >>> spectre_v2=retpoline,generic should be the default in my opinion. >>> If >>> good guys at Fedora (and other distros) are using it, so can >>> openSUSE. >> >> They don't even have IBRS support in their kernels AFAIR. >> > FWIW, they seem to have that now, at least, according to this: > >> Fedora default: http://termbin.com/0u7o > * Kernel is compiled with IBRS support: YES > * IBRS enabled and active: YES (for kernel and firmware code) The check script contains a bug: https://github.com/speed47/spectre-meltdown-checker/issues/275 It considers every occurence of "IBRS" as "IBRS is engaged". Even if it is only "IBRS_FW". >> STATUS: NOT VULNERABLE (Full retpoline + IBPB are mitigating the vulnerability) > > Which confirms (if there were any need for that) that it's our own > doing, e.g., in kernel-default... Of course, it's my patches "to blame": patches.suse/0001-x86-speculation-Add-basic-IBRS-support-infrastructur.patch patches.suse/0002-x86-speculation-Add-inlines-to-control-Indirect-Bran.patch patches.suse/0003-x86-idle-Control-Indirect-Branch-Speculation-in-idle.patch patches.suse/0004-x86-enter-Create-macros-to-restrict-unrestrict-Indir.patch patches.suse/0005-x86-enter-Use-IBRS-on-syscall-and-interrupts.patch thanks, -- js suse labs
For what it's worth, spectre can never be fully mitigated with software. https://www.i-programmer.info/news/149-security/12556-google-says-spectre-an... Not only is pretty much every current CPU vulnerable:
"As a result of our work on Spectre, we now know that information leaks may affect all processors that perform speculation, regardless of instruction set architecture, manufacturer, clock speed, virtualization, or timer resolution."
"Vulnerabilities from speculative execution are not processor bugs but are more properly considered fundamental design flaws, since they do not arise from errata. Troublingly, these fundamental design flaws were overlooked by top minds for decades."
But they always will be:
"...we developed proofs of concept in C++, JavaScript, and WebAssembly for all the reported vulnerabilities. We were able to leak over 1KB/s from variant 1 gadgets in C++ using rdtsc with 99.99% accuracy and over 10B/s from JavaScript using a low resolution timer."
This alone causes openSUSE's GNOME install to be the slowest GNOME install on any distro of Linux anywhere. This is a bug that needs to be fixed. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10. 04. 19, 1:46, Michael Pujos wrote:
TW default: https://termbin.com/8p7z TW nospectre_v2: https://termbin.com/bb6t Fedora default: http://termbin.com/0u7o
Also, fedora does not have up-to-date microcode for your CPU (Tumbleweed does) according to the links above. Even then, your CPU is Coffee Lake and that should have support for EIBRS, but it does not according to the output: * Enhanced IBRS (IBRS_ALL) * CPU indicates ARCH_CAPABILITIES MSR availability: NO * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO I am not sure what is going on with your CPU here. Maybe EIBRS was not released for your CPU yet. thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 4/10/19 1:53 PM, Jiri Slaby wrote:
On 10. 04. 19, 1:46, Michael Pujos wrote:
TW default: https://termbin.com/8p7z TW nospectre_v2: https://termbin.com/bb6t Fedora default: http://termbin.com/0u7o Also, fedora does not have up-to-date microcode for your CPU (Tumbleweed does) according to the links above.
Even then, your CPU is Coffee Lake and that should have support for EIBRS, but it does not according to the output: * Enhanced IBRS (IBRS_ALL) * CPU indicates ARCH_CAPABILITIES MSR availability: NO * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
I am not sure what is going on with your CPU here. Maybe EIBRS was not released for your CPU yet.
thanks,
Interesting. No idea either why it is not supported. The laptop is up to date in term of BIOS and other system updates (I updated if fully with Lenovo Vantage on Windows 10). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 2019-04-10 at 14:35 +0200, Michael Pujos wrote:
On 4/10/19 1:53 PM, Jiri Slaby wrote:
On 10. 04. 19, 1:46, Michael Pujos wrote:
Even then, your CPU is Coffee Lake and that should have support for EIBRS, but it does not according to the output: * Enhanced IBRS (IBRS_ALL) * CPU indicates ARCH_CAPABILITIES MSR availability: NO * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
I am not sure what is going on with your CPU here. Maybe EIBRS was not released for your CPU yet.
thanks,
Interesting. No idea either why it is not supported. The laptop is up to date in term of BIOS and other system updates (I updated if fully with Lenovo Vantage on Windows 10).
I guess you have the ucode-intel package installed? On my Tumbleweed, that is: $ rpm -qa|grep ucode-intel ucode-intel-20190312-1.1.x86_64 You can also check whether microcode is being updated or not during boot, e.g.: $ dmesg |grep -i microcode [ 0.000000] microcode: microcode updated early to revision 0x9a, date = 2018-07-16 [ 1.484930] microcode: sig=0x806e9, pf=0x40, revision=0x9a [ 1.484955] microcode: Microcode Update Driver: v2.2. All that being said, I don't remember which CPU families were expected to have "Enhanced IBRS". I don't have it neither on i7-7560U nor on W-2125 (Kaby Lake and Skylake, I think). Regards -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <<This happens because _I_ choose it to happen!>> (Raistlin Majere)
On 4/10/19 4:42 PM, Dario Faggioli wrote:
I guess you have the ucode-intel package installed? On my Tumbleweed, that is: $ rpm -qa|grep ucode-intel ucode-intel-20190312-1.1.x86_64
Yes, I have this package installed. Seems to be loaded fine: dmesg |grep -i microcode [ 0.000000] microcode: microcode updated early to revision 0xaa, date = 2018-12-12 [ 2.741806] microcode: sig=0x906ea, pf=0x20, revision=0xaa [ 2.742548] microcode: Microcode Update Driver: v2.2. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
<https://make-linux-fast-again.com/> -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (13)
-
cagsm -
Carlos E. R. -
Carlos E.R. -
Dario Faggioli -
Dario Faggioli -
Jiri Slaby -
Joachim Wagner -
Lars Marowsky-Bree -
Michael Pujos -
Robert Munteanu -
Roman Bysh -
simonizor -
Stasiek Michalski