Intel/Linux 20% slowdown

[rufwoof]

Linux (and Windows) Intel set to get 20% slower

https://www.theregister.co.uk/2018/01/0 ... sign_flaw/

A fundamental design flaw in Intel's processor chips has forced a significant redesign of the Linux and Windows kernels to defang the chip-level security bug.

AMD/Unix (OpenBSD) here

[Sailor Enceladus]

the flaw is in the Intel x86-64 hardware

Oh good. My Intel cpu is 32-bit

[fabrice_035]

bad new!

I try with intel tool detection vulnerability

Code: Select all

Application Version: 1.0.0.152
Scan date: 2018-01-03 16:08:00 GMT

*** Host Computer Information ***
Name: puppypc225xx
Manufacturer: Dell Inc.
Model: Studio XPS 1640
Processor Name: Intel(R) Core(TM)2 Duo CPU     P8600  @ 2.40GHz
OS Version:    (3.14.79)

*** Risk Assessment ***
Detection Error: This system may be vulnerable,
  either the Intel(R) MEI/TXEI driver is not installed
  (available from your system manufacturer)
  or the system manufacturer does not permit access
  to the ME/TXE from the host driver.

For more information refer to the INTEL-SA-00086 Detection Tool Guide or the
  Intel Security Advisory Intel-SA-00086 at the following link:
  https://www.intel.com/sa-00086-support

https://downloadcenter.intel.com/download/27150?v=t

[fabrice_035]

The are new performance after patch :

[Sage]

Yes, the WIntel cartel scores again! If you weren't at least a late teenager in the late end of the 1980's, you may be unaware that Intel has consistently screwed up for three decades? Always with the cooperation of their $$$-sapping companions in Redmond, themselves guilty felons by the USDoJ.
Nothing, but nothing, has stopped the punters from snapping up their cr*p, particularly in their home nation which has had other more successful fabricators, some of which were sent to the wall by this misguided bunch of greedy capitalists.

[8Geee]

I find it disturbing that Intel denies improper programming of its CPU. Basically, Intel says their chips have the acceleration flaw, and its due to trying to predict the next call to HW/SW/Graphics. After all it IS unknown, and the CPU is looking for a performance edge over its rival.

IMHO not only do desktop/laptop CPU's have this "flaw" all smartphones definately have it, and HERE is where other vendors are at risk... ARM especially, since it farms some work to Intel.

Well, thats Intel Management Engine, and now predictive (ahem, accelerated) processing.

BTW, now is a good time to check your browser's predictive behavior... things like "auto-complete", for example.

Regards
8Geee

[belham2]

....Better re-think those thoughts that AMD is not affected by processor gobblins peaking their heads up. It sort of stinks that both AMD and Intel, it appears, have known about their specific cpu vulnerabilities for some time and have chosen to do nothing. There is no other explanation as there is NO excuse in any universe for not knowing about possible bypasses of "memory isolation mechanisms". Damn, this behavior almost makes Microsoft look saintly all these decades releasing OSes with full knowledge they all were (and still are) vulnerable.

http://www.securityweek.com/intel-amd-c ... vices-risk

[Sky Aisling]

Here's another article about the 'holey' chip.

https://discuss.howtogeek.com/t/a-huge- ... soon/66686

[bark_bark_bark]

the flaw is in the Intel x86-64 hardware

Oh good. My Intel cpu is 32-bit

This issue has been around since the 90s apprantly

[Sailor Enceladus]

bad new!

I try with intel tool detection vulnerability

Code: Select all

Application Version: 1.0.0.152
Scan date: 2018-01-03 16:08:00 GMT

*** Host Computer Information ***
Name: puppypc225xx
Manufacturer: Dell Inc.
Model: Studio XPS 1640
Processor Name: Intel(R) Core(TM)2 Duo CPU     P8600  @ 2.40GHz
OS Version:    (3.14.79)

*** Risk Assessment ***
Detection Error: This system may be vulnerable,
  either the Intel(R) MEI/TXEI driver is not installed
  (available from your system manufacturer)
  or the system manufacturer does not permit access
  to the ME/TXE from the host driver.

For more information refer to the INTEL-SA-00086 Detection Tool Guide or the
  Intel Security Advisory Intel-SA-00086 at the following link:
  https://www.intel.com/sa-00086-support

https://downloadcenter.intel.com/download/27150?v=t

I think that is something else? The one for this thread seems to be called SA-00088:
https://security-center.intel.com/advis ... geid=en-fr

