Dear Intel, If a Glaring Exploit Affects Intel CPUs and Not AMD, It's a Flaw

[btarunr]

Intel tried desperately in a press note late Wednesday to brush aside allegations that the recent hardware security-vulnerability are a "bug" or a "flaw," and that the media is exaggerating the issue, notwithstanding the facts that the vulnerability only affects Intel x86 processors and not AMD x86 processors (despite the attempt to make it appear in the press-release as if the vulnerability is widespread among other CPU vendors such as AMD and ARM by simply throwing their brand names into the text); notwithstanding the fact that Intel, Linux kernel lead developers with questionable intentions, and other OS vendors such as Microsoft are keeping their correspondence under embargoes and their Linux kernel update mechanism is less than transparent; notwithstanding the fact that Intel shares are on a slump at the expense of AMD and NVIDIA shares, and CEO Brian Kraznich sold a lot of Intel stock while Intel was secretly firefighting this issue.

The exploits, titled "Meltdown," is rather glaring to be a simple vulnerability, and is described by the people who discovered it, as a bug. Apparently, it lets software running on one virtual machine (VM) access data of another VM, which hits at the very foundations of cloud-computing (integrity and security of virtual machines), and keeps customers wanting cost-effective cloud services at bay. It critically affects the very business models of Amazon, Google, Microsoft, and Alibaba, some of the world's largest cloud computing providers; and strikes at the economics of choosing Intel processors over AMD, in cloud-computing data centers, since the software patches that mitigate the vulnerability, if implemented ethically, significantly reduce performance of machines running Intel processors and not machines running AMD processors (that don't require the patch in the first place). You can read Intel's goalpost-shifting masterpiece after the break.

Intel Responds to Security Research Findings
Intel and other technology companies have been made aware of new security research describing software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operating as designed. Intel believes these exploits do not have the potential to corrupt, modify or delete data.

Recent reports that these exploits are caused by a "bug" or a "flaw" and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices - with many different vendors' processors and operating systems - are susceptible to these exploits.

Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively. Intel has begun providing software and firmware updates to mitigate these exploits. Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time.

Intel is committed to the industry best practice of responsible disclosure of potential security issues, which is why Intel and other vendors had planned to disclose this issue next week when more software and firmware updates will be available. However, Intel is making this statement today because of the current inaccurate media reports.

Check with your operating system vendor or system manufacturer and apply any available updates as soon as they are available. Following good security practices that protect against malware in general will also help protect against possible exploitation until updates can be applied.

Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers.

==END==

Linus Torvalds wrote an interesting comment on one of his Linux kernel mailers.

From Linus Torvalds <>

Date Wed, 3 Jan 2018 15:51:35 -0800

Subject Re: Avoid speculative indirect calls in kernel

On Wed, Jan 3, 2018 at 3:09 PM, Andi Kleen wrote:

> This is a fix for Variant 2 in https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html

> Any speculative indirect calls in the kernel can be tricked to execute any kernel code, which may allow side channel attacks that can leak arbitrary kernel data.

Why is this all done without any configuration options?

A *competent* CPU engineer would fix this by making sure speculation doesn't happen across protection domains. Maybe even a L1 I$ that is keyed by CPL.

I think somebody inside of Intel needs to really take a long hard look at their CPU's, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.

.. and that really means that all these mitigation patches should be written with "not all CPU's are crap" in mind.

Or is Intel basically saying "we are committed to selling you shit forever and ever, and never fixing anything"?

Because if that's the case, maybe we should start looking towards the ARM64 people more.

Please talk to management. Because I really see exactly two possibibilities:

Intel never intends to fix anything

OR

these workarounds should have a way to disable them.

Which of the two is it?

Linus

View at TechPowerUp Main Site

 

[biffzinker]

Meltdown = Intel, and ARM
Spectre = Intel, AMD, ARM, and Power
Spectre is synonymous to Speculative Execution

https://spectreattack.com/

 

[Space Lynx]

AMD EPYC CPU sales will be going through the roof for any new startup companies I imagine. I know I will be doing Ryzen 2 and Vega 2 for my next build, even if I have to take a performance hit. Just tired of all the crap. AMD was my first ever rig when I was a wee lad because it was all I could afford, and they served me well. It's time to go home and say goodbye to the crappy treatment of the gamer community, telemetry baked in, and login requirements for geforce experience.

 

[R-T-B]

