Intel/Linux 20% slowdown

[rufwoof]

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.

Intel's CEO has maximised liquidation, minimised his stock holdings. https://www.fool.com/investing/2017/12/ ... stock.aspx

choosen to keep only the shares that he's required to by Intel's rules

[8Geee]

I've had a read of many things today, nor'easter at hand, and have figured out the following...

This is all about "out-of-order execution (OOOE)" a trait encoded into most CPU's since the 90's.

Intel's version has a leak, and also executes the delayed instruction without regard to security or privacy. (In other words it does not know that the delayed instruction information is a password.) The leak allows the end-user to be tricked into allowing the OOOE stack to be read.

AMD claims that their processors are not subject to Intel's problems. They remain silent about leakage.

Very few Intel products are exempt from the Intel OOOE flaw,
in particular;

1.) HP/Intel Itanium Servers
2.) Intel Atom "Bonnell technology" (Original)
Some of these exempt Atoms are 64-bit.

Atom CPU's using Silvermont (2013+) are NOT EXEMPT. These include Bay-Trail and Cherry-Trail.

So yes, there is a huge problem. Apple, and Microsoft are patching their engines (kernels). And as of Jan.2 kernel dot org has updated all supported kernels. Google is sending mixed signals, and FUD follows mixed signals.

Wikipedia Out-Of-Order Execution

Wikipedia Intel Atom CPU's

Regards
8Geee

[ac2011]

Short version: start Linux with pti=on in the kernel line of the bootloader.

I don't see how that will help unless you're running a version of Linux with the patched kernel, which presumably almost none of us are. I can find no mention of the "pti" switch prior to these events, so I'd expect older kernels to simply ignore it. I'd love to be proved wrong.

[Keisha]

Short version: start Linux with pti=on in the kernel line of the bootloader.

I don't see how that will help unless you're running a version of Linux with the patched kernel, which presumably almost none of us are. I can find no mention of the "pti" switch prior to these events, so I'd expect older kernels to simply ignore it. I'd love to be proved wrong.

You're absolutely right, I'm working not with Puppy but with a custom version of Fedora to which the pti/kpti patch had been already applied (using kernel 4.15.rc6). I did not know that pti was not yet already an existing capability. Meanwhile, kernel developers are working on backporting pti/kpti to legacy kernels.

AMD (at https://www.amd.com/en/corporate/speculative-execution) now officially admits that version #1 of Spectre does affect at least some AMD CPU's, though AFAIK Ryzen and Epyc CPU's have not been shown to be affected, only A-series and FX series. Spectre #2 and Meltdown #3 do not affect AMD CPU's. The big performance hits (and a perhaps more important issue, the electricity consumption rise and consequent added heat emission needed to maintain equal performance, problems which have not yet been addressed in the press AFAIK) only occur when combatting #3 by using pti=on, and so only Intel CPU's are hurt.

Therefore I still stand by my speculation that this whole cockup will prove harmful to Intel as far as marketing CPU's to the providers of equipment to cloud providers. Whether this will help AMD in the cloud market, I guess, depends on whether there are other lesser-known CPU makers (Via? IBM? Cavium? Marvell? Sunway? nVidia?) who can step in to compete.

#2 needs a microcode update to fix, and AFAIK at this writing Intel has not yet provided one.

So, my revised opinion as of right now is: patched kernels (***EDITED: and other software components, e.g. llvm***) will be necessary in order to combat #1, #2, and #3 and in addition a CPU microcode update and maybe a BIOS patch are needed in order to combat #2. (***EDITED:The only effect on AMD is, a kernel patch is needed to shield AMD CPU's from #1. This patch will incur no performance hit on AMD CPU's.***)

I have an inquiry in to my own motherboard manufacturer (ASRock) concerning how the BIOS needs to be patched.

Anyone who has new information is certainly welcome to post.

[ac2011]

That sounds right. My current 'solution' is to get hold of a 2009 Atom N280 thin client for sensitive online use. No speculative execution so should be invulnerable to Meltdown and Spectre... I think. It will be slow, though.

I went for the earlier variant as later (but still pre-2013) Atoms presumably come with Intel's ME, and I don't want that. The Venn diagram contains a very thin sliver of acceptable solutions!

I have an AMD machine (A-series) that I can use, but for best security on that I'd have to shift away from my favourite Puppy distro to something with rolling updates to ensure all applications are Spectre-proofed, which would be a shame.

I'm looking at Raspberry Pi longer term, which has neither vulnerability. I'm no longer an avid gamer so that might work for me for everyday use.

Keen to hear what other people have planned, if anything.

[Sailor Enceladus]

It looks like code has been commited today (2018-01-05) to work around the Meltdown problem in kernels 4.4.110, 4.9.75, and 4.14.12 so far (from what I can tell)?
https://git.kernel.org/pub/scm/linux/ke ... 2=v4.4.109
https://www.kernel.org/

I'll try compiling a 4.4.110 when I get home, and compare it with 4.4.109 on my 32-bit Pentium M laptop.

[belham2]

We should also be talking about what users can do to protect themselves. I think the following might help and/or provide some guide:

1) make sure you have 2-4 different bootable systems . System 1 is for general web use. System 2, a backup to System 1. System 3, a system with a browser that is used only for email and sensitive site access (that means going directly to those sites, and nowhere else). System 4, a backup to system 3.