I think what your error is telling you, is that Intel has no idea if you're vulnerable to SA-00086 or not because it can't find the driver MEI/TXEI it needs to test further (at least that is my first guess from the label "Detection Error" and it's description).

[bigpup]

Now you know how they are going to talk you into buying the next generation newest processor and Windows 11.

If you build it so it never breaks. They will only buy it one time!!

[Keisha]

Hello all, long time no see.

According to
https://www.postgresql.org/message-id/2 ... narazel.de

you can do what the patchset will do by setting pti=on (pti = page table isolation) in the kernel line of the grub bootloader.

At work I use a dual xeon e5-2696 v3, running Fedora 26, nice fast number-cruncher.

Hardinfo 0.6-alpha benchmark results on this machine with and without pti=on, average of three runs:

Without pti=on:
CPU Blowfish 0.28 seconds
CPU CryptoHash 3008.91 MiB/second
CPU Fibonacci 1.13 seconds
CPU N-Queens 26.97 seconds
CPU ZLib 5.75 seconds
FPU FFT 0.78 seconds
FPU Raytracing 29.84 seconds
GPU Drawing 21,815.72 HIMarks

With pti=on:
CPU Blowfish 0.29 seconds
CPU CryptoHash 2652 MiB/second
CPU Fibonacci 1.13 seconds
CPU N-Queens 27.04 seconds
CPU ZLib 5.86 seconds
FPU FFT 0.78 seconds
FPU Raytracing 42.42 seconds
GPU Drawing 22,494 HIMarks

CPU CryptoHash shows a 12% performance loss.
FPU Raytracing shows a 30% performance loss.

All other benchmarks, essentially the same. Subjectively, the machine doesn't feel any slower.

Could this translate to a significant advantage of AMD over Intel in product sales going forward?

[8Geee]

based upon the previous post... is this something that can be added to extlinux_conf?

Regards
8Geee

[s243a]

CPU CryptoHash shows a 12% performance loss.
FPU Raytracing shows a 30% performance loss.

All other benchmarks, essentially the same. Subjectively, the machine doesn't feel any slower.

Could this translate to a significant advantage of AMD over Intel in product sales going forward?

This is because the CPU is probably not the main bottleneck on your machine. I saw something that compared the growth rate of cpu performance to ram speeds and ram is falling behind in terms of More's law. I suspect this applies to non-volaitle storage as well.

This is of course my arm-chair opnion.

As an a-side note, I think that gameing the CPU specs by hiding a security valnrabilty is fraud. However, so is much of marketing and little is done about it.

Another random thought, devices are getting smaller and smaller and have less surface area to disapate heat. This slows down CPUs. If this slows down the CPU enough then maybe it will run as slow as the rest of the components.

[Keisha]

based upon the previous post... is this something that can be added to extlinux_conf?

I use grub2 and it's been a long time since I used extlinux, but I imagine you can.

[Keisha]

Another random thought, devices are getting smaller and smaller and have less surface area to disapate heat. This slows down CPUs. If this slows down the CPU enough then maybe it will run as slow as the rest of the components.

The above benchmarks were run with Fedora's default Powersave governor.

I just used CPUFreqUtility to set the CPU's to run with the Performance governor and by raising the minimum frequency to 3.0 GHz the CPU CryptoHash score rose to 3894 with pti=on. Which is 23% faster than with pti=off on the Powersave governor.

However FPU Raytracing on the Performance governor with minimum frequency set as above slowed down to 47 seconds. Meanwhile, gkrellm showed the cpu temps rising to 140+. The temps never passed 130 on FPU Raytracing with the default Powersave governor.

Perhaps, as you suggest, thermal throttling is happening in FPU Raytracing.

The CPU's on this machine are cooled only by air. Next week I'll install decent liquid cooling CPU heatsinks and then benchmark them again, with and without pti=on, trying both governors.

If, in order to compete against AMD's Ryzen and Epyc CPU's, Intel Xeon CPU's must use a performance governor and liquid cooling...then Intel is facing catastrophe.

I wonder if the CEO of Intel acted on insider foreknowledge of this evidently catastrophic bug when he sold off all his Intel stock, retaining only just enough to qualify to keep his CEO job, last November?--see
https://finance.yahoo.com/news/intel-ap ... 00267.html

[Sky Aisling]

[s243a]

[Keisha]

Well, I'll try to answer this; bear in mind, I am not an expert...

My reading of all the news leads me to believe the short answer depends on whether you have an AMD or Intel CPU.

The most succinct overview I have found is here:
https://mybroadband.co.za/news/hardware ... -know.html

But...

AMD CPU's are not vulnerable to any of these attacks, according to AMD's own statement issued yesterday (https://www.cnbc.com/2018/01/03/amd-reb ... chips.html) (***EDITED: AMD has admitted that at least some AMD CPU's are vulnerable to Spectre #1. A kernel patch is needed to fix the vulnerability. Exactly what this patch is, I don't yet know. AMD says performance is not affected by the patch.***). Core Linux developers Linus Torvalds and Thomas Gleixner evidently believe AMD's assurances (***EDITED: insofar as #3, "Meltdown."), see https://www.phoronix.com/scan.php?page= ... le-x86-PTI.

If you have an Intel CPU then I believe the answer is "yes, the bug allowing the two Spectre and one Meltdown types of attacks does affect Puppy run from a Live CD." I believe so since the vulnerability is at the level of the CPU and an attack can be introduced either at the level of the OS (through a java or flash script introduced through the browser, or via other infected software downloaded and run in the current session) or by addressing the CPU directly over the internet connection via the route described at http://murga-linux.com/puppy/viewtopic.php?t=112465 (***EDITED: which involves the remote management capabilities of Intel chipsets. Apparently these can be at least partially turned off by patching the BIOS***).

If you have the misfortune, like most people, to be using an Intel CPU, then starting Puppy with the pti=on parameter will thwart the Spectre and Meltdown attacks from being mounted via an attack at the operating system level (***EDITED: --provided you have a kernel with the pti/kpti patch***).

The attacks can *maybe* be thwarted from being mounted at the CPU level by putting into practice the countermeasures (specifically: disabling the remote management capabilities --AMT, SPS, or ME-- in the BIOS) described at https://www.intel.com/content/www/us/en ... tware.html
(specifically, by doing what the individual motherboard manufacturers recommend, as linked at the bottom of that article).

On my own machine, at the moment I'm out of luck on this latter defense, because the remote management in my wonderfully fast vintage-2016-BIOS dual-E5v3-Xeon motherboard is only version 3 SPS, and Intel no longer supports SPS versions earlier than 4. Therefore Intel does not at present offer a way to turn off SPS on this motherboard.

According to the article you cite, the Spectre attack can succeed against AMD CPU's. However, I can find only one actual research report indicating so --namely,
https://spectreattack.com/spectre.pdf
and this report does not give specifics. It merely says, on page 3, "We have also verified the attack’s applicability to AMD Ryzen CPUs" but nothing more is stated. (***EDITED: AMD now, Jan. 4, admits its CPU's are vulnerable to Spectre #1, but maintains they are not vulnerable to #2 or #3).

Meanwhile, yesterday AMD issued the statement, cited above, that "To be clear, the security research team identified three variants targeting speculative execution. The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time." (***EDITED: what they meant was, apparently, "we are vulnerable only to #1 and there is near zero risk to AMD processors from #2 and #3."***)

AMD's rebuttal is unequivocal (***EDITED: only as far as #2 and #3***)

Therefore, I strongly suspect that the single report of AMD vulnerability to Spectre, repeated endlessly through the echo chamber of the financial and technical press, is intentional misdirection, done to stave off a catastrophic meltdown of Intel's stock price, and dramatic rise in AMD's stock price, long enough to give big Wall Street portfolio managers time to reposition themselves accordingly ahead of the breaking wave of catastrophe, i.e. sell Intel and buy AMD stock before the general investing public becomes aware of how bad the situation really is for Intel. (***EDITED: probably more deception on the part of Intel than AMD. Intel's first public response was through their general counsel.***

Intel stock is down this morning despite the overall market reaching new record highs, and AMD's stock is up, which tends to support my suspicion. The Wall Street mavens on CNBC are saying they still like Intel and are viewing this price dip as a buying opportunity in Intel, they are saying that the vulnerability will not materially affect Intel's financial well-being. (***EDITED next day: market at record highs again, Intel stock has recovered slightly, AMD is down slightly.***)

But if Intel can no longer match AMD's performance without liquid cooling and using more electricity (i.e. using the Performance governor), as my own rudimentary local experiments positively indicate...then companies who operate large-scale server farms, cloud providers and suchlike, are going to turn en masse to AMD, and there is a distinct possibility of class-action lawsuits being brought by such large customers against Intel. (***EDITED: as of Jan. 5 I still believe Intel may be harmed. Don't know how much it will benefit AMD though.***)

I hope that such pressure will persuade Intel to extend its mitigation efforts to include older motherboards such as mine, in the realm of defending against page table isolation attacks such as Spectre and Meltdown mounted at the CPU level. Starting Linux with pti=on in the kernel line of the bootloader, should be sufficient to stop attacks at the OS level. (***EDITED: provided you have a patched kernel***)

Short version: start Linux with pti=on in the kernel line of the bootloader (***EDITED: provided you have a patched kernel***), and turn off remote management in the BIOS as per the procedures given in individual motherboard manufacturers' links at the bottom of https://www.intel.com/content/www/us/en ... tware.html. (***EDITED: and you'll need a microcode update to combat #2. As of Jan. 5 Intel has not yet AFAIK provided such an update.***)

Then Puppy started from a live CD on an Intel-based computer will not be vulnerable, according to the best information presently available.

[fabrice_035]

The attack relies on running the attackers code on your computer. If you don't run the attackers code then the exploit won't work. Because puppy minimizes the amount of software that one is istalled by default the chance of a fresh puppy having the exploit in installed software is very low.

Some think very soon a script (run in your web browser) will be able to perform an exploit.

I hope a update kernel for Tahrpup and other Puppy distro. Waiting ...
Regard.