Unfortunately, AMD processors are affected by "Spectre", as biffzinker noted. I was wrong earlier in assuming reading those registers would trigger a reboot everytime, as aparently, someone found a way to do all sorts of things with them...

 

[lilunxm12]

Meltdown = Intel Processors
Spectre = Intel, AMD, and ARM
Spectre is synonymous to Speculative Execution

https://spectreattack.com/

Some ARM processors are also vulnerable to Meltdown
Source:https://developer.arm.com/support/security-update

Unfortunately, AMD processors are affected by "Spectre", as biffzinker noted. I was wrong earlier in assuming reading those registers would trigger a reboot everytime, as aparently, someone found a way to do all sorts of things with them...

The point is that AMD processors are apparently not vulnerable to Meltdown and the performance hitting PITA patch is for Meltdown not Spectre, so the conspiracy theory is still there; Why the initial PITA patch flags all X86 machines instead of intel only?

 

[Paganstomp]

In order to ensure our security and continuing stability, the Republic will be reorganized into the first Galactic Empire, for a safe and secure society!

off topic... sorry!

 

[R-T-B]

The point is that AMD processors are apparently not vulnerable to Meltdown and the performance hitting PITA patch is for Meltdown not Spectre, so the conspiracy theory is still there; Why the initial PITA patch flags all X86 machines instead of intel only?

I didn't claim otherwise.

Note there is no patch for spectre, but given it's nature, when they find a way to handle it it will either be a.) very clever or b.) too expensive to performance to even consider. Frankly, I hope they come up with something extremely clever.

In order to ensure our security and continuing stability, the Republic will be reorganized into the first Galactic Empire, for a safe and secure society!

off topic... sorry!

As if I needed another reason to hate Jar Jar... He allowed that.

 

[xkm1948]

Just got an update KB4056892, is this supposed to fix the meltdown flaw? I thought it was gonna take a lot longer?

 

[nem..]

Unfortunately, AMD processors are affected by "Spectre", as biffzinker noted. I was wrong earlier in assuming reading those registers would trigger a reboot everytime, as aparently, someone found a way to do all sorts of things with them...

 

[R-T-B]

peace
View attachment 95523

Uh, Spectre is the one without the fix, and it too affects all OSes (and linux, under default kernel settings)... It's by nature a hardware issue.

Who the heck made that chart? He doesn't know anything. I think both spectre 1 and 2 affect pretty much all known speculative execution processors atm. Maybe I'm mistaken here, but this article I read from a decently respectable publication suggests otherwise:

Read:

https://arstechnica.com/gadgets/201...odern-processor-has-unfixable-security-flaws/

In the meantime, let me help you fanboy:

Intel has spectre too!!!1!! AMD does NOT have MELTDOWN!

 

[R0H1T]

Just got an update KB4056892, is this supposed to fix the meltdown flaw? I thought it was gonna take a lot longer?

They've had 3 quarters to fix it ffs

 

[lilunxm12]

I didn't claim otherwise.

Note there is no patch for spectre, but given it's nature, when they find a way to handle it it will either be a.) very clever or b.) too expensive to performance to even consider. Frankly, I hope they come up with something extremely clever.



As if I needed another reason to hate Jar Jar... He allowed that.

In earlier thread you replied to someone claimed AMD processors were also affected so the patch is required. Now it turns out you're wrong but the point stands, AMD doesn't need PITA patch.

 

[R-T-B]

In earlier thread you replied to someone claimed AMD processors were also affected so the patch is required. Now it turns out you're wrong but the point stands, AMD doesn't need PITA patch.

Ah yes. Earlier I did claim they weren't affected at all other than a reboot issue. I was wrong there. And either way you are right it's unlikely we'll get a "average-joe" PITA patch but we still are left with security issues, is my point. That's a major "datacenter PITA"

Granted, they aren't any better off with Intel...

...Or arm...

MIPS64, anyone?

...no?

PowerPC?
...

Alpha?

Halp, I just want a CPU that works.

 

[xkm1948]

Not seeing any performance penalty by quick synthetic benchmark. Will let you know later this week when I run another batch of RNASeq analysis. That is some pretty memory I/O heavy workload.

 

[R-T-B]

Not seeing any performance penalty by quick synthetic benchmark. Will let you know later this week when I run another batch of RNASeq analysis. That is some pretty memory I/O heavy workload.View attachment 95524

