Intel Disputes CPU Bug Claims

  • Thread starter Thread starter Guest
  • Start date Start date
Toggle sidebar Toggle sidebar
Status
Not open for further replies.
Directly from AMD

"AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.

Disable page table isolation by default on AMD processors by not setting
the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
is set."
 
Though the doomsday scenario may be overblown, you must also consider that Intel has a vested interest in downplaying the impact if any, as well as implicating as many other competitors as possible. I think we need to wait and see.
 
Hang on, what windows tests? almost every single test posted online abvout the patch was of linux.

Also the language you're using in both articles almost seems like you were paid to protect intel.

Also the intel verbiage seems to be trying to claim other processors have this flaw, which AMD said its false.
 


The Windows tests are linked in the text. https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheitsluecke/

AMD has not released a statement about the vulnerabilities.

ARM disclosed a few minutes ago that it also is subject to the vulnerability. The company claims the vulnerability is not the the result of "Architectural flaws."

We will update the post when AMD makes an official statement.
 
"this implies the exploit can read data" It's just me but imagine what CIA could have done with this all over the world. But I'm sure CIA didn't have idea about this... or maybe not?
 
Haha, where's your post patching Benchmarks? Until you complete those and publish them, all this smacks of paid protection of Intel stock prices.
 


https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheitsluecke/

These are preliminary results. Computerbase.de has a solid history of accurate test methodology.
 
What about Cloud providers? They must be shaking in their shoes. Customer A can use this exploit to read data from Customer B.
 
Yup. I am sure this is COMPLETELY overblown. And the MASSIVE sale of stock by the CEO in November (when the bug was 1st discovered)? Purely coincidence! Right? RIGHT???
 
I'm not sure the reporting on this issue today has given much credibility to tech writers. As this back and forth evolved they ended up letting Intel run the PR and damage control machine and the writers got played like a fiddle. Although implicating ARM and AMD succeeded in raising fear, uncertainty and doubt - and moving markets - the fact remains that the most serious issue remains an Intel specific issue whose fix will have some unknown implication ranging from zero to substantial. I don't find that consistent with the statement that all modern CPU manufacturers are equally vulnerable.
 
This year is gonna be a blast. security holes EVERYHWERE. Intel then Apple then Samsung. I love my tinfoil hat and popcorn.

PS If what is stated by Intel is not true, or I will be affected in any way by the patch they are not going to see money from me never again.
 
Intel's statement is an outright, purposeful deception. They brought up the spectre of data modification and completely avoided mentioning the actual bug, which is the ability to read the contents of kernel memory, when not a single person was talking about data modification and everyone was talking about the ability to read kernel memory. Being able to read kernel memory completely destroys the security of the machine, period. You don't NEED to be able to modify memory when you can steal the encryption keys!

Intel then went on to try to include all other cpu vendors in their little party, to make it seem like it was normal or at least not something Intel-specific. Except this bug *IS* Intel-specific. AMD doesn't suffer from it. ARM doesn't suffer as badly. Sure, there are generally some issues due to speculative timing attacks. But this bug on Intel is the thousand-pound gorilla and they are playing light with it in their statements.

And also in statements, Intel is trying to pass-off the 'fix' that all of us OS programmers have to do, as being something minor. It isn't minor. We have to completely destroy user->kernel transition efficiency by changing out the MMU page tables (%CR3 reload) for every user->kernel and kernel->user transition. THAT SUCKS ROCKS! 150ns system call overhead increases to over 400ns. that isn't minor. That's a show-stopper.

It may be that some classes of problems won't care so much, because they don't make a lot of system calls or take a lot of interrupts, but I guarantee you that there are a LOT of classes of problems that do care, particularly on the server side and in the cloud. I sure as hell care. Intel is wasting god knows how many millions of man hours of people's time dealing with this junk.
All because Intel can't get its house in order. First the management engine, then the hyper-threading bug, and now this junk. I'm sick and tired of it.

-Matt
 
It seems that the author of this article fell for Intel's PR bait hook, line and sinker. In particular the deliberately misleading mention of AMD, which does not suffer from this 'not a bug'. Interesting that the author feels compelled to claim that any performance issues will be addressed over time, when the design fault ('not a bug') can only be avoided by turning off an essential element of the CPU's functionality.
 


AMD has submitted a patch for Linux to prevent the fix being applied to their processors, since it is not necessary:

https://lkml.org/lkml/2017/12/27/2

 


AMD, Google, ARM Holding, and Microsoft have all now issued statements. AMD responded directly. The company does suffer from a one variant of the vulnerability (Bounds Check Bypass), but the company claims it is "Resolved by software / OS updates with negligible performance impact." Intel, of course, is claiming the same, but the company suffers from three variations of the vulnerability.
Google has already patched its infrastructure.
As we said in the closing lines of the article:

Intel's statement opens the floor for other companies to weigh in with their version of events. We'll follow up as more details emerge.
Click to expand...
 

This.

Software running in one virtual machine can read the memory of another virtual machine on the same host.
 
Question is for how long did Intel know about these vulnerabilities? If some forums are to be believed it's not a new issue as some white hat hackers have already alluded to the problem in the past. According to their claim this bug is generated from the kernel space allocation/mapping routine which is handled by processor MMU. Intel's method of doing this leaves the kernel memory somewhat accessible (readable) from the userspace which compromises the security of the entire system through possible TLB (translation lookaside buffer) side channel exploits. Again, the question is what took Intel this long to address this critical issue?
 
"Those preliminary tests reveal that there is , with synthetic I/O tests inflating the issue."
There is a problem with this sentece.
 
Status
Not open for further replies.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom