'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign

Linus Torvalds
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 sh*t
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?
Click to expand...
https://lkml.org/lkml/2018/1/3/797
 
The_Librarian said:
The Register analyzed Intel's response for us in easy-to-understand terms :D , you can follow this link : https://mybroadband.co.za/vb/showth...egister-Intel-PR-blunder-translated-by-El-Reg
Click to expand...

Although, to be fair to Intel and others, with all the slagging Intel etc are getting for a "flawed design", if they say CPU's as far back as 1995 can be affected, this does mean that its taken 20 plus years just for this flaw to be discovered, let alone that anyone has yet used it.

So not such an obvious flaw to my mind?
 
Splinter said:
Although, to be fair to Intel and others, with all the slagging Intel etc are getting for a "flawed design", if they say CPU's as far back as 1995 can be affected, this does mean that its taken 20 plus years just for this flaw to be discovered, let alone that anyone has yet used it.

So not such an obvious flaw to my mind?
Click to expand...

Related issues have been discussed 10 years ago already. And probably known by Intel before that. They (Intel and other chip manufacturers) should have paid more attention to this type of exploit.

https://news.ycombinator.com/item?id=16075744
https://marc.info/?l=openbsd-misc&m=118296441702631&w=2
http://www.cs.dartmouth.edu/~sergey/cs258/2010/D2T1%20-%20Kris%20Kaspersky%20-%20Remote%20Code%20Execution%20Through%20Intel%20CPU%20Bugs.pdf
https://www.geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif
 
kripstoe said:
Related issues have been discussed 10 years ago already. And probably known by Intel before that. They (Intel and other chip manufacturers) should have paid more attention to this type of exploit.
Click to expand...

I'm no techie, so I'll take your word for it!
 
kripstoe said:
Related issues have been discussed 10 years ago already. And probably known by Intel before that. They (Intel and other chip manufacturers) should have paid more attention to this type of exploit.
Click to expand...

If its been known for 10 years, then its a feature not a bug! /ducks
 
/dev/null said:
Linus Torvalds

https://lkml.org/lkml/2018/1/3/797
Click to expand...
Maybe Torvalds isn't aware that Spectre has already been confirmed on AMD and ARM CPUs.
...vulnerable speculative execution capabilities are found in microprocessors from Intel, AMD, and ARM that are used in billions of devices.

We have empirically verified the vulnerability of several Intel processors to Spectre attacks, including Ivy Bridge, Haswell and Skylake based processors. We have also verified the attack’s applicability to AMD Ryzen CPUs. Finally, we have also successfully mounted Spectre attacks on several Samsung and Qualcomm processors (which use an ARM architecture) found in popular mobile phones. Current Status. Using the practice of responsible disclosure, we have disclosed a preliminary version of our results to Intel, AMD, ARM, Qualcomm as well as to other CPU vendors.

... Experiments were performed on multiple x86 processor architectures, including Intel Ivy Bridge (i7-3630QM), Intel Haswell (i7-4650U), Intel Skylake (unspecified Xeon on Google Cloud), and AMD Ryzen. The Spectre vulnerability was observed on all of these CPUs.

... the Spectre attack works on non-Intel processors, including AMD and ARM processors. Furthermore, the KAISER patch [19], which has been widely applied as a mitigation to the Meltdown attack, does not protect against Spectre.

... As the attack involves currently-undocumented hardware effects, exploitability of a given software program may vary among processors. For example, some indirect branch redirection tests worked on Skylake but not on Haswell. AMD states that its Ryzen processors have “an artificial intelligence neural network that learns to predict what future pathway an application will take based on past runs” [3, 5], implying even more complex speculative behavior.
Click to expand...

Source - academic paper
 
Arthur said:
Maybe Torvalds isn't aware that Spectre has already been confirmed on AMD and ARM CPUs.
Click to expand...
Maybe Arthur isn't aware that Torvalds is referring to Meltdown's ability to leak information from kernel to user space.
 
IMO one of the reasons this issue could have been missed, is that well compiled and optimised programs seldom use indirect memory comparisons. Normal practice would always use predictions loaded into a CPU register, for performance reasons.

Ironically the Intel x86 instruction set includes many possible addressing modes for data, partly for backward compatibility and to make the CPU as general as possible. By contrast many early RISC processors had much simpler instruction sets, which in retrospect would be more secure.

These exploits make use of valid, but seldom used memory instructions. The implications may never have occurred to the x86 designers, which span over three decades. After adding so many layers of complexity, these kind of oversights become almost inevitable IMO.
 
ginggs said:
Maybe Arthur isn't aware that Torvalds is referring to Meltdown's ability to leak information from kernel to user space.
Click to expand...

Intel...AMD...Its all silicon from the same sand. I'm South African, I go for the cheapest thing that does what I want done. That tends to be AMD.
 
Comment from a google plus user :

This is neither a hardware or a software issue. It is an architecture issue. The problem goes to the heart of the von Neumann machine: how do you predict program branches, and avoid performance penalties when you're wrong? The current solution is to run both branches ahead of time, then when the branch is determined, use the results from the correct branch and discard the other. The exploits seem to rely upon reading the cache of the invalid branch before it is overwritten.
Click to expand...
 
Last edited:
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X