2) Over the past few days, i am hearing this from not only Intel people, but also AMD. Home users, turn off ALL samba. In essence, run isolated systems. A firewall isn't going to help you if you get hit with one of these.

3) In Systems 1 and 2 above, make sure your browser has the ability to disable javascript. It is fairly easy (about:config) in Firefox/Palemoon/Seamonkey, and also easy in Chrome (but more problematic, as evidently, even when you set Chrome to not use javascript, it still does for some things---Google, wakeup for crissakes). And it will be a pain in the butt for most sites. For example, with javascript disabled, on murga when you type out a message, you will be able to do things "Bold" or "italic' or "Underline" and many other things on the murga site. I am facing these things right now writing this message, since all of my machines have javascript disabled (I use heavily "about:config" modded & fortified Firefox as my browser). So, oh well, it's the price to pay until things get clearer.

4) In Systems 3 and 4 above, these systems are with browsers that have javascript enabled (most sensitive sites, i.e. bank, etc won't function without javascript enabled in the browser). Also, these systems are never to be booted up and used for anything else. Install basic minimums to this systems (Ubuntu minimal, or Debian minimal, and Puppy installs are great choices here. My preference: I build minimal Debian installs myself. Also, I trust Barry inside and out---and for a USB stick for a System 3/4 boot, these are the way to go.

5) Use a good ad-blocker in all browsers in Systems (1-4). Today, Ublock Origin is the most recommended by people in the security industry, and with good reason. Ads on the web are malware missiles, and deliver malware payloads.

6) For Systems 1 and 2, you could do a lot worse than installing NoScript. No explanation needed here.

7) Last but not least, in the Systems 3 and 4 that you build, or install and/or whatever, don't install any extra software packages---no new added programs for anything (except a browser, and, if building, only the basics for a DE functioning system). This shouldn't need explained, given what Systems 3 & 4 will be used for.


