Intel/Linux 20% slowdown

For discussions about security.
Message
Author
Keisha
Posts: 469
Joined: Tue 18 Nov 2014, 05:43

#41 Post by Keisha »


“A wise man can learn more from a foolish question than a fool can learn from a wise answer.â€￾ --Bruce Lee

ac2011
Posts: 134
Joined: Wed 09 Feb 2011, 08:22

#42 Post by ac2011 »

Keisha wrote: Hmm...some further information which seems to challenge your conclusions:
Those were Google's conclusions, not mine. Again from the Google link about variant #1: "Mitigation requires analysis and recompilation so that vulnerable binary code is not emitted. Examples of targets which may require patching include the operating system and applications which execute untrusted code."

So either Google or Red Hat is wrong, since "applications which execute untrusted code" includes web browsers amongst other things, not just the kernel.

I hope Red Hat is right as I bought the AMD box specifically as an upgrade path free from IME. For now I'll use the Atom boxes until all the misunderstanding/misinformation about Meltdown and Spectre shakes itself out.

s243a
Posts: 2580
Joined: Tue 02 Sep 2014, 04:48
Contact:

#43 Post by s243a »

ac2011 wrote:
Keisha wrote: Hmm...some further information which seems to challenge your conclusions:
Those were Google's conclusions, not mine. Again from the Google link about variant #1: "Mitigation requires analysis and recompilation so that vulnerable binary code is not emitted. Examples of targets which may require patching include the operating system and applications which execute untrusted code."

So either Google or Red Hat is wrong, since "applications which execute untrusted code" includes web browsers amongst other things, not just the kernel.

I hope Red Hat is right as I bought the AMD box specifically as an upgrade path free from IME. For now I'll use the Atom boxes until all the misunderstanding/misinformation about Meltdown and Spectre shakes itself out.
This is speculation. A browser script might not have the necessary features to execute the attack. I presume the attack hasn't been demonstrated via a browser script or google wouldn't have made that claim.

Then again if the attacker could hijack the browser then maybe my assumptions are void.

Keisha
Posts: 469
Joined: Tue 18 Nov 2014, 05:43

#44 Post by Keisha »

