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 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 4/10/19 1:01 PM, Lars Marowsky-Bree wrote:

On 2019-04-10T12:31: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. 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

On 2019-04-10T13:18:45, Michael Pujos 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

On Sat, May 11, 2019 at 8: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.

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 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 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 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 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 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/
-------------------------------------------------------------------
<> (Raistlin Majere)

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