I believe most of us do the above things to some degree. But we, here on murga, are an absolute minority, and that is in just the general linux world (we don't even register out in the Microsoft/Apple world). Most linux users I know can't save their own butts with just basic functions. I give them a pup, and they just fall flat on their face when something simple happens and they can't fix it because they have no idea how. They are used to just install big Linux OSes, and expect it all to work hunky-dory with no problems whatsoever. These people and types of users scare me, even more than Windows/Apple users. Anyhow, I am not sure how we (the murga gang) can make a difference in what is currently going on.

Please know: I typed all of this out quickly. I do know some of the above would be uber painful for some, especially the Samba part. But, look, overall it can't hurt for a short period of time until things been better understood and mitigated to a greater degree. You get owned on one of Samba-linked computers, you're more likely to get owned on all of them. Equally, nowadays there is no sane mind in the world that would use a general browsing computer for anything done sensitive-wise (banking, health, investments) on the web. If you do engage in this recklessness, you deserve whatever happens.


Lastly, it is my opinion (and I know many are thinking this, Bigpup even joked about it)...but it is my opinion Intel and AMD are absolutely creaming their pants with joy over this. They needed a reason, an end-of-the-world panic to drive the next great chip cycle. This may it, and they may be actively encouraging it. Heck, when the U.S. Department of Homeland Security came out just yesterday that ALL computers on the planet cannot be trusted, and new chips with new designs & software need released, well......I mean, Intel and AMD must have nearly passed out from euphoria while trying to maintain their worried and all-is-still-ok current public face.

[Marv]

A few very quick tests using the 4.14.11 32b PAE kernel (from peebee in the newest LxPupSc) on a second generation i5 laptop. nokaiser is supported as a kernel parameter according to the 4.14.110 changelog and does seem to toggle the kaiser patches. On this hardware (Fujitsu S761 laptop), with the kaiser patches enabled, which is the kernel default, there is about a 1.5% hit on glxgears FPS, a 0.8% hit on the CPU cryptohash, and a 4% hit on the FPU raytracing benchmarks in hardinfo. All based on 5 run averages, performance governor, same machine same OS etc. Temperature monitored and not a factor. The first two are just about down in noise, the FPU delta seems real. I haven't gotten to the core 2 duos or the Bay Trails yet, but mostly use the i5s now and certainly can live with that.

Edit: kaiser is now kpti and the most recent info I've read states that nopti is to be the kernel toggle. Don't know if nokaiser will continue to be supported as an alias or not. This rolling stone really gathers no moss!

[Keisha]

A few very quick tests using the 4.14.11 32b PAE kernel (from peebee in the newest LxPupSc)..."

According to https://access.redhat.com/articles/3311301 it'll have a file
/sys/kernel/debug/x86/pti_enabled
if the pti patch has been applied to the kernel. The slowdowns and thermal throttling on Intel CPU's are seen only on kernels with the pti patch applied.

In ordinary desktop use, my experiments show little or no perceptible slowdown, and only a little thermal problem; for the individual user security is the main issue. Slowdown, excessive electric consumption, and heat are issues equally important to security only in scenarios where there is constant re-filling of the CPU's internal caches (L1, L2, and TLB), and this is not a relevant scenario in most individual desktop or laptop computer use.

Unfortunately however, large-scale data centers with heavy transaction volumes, where we're talking a large roomful of rackmount servers, are exactly this type of scenario. From what I understand and can see, Intel is going to get complaints from these types of customers, e.g. Amazon Web Services, Microsoft Azure, Google, Oracle, all the world's stock exchanges, bitcoin mining centers, etc. etc. etc.

Two law firms (Kaplan Fox & Kilsheimer LLP, and the Law Offices of Howard G. Smith) have already announced investigations into Intel over possible violations of securities law committed by Intel's CEO and other officers in connection with large stock sales done without fanfare in foreknowledge of these security threats; as these cases go forward I foresee that the stonewalling which Intel is evidently engaged in right now, with regard to the added electric and cooling costs of Intel CPU's under the conditions of use in data centers when the AMT/SPS/ME, Spectre, and Meltdown defensive patches have all been applied...will come under consideration before a court.

Worst case scenario, these preliminary lawsuits will then mushroom into gigantic class-actions with the likes of Amazon, Microsoft, Google et al as plaintiffs.

I myself would certainly not be a long-term investor in Intel stock at the moment.

...later (but still pre-2013) Atoms presumably come with Intel's ME, and I don't want that...

Yes, my machine's motherboard is a vintage-2014 socket 2011-3, dual sockets/Xeon's, with a BIOS dated March 31 2016 and yet the SPS (ME equivalent for servers) on the chipset is only version 3, the current version is 4, so I've asked the motherboard manufacturer (ASRock) for guidance. Intel's own security advisory on the AMT/SPS/ME vulnerabilities (https://security-center.intel.com/advis ... geid=en-fr) only covers SPS version 4. No word on what vulnerabilities exist in version 3. *Grrr*.....

I have an AMD machine (A-series) that I can use, but for best security on that I'd have to shift away from my favourite Puppy distro to something with rolling updates to ensure all applications are Spectre-proofed, which would be a shame.

Or wait for a Puppy to appear with an appropriately patched kernel. The final mainline version of 4.16 should work, when it appears. Maybe, just maybe, 4.15. Or a legacy version kernel with the patchset backported.

I myself use an in-house-customized Fedora, which since Fedora is maintained by Red Hat gets needed security updates with minimum delay. Sure hope I don't have to beg my boss for a new Epyc machine though.

[ac2011]

I have an AMD machine (A-series) that I can use, but for best security on that I'd have to shift away from my favourite Puppy distro to something with rolling updates to ensure all applications are Spectre-proofed, which would be a shame.

Or wait for a Puppy to appear with an appropriately patched kernel. The final mainline version of 4.16 should work, when it appears. Maybe, just maybe, 4.15. Or a legacy version kernel with the patchset backported.

That would solve Meltdown but not Spectre, which I believe requires recompilation of applications with 'retpoline' or similar mitigations. Still, perhaps this can be built into the build process for future Puppies?

Admittedly Spectre appears to have the lower risk profile at the moment, but that may change.

[Keisha]

I have an AMD machine (A-series) that I can use, but for best security on that I'd have to shift away from my favourite Puppy distro to something with rolling updates to ensure all applications are Spectre-proofed, which would be a shame.

Or wait for a Puppy to appear with an appropriately patched kernel. The final mainline version of 4.16 should work, when it appears. Maybe, just maybe, 4.15. Or a legacy version kernel with the patchset backported.

That would solve Meltdown but not Spectre, which I believe requires recompilation of applications with 'retpoline' or similar mitigations..

But you said you use an AMD A CPU, which is not susceptible to the Spectre #2 attack which is mitigated by retpoline (see https://www.amd.com/en/corporate/speculative-execution). It only applies to Intel CPU's. Spectre #2 requires either retpoline patches to the kernel and software, or a microcode update (so says https://security.googleblog.com/2018/01 ... cpu_4.html). This implies that if you have the Intel microcode update in force, retpoline is unnecessary.

[8Geee]

I see a reference to the Intel Management Engine with Atom's being suseptible to THOSE things.

The Two Atom Series are;

C3xxx (Silvermont Architecture) AKA x3 series SoFIA
E39xx (Silvermont Archetecture) AKA x5 series Apollo Lake

So the Bonnell Architecture is EXEMPT.

Regards
8Geee

[ac2011]

[ac2011]

I see a reference to the Intel Management Engine with Atom's being suseptible to THOSE things.

The Two Atom Series are;

C3xxx (Silvermont Architecture) AKA x3 series SoFIA
E39xx (Silvermont Archetecture) AKA x5 series Apollo Lake

So the Bonnell Architecture is EXEMPT.

Regards
8Geee

Seems to be, hence the N280. It'll be fun going back a decade in computing power...

[8Geee]

There are some N2800 boxes around. These are 2-core Atoms using the Bonnell archetecture, and the last best processor that is EXEMPT from IME and Meltdown/Spectre.

Cheers
8Geee

[ac2011]

There are some N2800 boxes around. These are 2-core Atoms using the Bonnell archetecture, and the last best processor that is EXEMPT from IME and Meltdown/Spectre.

Cheers
8Geee

Thanks, but given it's a >2008 design I suspect it might have the Intel Management Engine, and that's a no-no for me. No point in jumping from one frying pan into another.

Edit: I know you wrote exempt from IME but do you have any links for that? Libreboot says anything from Intel after 2008 is compromised, and anything from 2013 onward for AMD, hence my 2012 AMD A-series box. The N2800 would be a better option than the N280 if it's IME-free.

[8Geee]

If the CPU is not Atom C3000 or E3900 there is NO Intel Management Engine. The 2008 reference is for desktop Nehalem CPU's. This is common FUD being sent all over.

Link to both Atom Processors and Intel OOOE was already given in one of my previous posts on topic. The source is Wikipedia.


As for Intel Management Engine look here. Skip the geeky stuff if you want, but there are important verified points about what is affected, and "other names" for it. You will find that the 2008 reference is for the Nehalem desktop. And you will also find that AMD distributed a patch for their version that shuts off that "feature" without harm. Intel's version bricks the computer.


Regards
8Geee

[ac2011]

If the CPU is not Atom C3000 or E3900 there is NO Intel Management Engine. The 2008 reference is for desktop Nehalem CPU's. This is common FUD being sent all over.

Regards
8Geee

Thanks (I think you wrote while I was editing). This sounds more appealing. My Google-fu apparently isn't good enough to find a definitive list of IME vs non-IME CPUs.

[8Geee]

me too, but uncle Barney Google has a nit to pik with competitors to Android and Chrome. se la vie.

Regards
8Geee

[rufwoof]

We should also be talking about what users can do to protect themselves. I think the following might help and/or provide some guide:

1) make sure you have 2-4 different bootable systems . System 1 is for general web use. System 2, a backup to System 1. System 3, a system with a browser that is used only for email and sensitive site access (that means going directly to those sites, and nowhere else). System 4, a backup to system 3.
.
.
4) In Systems 3 and 4 above, these systems are with browsers that have javascript enabled (most sensitive sites, i.e. bank, etc won't function without javascript enabled in the browser). Also, these systems are never to be booted up and used for anything else. Install basic minimums to this systems (Ubuntu minimal, or Debian minimal, and Puppy installs are great choices here. My preference: I build minimal Debian installs myself. Also, I trust Barry inside and out---and for a USB stick for a System 3/4 boot, these are the way to go.
.
.
7) Last but not least, in the Systems 3 and 4 that you build, or install and/or whatever, don't install any extra software packages---no new added programs for anything (except a browser, and, if building, only the basics for a DE functioning system). This shouldn't need explained, given what Systems 3 & 4 will be used for.