ac2011 wrote:[Those were Google's conclusions, not mine...So either Google or Red Hat is wrong,...
Sorry for blaming the messenger. Yes, there is a stark contradiction implied there, isn't there...

Intel's shareholders probably will proceed with the legal actions which are already going forward, and those suits might ultimately combine and morph into some kind of class-action, which I presume Intel would settle out of court, with the shareholders getting new stock warrants perhaps. Maybe, just maybe, the individual buyers at retail of desktops and laptops with Intel inside will end up getting some type of small refund payout and/or rebate on their next Intel purchase.

However, my guess is, Amazon and Google and Microsoft and all the other rackmount server farm cloud providers etc. won't do anything drastic, e.g. won't become plaintiffs in giant lawsuits against Intel. After all, the cloud providers and Intel are mutually dependent on each other, and the Federal government would take any steps necessary to prevent Intel from being driven out of business, for reasons of national security.

Instead, my guess is, Dell and HP and the other hardware makers who supply the government and big cloud providers with large roomsful of rackmount hardware will quietly use public reaction to this fiasco as a bargaining chip to strike deals with Intel for future CPU's at reduced prices.

The cloud providers (including Google) will naturally attempt to bring pressure on Intel to compensate them for the higher electric bills needed to implement the Meltdown remedy, and for whatever damage to reputation and resultant loss of customer bases is due to the Spectre vulnerabilities of Intel CPU's.

If all this speculation above is on the mark, then the whitepapers by Google's Point Zero Team are not to be taken seriously, but are instead just a PR favor being done for Intel, a gesture of goodwill given by Google, an opening gambit of "noblesse oblige," in what promises to be an entertaining process of negotiation.

Or it could be that the whitepapers were in fact produced at the behest of Intel. Maybe it's decided to get rid of the AMT/SPS/ME ("IME") remote management technology altogether and is using this "disgrace" as a cover to initiate a new marketing campaign to sell everybody a forthcoming new generation of "less prone to government intrusion" CPU's?

Or maybe to ditch x86 and amd_64 altogether?
ac2011 wrote:I hope Red Hat is right as I bought the AMD box specifically as an upgrade path free from IME. For now I'll use the Atom boxes until all the misunderstanding/misinformation about Meltdown and Spectre shakes itself out.
I just bought an Atom box too :lol: .

I've already convinced my boss to have the IT guy look at dual Epyc boxes.

Another possibility might be rumored forthcoming offerings from Lenovo based on Chinese-designed, Chinese-made CPU's built on MIPS64 architecture, which said architecture appears to be not subject to the OOOE type of attack --hmm, maybe there's a reason why China decided to license MIPS64 and develop its own CPU's...

I'll keep my dual-E5-2696v3-Xeon uber-spreadsheet-crusher though, until such time as Intel announces that no, it can't really come up with the promised new microcode update to prevent Spectre #2 attacks. If Intel throws in the towel on that one, or if the new microcode seriously slows my day-to-day processing down like the Meltdown #3 defense slows down high-transaction-volume datacenter database access...then Intel is history, and AMD (or Loongsong?) here I come :shock:
“A wise man can learn more from a foolish question than a fool can learn from a wise answer.â€￾ --Bruce Lee

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#45 Post by rufwoof »

As the vulnerability is more widely known/understood, in the interim between browsers being patched (FF 57.4 I believe has been patched for AMD protection), using a addon such as useragent might be a reasonable choice in the interim and spoof your operating system/browser. At least that way if a potential exploit is being deployed against known systems/browsers it may misdirect/mitigate the risk.

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

#46 Post by prehistoric »

As a person running an AMD processor at the moment, I'm going to offer a perspective on the relative risks. All the x86-compatible processors with speculative execution likely have similar vulnerabilities. AMD has implemented the same ideas in different ways, but many of these attacks have not been demonstrated on those processors. This is mainly because of Intel's market dominance. AMD has been less valuable as a target to attack.

It should be possible to correct this by changing kernels, though at present there hasn't been enough testing to know which offer a real improvement. In my view any mitigation that depends on changing applications is DOA (dead on arrival). Some people will do it, but many will not.

For the truly paranoid I will offer this question: how do you know what microcode, including loadable microcode used to fix this problem, is doing, or what it would be doing if attacked in some special way? How do you know what microcode your processor is running?

User avatar
Sky Aisling
Posts: 1368
Joined: Sat 27 Jun 2009, 23:02
Location: Port Townsend, WA. USA

Intel/Linux 20% slowdown

#47 Post by Sky Aisling »

Does anyone know of a list or spreadsheet that shows machine make, model, year manufactured, CPU make and model, Kernels effected and other relevant data? A composite list?

Thank you in advance.

Sailor Enceladus
Posts: 1543
Joined: Mon 22 Feb 2016, 19:43

Re: Intel/Linux 20% slowdown

#48 Post by Sailor Enceladus »

Sky Aisling wrote:Does anyone know of a list or spreadsheet that shows machine make, model, year manufactured, CPU make and model, Kernels effected and other relevant data? A composite list?

Thank you in advance.
In the SA-00088 link in my post here, Intel writes the CPUs it believes/claims are affected:
http://murga-linux.com/puppy/viewtopic. ... 200#979200

It doesn't say Core2Duo or anything before that, from what I can see, which is kind of interesting.

User avatar
Sky Aisling
Posts: 1368
Joined: Sat 27 Jun 2009, 23:02
Location: Port Townsend, WA. USA

Intel/Linux 20% slowdown

#49 Post by Sky Aisling »

Attachments
Cartoon1.png
(182.79 KiB) Downloaded 754 times

Keisha
Posts: 469
Joined: Tue 18 Nov 2014, 05:43

Re: Intel/Linux 20% slowdown

#50 Post by Keisha »

Sky Aisling wrote:Does anyone know of a list or spreadsheet that shows machine make, model, year manufactured, CPU make and model, Kernels effected and other relevant data? A composite list?

Thank you in advance.
AMD and Intel issued more-or-less simultaneous public releases today at about 3PM New York time. I happened to have CNBC on the TV and saw on the ticker the sudden rise in Intel stock and fall in AMD stock as a result of these announcements arriving about simultaneously.

Previously, I'd gathered that both AMD and Intel CPU's needed properly patched updated kernels. In addition, to fight Spectre #2, Intel needs updates to microcode. Today, Intel did publish a microcode update (https://downloadcenter.intel.com/downlo ... -Data-File). This update page lists applicable CPU's going all the way back to Celerons running on a 100 MHz front side bus.

Meanwhile, AMD issued an announcement (http://www.amd.com/en/corporate/speculative-execution) that, contrary to its initial announcements, it too would issue updates to its own microcode in order to defend against Spectre #2. AMD promised microcode updates for its current (Ryzen and Epyc) CPU's starting this week, and for earlier AMD CPU's in coming weeks.

So it looked like Intel was on the ball and AMD had been caught napping, and this resulted in their respective stock price spike or dip.

The Intel microcode update became available in the Ubuntu repositories soon after Intel released it. If you are running TahrPup, you can simply start Puppy Package Manager, click Configure Package Manager (the crossed wrench-and-screwdriver button), click the Update Database tab, click the Update Now button and press Enter as many times as it tells you to while it's wget'ing, to update the packages database to the current version. Then do a search in the main PPM screen for the package "intel-ucode" version 20180108 or newer, select it, and install it. Then reboot, you've got the new microcode. The directions for installing this microcode update to other operating systems are found in the unpacked microcode gunzip archive, in the file "releasenote". For example, instructions for Fedora are given at https://forums.fedoraforum.org/showthre ... -microcode.

The Intel webpage does not say whether or not this microcode update (when combined with a kernel update) is a complete, reliable solution to the two Spectre attacks, nor have performance comparisons been done yet before-and-after the new microcode update. So, optimism concerning Intel stock and pessimism concerning AMD stock may be premature!

Both brands of CPU are going to need kernel updates. Ubuntu images for these new kernels can be accessed through the links at https://wiki.ubuntu.com/SecurityTeam/Kn ... ndMeltdown. For example, the Ubuntu 14.04 (Trusty Tahr) kernel is at https://usn.ubuntu.com/usn/usn-3524-1/. Updating the Puppy kernels will of course require whatever measures are needed to adapt to Puppy, and to furnish the library modules and source code as well.
“A wise man can learn more from a foolish question than a fool can learn from a wise answer.â€￾ --Bruce Lee

User avatar
Sky Aisling
Posts: 1368
Joined: Sat 27 Jun 2009, 23:02
Location: Port Townsend, WA. USA

Intel/Linux 20% slowdown

#51 Post by Sky Aisling »

Thank you, Keisha!
I just finished watching Benedict Cumberbatch in the Hounds of Baskerville.
Your discovery of this data reads like a Sherlock Holmes mystery.

I've redone the repos. I'll now go play with the secret "intel-ucode".

Well done, Sherlock :)

User avatar
RetroTechGuy
Posts: 2947
Joined: Tue 15 Dec 2009, 17:20
Location: USA

#52 Post by RetroTechGuy »

bigpup wrote:Now you know how they are going to talk you into buying the next generation newest processor and Windows 11. :evil: :twisted: :roll:

If you build it so it never breaks. They will only buy it one time!!
And it will run like Windows 1.1... ;-)

