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

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