Great advice Belham2. I have Debian (main repo's only) for casual use (their security team are hot). For your 3/4 I use OpenBSD. Once installed already to a partition (a6 type), you can just download/verify the latest snapshot bsd.rd (usually under pub/OpenBSD/snapshots ... and your PC/device folder, /pub/OpenBSD/snapshots/amd64/bsd.rd for me) saving it to / and then boot that (reboot and enter "boot bsd.rd"). That 9MB or so ramdisk snapshot enables you to upgrade, install ...etc. I usually reinstall afresh and its all textual/cli style that takes around 5 minutes to run through (mostly its just accepting defaults and I use the http based install option so there's no need for CD's etc., just pulls down everything it needs). After a reboot I mount my Debian partition (for me running disklabel sd0 shows the ext3 partitions and for me its mkdir sda2;mount /dev/sd0j sda2 to mount the Debian partition) in which I have copies of the /etc/X11/xorg.conf, /etc/sysctrl.conf, ~/.Xdefaults ~/.xsession. ~/.twmrc and ~.profile that I copy over to the new OpenBSD install and then pkg_add (similar to Debian's apt-get) firefox-esr-i18n-en-GB and its all good to go.

Tracking openbsd --current conceptually isn't as stable as --release or --stable, but so far I've not encountered any problems and that has pre-built binaries of the latest versions so there's no need to compile anything. You can run into problems where the mirrors are being updated as you're pulling things down, but that's relatively rare (not encountered it myself, but have seen mention of it by others) and a simple re-try again later resolves that issue.

A fresh install of the latest versions of OpenBSD (which includes X that is set to run at a low-privilege levels) and browser used only to go directly to your banks web site is relatively secure. OpenBSD however doesn't have the range of programs as available from Debian, so as a day to day general system Debian works well for me. Nice to have a slice of both Linux and Unix pies as well.