Wait, 10 is already trying to run like Windows 1.0

For 30 years I've been hearing "don't worry, the hardware will catch up".
[url=http://murga-linux.com/puppy/viewtopic.php?t=58615]Add swapfile[/url]
[url=http://wellminded.net63.net/]WellMinded Search[/url]
[url=http://puppylinux.us/psearch.html]PuppyLinux.US Search[/url]

Keisha
Posts: 469
Joined: Tue 18 Nov 2014, 05:43

Re: Intel/Linux 20% slowdown

#53 Post by Keisha »

Sky Aisling wrote:Thank you, Keisha!...Well done, Sherlock :)
Urk. Not so fast. More like "No cigar, Clouseau..."

Merely installing the intel-ucode .deb alone, evidently doesn't get the microcode actually installed.

I'm studying the article https://www.pcsuggest.com/update-cpu-mi ... -in-linux/ right now, and will test procedures on an actual running copy of TahrPup64 6.0.6, on an Intel i5-2400 CPU, before I venture further guesses at the correct procedure.

When I use PPM to install cpuid and then run

Code: Select all

iucode_tool -tb -lS /lib/firmware/intel-ucode/*
(not sure if I already had iucode_tool installed, might need to come from PPM) (or maybe installing intel-ucode provides iucode_tool) I see that the only microcode present on this installation of TahrPup64 6.0.6 is dated 2013-06-12.

Studying...

(edited to revise i5-2620 to i5-2400)
Last edited by Keisha on Sat 13 Jan 2018, 16:31, edited 1 time in total.
“A wise man can learn more from a foolish question than a fool can learn from a wise answer.â€￾ --Bruce Lee

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#54 Post by musher0 »

prehistoric wrote:As a person running an AMD processor at the moment, I'm going to offer a perspective on the relative risks. All the x86-compatible processors with speculative execution likely have similar vulnerabilities. AMD has implemented the same ideas in different ways, but many of these attacks have not been demonstrated on those processors. This is mainly because of Intel's market dominance. AMD has been less valuable as a target to attack.

It should be possible to correct this by changing kernels, though at present there hasn't been enough testing to know which offer a real improvement. In my view any mitigation that depends on changing applications is DOA (dead on arrival). Some people will do it, but many will not.

For the truly paranoid I will offer this question: how do you know what microcode, including loadable microcode used to fix this problem, is doing, or what it would be doing if attacked in some special way? How do you know what microcode your processor is running?
Ah. Someone whose light bulb over his head is ON. :) All the little hamster Puppies
are running amuck in their carousels over this, except you, it seems.

Thanks for the words of wisdom, prehistoric.

Didn't I read somewhere that these exploits are "speculative"? As in speculation?
As in: "some computer specialist has discovered that they exist, but nobody has
actually used them yet"?

Besides, who's interested in what a little old Puppy Linux script writer such as "moi"
has on his box?

Better be safe than sorry of course, but I'd rather wait until some really validated
solutions come along.

As bigpup mentioned on another thread, this could be a marketing trick, too. To
make us all dump our current computer equipments and buy new boxes.

BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

Sailor Enceladus
Posts: 1543
Joined: Mon 22 Feb 2016, 19:43

#55 Post by Sailor Enceladus »

musher0 wrote:Ah. Someone whose light bulb over his head is ON. :) All the little hamster Puppies
are running amuck in their carousels over this, except you, it seems.
The first 2 posts in this thread seem pretty happy and calm to me. ;)

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

#56 Post by prehistoric »

@musher0

The speculative part of this crisis is "speculative execution" which has been in the majority of high-performance processors for about two decades.

More common meanings of speculative show up in various ideas about how these vulnerabilities might be demonstrated. Some of these will be particularly difficult, but I have no doubt that many examples will be produced.

On top of all the frightening stuff that has been demonstrated to leak information there is a known exploit called "Rowhammer" which can flip bits in certain common types of DRAM based on physical location, without having access through memory protection hardware. In principle this could allow these exploits to modify memory which they are forbidden to access. The cartoon had this right.

I would predict the collapse of technological civilization if we didn't already have people working hard to achieve that without using this vulnerability. Being the second to cause collapse doesn't count.

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#57 Post by musher0 »

Thanks for the reply, prehistoric.

I'm not sure if I fully understood your last paragraph. Some religions too have now
and then predicted the end of civilization. In the year 999, Europeans thought the
end of the world would come with the year 1000. Nineteen years ago, we thought a
similar catastrophe would happen, but a solution was found to the Y2K bug. Etc., etc.

What I do know is that if you go out of your way to wake up a bear in the middle of
his winter sleep, you will get mauled. Sorry but this is the best analogy I can come
up with.

As far as I can tell, judging from the reports in specialist magazines and web sites,
nobody wicked has used these three exploits yet. I.e., the bear is still sound asleep.
Plus Linux is immune to two of them. (I mean "exploits", not "bears".) :lol:

I had never heard of "RowHammer" before you mentioned it.

Anyway, I'm trying to review this news with a cool head.
My lshw utility tells me this is my CPU:
" *-cpu
description: CPU
product: AMD Turion(tm) 64 X2 Mobile Technology TL-52
vendor: Advanced Micro Devices [AMD]"
A writer at kitguru.net wrote last Friday (Jan. 12, 2018) that
Systems using AMD Opteron, Athlon or Turion X2 Ultra CPUs should gain access to
the patch once again next week. Linux vendors are also rolling out patches for AMD
systems too.
(Although my Turion X2 CPU is not an "Ultra".)

"Sometime next week", that expert says. There is nothing I can do in the meantime.
But I am sure that "civilization" as I know it will NOT crumble to dust in the coming
days. There is nothing I can do in the meantime except maybe, following Salior
Enceladus' wise advice, dust off the old 32-bit and bring it back in service. ;)

If you read carefully, you will notice that that expert writer has used the words "also"
and "too" in the last sentence I quoted. In English style, writing the same meaning
twice at such close range is a grave error. However, his web site did not collapse
because of it. ;)

What can I say. How about some comic relief?
"To err is human. To really foul things up, you need a computer."
as the people in charge of student admission at Carleton University were saying in
the early 1980's. :lol: Touché, I'd say.

But seriously... Humans trip, and then get back on their feet. In writings as in
computer science. History of mankind in a nutshell. No need for alarm, my friends.
Let's just be determined and patient.

BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

#58 Post by prehistoric »

musher0 wrote:Thanks for the reply, prehistoric.

I'm not sure if I fully understood your last paragraph. Some religions too have now
and then predicted the end of civilization. In the year 999, Europeans thought the
end of the world would come with the year 1000. Nineteen years ago, we thought a
similar catastrophe would happen, but a solution was found to the Y2K bug. Etc., etc.
If we look for hard historical evidence, it is difficult to find contemporary accounts of panic in year 1,000 A.D. that differ from accounts in year 900 A.D. or 1,100 A.D. The date of birth for Christianity had only been introduced by Dionysius Exiguus in the sixth century, and was probably not universally accepted in the 10th century. Scholars now accept that he was off by a few years, and the argument was wilder in the tenth century. There was wide belief that the millenium began with the resurrection, putting the end around 1030 A.D.

Even so, Arabic numerals were not introduced to Europe until Liber Abaci in the 13th century. You would have to imagine stone masons in some medieval equivalent of Times Square turning IM into M at midnight, and even this would be an anachronism because for most purposes the day did not start at midnight. Prior to clocks the way people determined the start of a new day, and the hours of a day, varied considerably, but only a few astronomers might have considered midnight the time of change, and they would have been suspect on religious grounds, since this originated among pagans.

English language still says o'clock to deal with these newfangled hours, though French seems to have dropped this. (I believe you do say "à deux heures du matin", though I'm not sure if this means 2 a.m. or the second hour of daylight.) In the year 1,000 most people did not worry much about time at night, except perhaps for Benedictine monks. The result is a linguistic mess in which you can take a siesta (sixth hour) after noon (ninth hour).

In reading about Christian eschatalogical movements you need to know that the New Testament (in Mathew, Mark and Luke) contains a prophecy that "there are some who shall not taste of death..." before the secular world is destroyed. Interpretations have changed, but the result has been a series of movements from the first century on. I don't know of any century since without them. (Check out A History Of The End Of The World.)
...What can I say. How about some comic relief?
"To err is human. To really foul things up, you need a computer."
as the people in charge of student admission at Carleton University were saying in
the early 1980's. :lol: Touché, I'd say.
But seriously... Humans trip, and then get back on their feet. In writings as in
computer science. History of mankind in a nutshell. No need for alarm, my friends.
Let's just be determined and patient.
..
I heard this in the 1960s, and I think it was around before I got into computers. I know I was shown examples of insects claimed to be early "computer bugs".

Yes, the world will cope, but we need to do better than we have in the past if we want that future world to be based on living people of the current species. (If AI were to announce a means to "completely eliminate human error", I have a strong suspicion about how this could be accomplished.) We keep building houses of cards.

Aside: I can't help but mention Henry Petroski's books, starting with To Engineer Is Human: the role of failure in successful design. The trick is not to completely avoid mistakes, but to survive them, and have robust and adaptive ways to respond to them. I am not talking about scams and protection rackets.

I remember arguments about the importance of hardware bounds-checking on arrays from the 1960s and 1970s, when the Internet had not been imagined and the term "computer virus" would have been a joke. There were machines that did this, but the general consensus at the time was that it slowed computation too much. This is precisely the weakness exploited by Spectre, though it requires speculative execution as well.

We have done a great deal with the architecture of CPUs, but have neglected the theory of memory access and IO. Some people have produced very interesting ideas, but these have been ignored by the bulk of the industry, which was heavily weighted toward continuing what was already profitable while avoiding anything fundamentally new. (What we got instead were new buzzwords which worked very well for marketing.)

Aside: Just from my own reading I remember Iliffe's pointer/number machine in which there was a hardware distinction between numbers and addresses. Changing between them was tightly controlled, which would limit exploits using address manipulation. More sophisticated designs used capability-based addressing. Implementations of such things as segmented memory or capabilities in practice have mostly been defective, which didn't hurt their use as buzzwords.

As an example, I'll mention that there was a bug in the 386 which allowed access to most (not all) of the second megabyte of address space despite an intent to limit this without more advanced address translation. (Address translation hardware development was behind schedule.) So many people used this that it became a feature rather than a bug, and it is still buried somewhere in the architecture. This strikes me as much closer to biological evolution than any rational design process.

The secret ingredients that make biological evolution work are death and extinction, two things we all try to avoid.

User avatar
Sky Aisling
Posts: 1368
Joined: Sat 27 Jun 2009, 23:02
Location: Port Townsend, WA. USA

Intel/Linux 20% slowdown

#59 Post by Sky Aisling »

https://arstechnica.com/gadgets/2018/01 ... et-closer/
Driver incompatibilities and microcode problems are both being reported.

Peter Bright - 1/15/2018, 1:05 PM
Applications, operating systems, and firmware all need to be updated to defeat Meltdown and protect against Spectre, two attacks that exploit features of high-performance processors to leak information and undermine system security. The computing industry has been scrambling to respond after news of the problem broke early a few days into the new year.

But that patching is proving problematic. The Meltdown protection is revealing bugs or otherwise undesirable behavior in various drivers, and Intel is currently recommending that people cease installing a microcode update it issued to help tackle the Spectre problem. This comes as researchers are digging into the papers describing the issues and getting closer to weaponizing the research to turn it into a practical attack. With the bad guys sure to be doing the same, real-world attacks using this research are sure to follow soon. ...
EDIT:
Personally, I'm not worried about it. I've pulled a couple of tin cans out of the recycling bucket and I'm waxing up a long cotton string. It worked when I was kid, so, ...

Post Reply