I look forward to your report, resident cat geneticist.

 

[cdawall]

So what all is broken now? Everything? Cause that is how I am reading this.

 

[xkm1948]

So what all is broken now? Everything? Cause that is how I am reading this.

Time to dig up some old Pentium II or K6-2

 

[cdawall]

Time to dig up some old Pentium II or K6-2

That is kind of how this is reading. hmmm or I could just YOLO it. That seems more realistic for my life.

 

[Steevo]

So what all is broken now? Everything? Cause that is how I am reading this.

Not much beyond very specific workloads that have optimized instruction sets, but the fact the vulnerability is there and has to be patched disallows a few very specific workload instruction sets taht gave Intel a leg up in performance, ARM too for that matter.


Its goes something like this from what I understand.


Program A is assigned to XX memory space on core 0, it issues instruction Y to prefetch or look up data in another memory location that it doesn't have access to, but the lookup is allowed, as, the instruction increases performance. The patch will result in performance loss on programs written to take advantage of this prefetch, it may be a parent thread looking up the results of a child threads outcome for a deterministic factor.

 

[cdawall]

Not much beyond very specific workloads that have optimized instruction sets, but the fact the vulnerability is there and has to be patched disallows a few very specific workload instruction sets taht gave Intel a leg up in performance, ARM too for that matter.


Its goes something like this from what I understand.


Program A is assigned to XX memory space on core 0, it issues instruction Y to prefetch or look up data in another memory location that it doesn't have access to, but the lookup is allowed, as, the instruction increases performance. The patch will result in performance loss on programs written to take advantage of this prefetch, it may be a parent thread looking up the results of a child threads outcome for a deterministic factor.

Ok so I saw that in the other thread, but now there are issues with all CPU's in it, which is what I apparently missed somewhere. I am just going to stick with everything is broken and have another beer.

 

[biffzinker]

The Registers interpretation of Intel's PR issued on Wednesday.

Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.

Translation: We weren't the only one. And if we're going down, we're taking every last one of you with us.

Chipzilla doesn't want you to know that every Intel processor since 1995 that implements out-of-order execution is potentially affected by Meltdown – except Itanium, and the Atom before 2013.

https://www.theregister.co.uk/2018/01/04/intels_spin_the_registers_annotations/

 

[FordGT90Concept]

Applications accessing other application's memory is a normal thing, at least on Windows. All applications do it to access kernel features like mouse and keyboard inputs. Any application that uses an overlay does it to apply the overlay. Debuggers do it to debug hooked applications. Of course Cheat Engine, keyloggers, and trainers do it too. An environment like Singularity where cross application access is almost strictly forbidden is not an environment most people want to use.

The above, of course, is on one machine. Virtual machines, on the other hand, should be totally gated from each other. If I understand correctly, AMD properly gates virtual machines where Intel doesn't. This makes virtual machines in an Intel enterprise environment no more secure than running all the software in one machine.

If you're not the NSA or running a service like Azure or AWS, I'm not entirely sure you'd care about virtual machines being completely gated because you're careful about what you run in the first place.

 

[R-T-B]

Applications accessing other application's memory is a normal thing, at least on Windows. All applications do it to access kernel features like mouse and keyboard inputs. Any application that uses an overlay does it to apply the overlay. Debuggers do it to debug hooked applications. Of course Cheat Engine, keyloggers, and trainers do it too. An environment like Singularity where cross application access is almost strictly forbidden is not an environment most people want to use.

The issue is when you use this to gain access to kernel mode memory, which almost no application process should have the ability to do outside of strictly defined calls with limitations.

If you're not the NSA or running a service like Azure or AWS, I'm not entirely sure you'd care about virtual machines being completely gated because you're careful about what you run in the first place.

Well, this could be used for priviledge escalation of malware, is the easiest example I can think of. Suddenly a user account can basically wreck the whole machine.

 

[RejZoR]

@nem..
So, AMD is only affected by Spectre1 and even that ONLY under Linux. Windows is not even affected.
Any info if AMD's software fix for Spectre1 also degrades performance in any significant way?

 

[xkm1948]

@nem..
So, AMD is only affected by Spectre1 and even that ONLY under Linux. Windows is not even affected.
Any info if AMD's software fix for Spectre1 also degrades performance in any significant way?

Time to go RyZen 2 my man, or Threadripper 2. Your choice, 5820K may need to rest.