All Intel processors affected by memory leaking vulnerability

chong

Supremacy Member
Joined
Jan 1, 2000
Messages
5,037
Reaction score
35
News already mentioned AMD is not affected with the bug? No?

The performance drops are a result of the software patches being made to workaround the Intel CPU bug; the Intel CPU bug itself does not cause performance drops.

So yes, AMD does not have the bug. But because the software patches are currently being indiscriminately applied to all x86 machines, AMD machines which technically don't need the patches will also see performance drops after the impending software updates.
 

lamesensei

Senior Member
Joined
Aug 17, 2007
Messages
1,373
Reaction score
0
The performance drops are a result of the software patches being made to workaround the Intel CPU bug; the Intel CPU bug itself does not cause performance drops.

So yes, AMD does not have the bug. But because the software patches are currently being indiscriminately applied to all x86 machines, AMD machines which technically don't need the patches will also see performance drops after the impending software updates.

pls do more research -

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

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.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
arch/x86/kernel/cpu/common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index c47de4e..7d9e3b0 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -923,8 +923,8 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c)

setup_force_cpu_cap(X86_FEATURE_ALWAYS);

- /* Assume for now that ALL x86 CPUs are insecure */
- setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
+ if (c->x86_vendor != X86_VENDOR_AMD)
+ setup_force_cpu_bug(X86_BUG_CPU_INSECURE);

fpu__init_system(c);

f hell this article about intel, intel fanboy still can turn around and shoot amd :s22:
 
Last edited:

Rock-kun

Senior Member
Joined
Sep 10, 2007
Messages
991
Reaction score
1
pls do more research -

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



f hell this article about intel, intel fanboy still can turn around and shoot amd :s22:

First of all, that patch was only accepted 12 hours ago. At the time this thread was created, it was still uncommitted. Patches submitted to the kernel are never automatically accepted until they pass through a few maintainers, with Linus having the final say. A maintainer reviewing it has little impact on whether it is eventually committed.

And finally, that patch may still end up being rejected because Google claims its tests indicate AMD is also affected. Source: https://www.phoronix.com/scan.php?page=news_item&px=Google-CPU-Disclosure
 
Last edited:

furyoo

Supremacy Member
Joined
Mar 10, 2002
Messages
6,557
Reaction score
77
pls do more research -

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



f hell this article about intel, intel fanboy still can turn around and shoot amd :s22:

I'm not sure why you're so quick to dismiss it as an Intel fan boy thing. Although there is a workaround that should be easy to implement, especially in Linux, there has been no confirmation that this is the approach taken for the windows patch.

Even the r/AMD subreddit is concerned that the initial patch will be an all encompassing one that will hit every single chip:

https://www.reddit.com/r/Amd/comments/7nqwoe/apparently_amds_request_to_be_excluded_from_the/?utm_source=reddit-android
 

wwenze

Great Supremacy Member
Joined
Dec 2, 2002
Messages
73,361
Reaction score
18,263
Sigh people trying to discuss and find discoveries and effect you label them as Intel fanbois... You (I'm not even to use the word "sir" even ironically) are the definition of fanboy

Tom's Guide has a very interesting way of rephrasing stuff...
"Major Security Flaws Exist on Intel, AMD, ARM CPUs"
"At 5 p.m., Daniel Gruss, a post-doctoral student in information security at the Technical University of Graz in Austria, came forward to announce Meltdown and Spectre. He told ZDNet's Zack Whittaker that "almost every system" based on Intel chips since 1995 was affected by the flaws. It turned out the problem was even worse."
https://www.tomsguide.com/us/intel-cpu-kernel-pc-mac,news-26320.html

Could it be ever derivative from / copy of Pentium has this issue? Or just something that was convergent evolution? Or even an industry standard?
Just the concept of speculative execution? Any other factors involved?
 
Last edited:

lamesensei

Senior Member
Joined
Aug 17, 2007
Messages
1,373
Reaction score
0
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Tip-Git-Disable-x86-PTI

While at the moment with the mainline Linux kernel Git tree AMD CPUs enable x86 PTI and are treated as "insecure" CPUs, the AMD patch for not setting X86_BUG_CPU_INSECURE will end up being honored.

The patch covered in the aforelinked article has not been merged through to Linus Torvalds' Git tree. Instead, as of a short time ago, is now living within the tip/tip.git tree. In there is also defaulting PAGE_TABLE_ISOLATION to on and other recent fixes around x86 Page Table Isolation (PTI) support.

But what remains to be seen is if this work will be pulled into Linux 4.15 Git or not. We're within three weeks of the executed debut of Linux 4.15.0 stable and it isn't clear if these tip changes will be requested to be pulled into Linux 4.15 or be postponed until the start of the Linux 4.16 kernel merge window, since the safe bulk of the x86 PTI work is already in Git master. Right now the branch name doesn't indicate it's in any fixes/urgent queue nor has there been any pull request yet asking Torvalds to take it into his repository: normally tip.git master is with material for linux-next.

So we'll have to see what ends up happening in the days ahead, but regardless, at least the "AMD patch" is now sitting within a known tree that will eventually flow into the mainline Linux tree whether it be 4.15 or 4.16.

plus extra salt for the lulz

https://lkml.org/lkml/2018/1/3/797

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 <andi@firstfloor.org> 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 ****
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

and if it does affect amd i lose also y so mad?
 
Last edited:

wwenze

Great Supremacy Member
Joined
Dec 2, 2002
Messages
73,361
Reaction score
18,263
First of all, that patch was only accepted 12 hours ago. At the time this thread was created, it was still uncommitted. Patches submitted to the kernel are never automatically accepted until they pass through a few maintainers, with Linus having the final say. A maintainer reviewing it has little impact on whether it is eventually committed.

And finally, that patch may still end up being rejected because Google claims its tests indicate AMD is also affected. Source: https://www.phoronix.com/scan.php?page=news_item&px=Google-CPU-Disclosure

I think this episode just proves again the power of AMD's fanboy army, which managed to twist reality... for one day.
Would be the worst marketing spending if they weren't working for free.
 

Rock-kun

Senior Member
Joined
Sep 10, 2007
Messages
991
Reaction score
1
Sigh people trying to discuss and find discoveries and effect you label them as Intel fanbois... You (I'm not even to use the word "sir" even ironically) are the definition of fanboy

Tom's Guide has a very interesting way of rephrasing stuff...
"Major Security Flaws Exist on Intel, AMD, ARM CPUs"
"At 5 p.m., Daniel Gruss, a post-doctoral student in information security at the Technical University of Graz in Austria, came forward to announce Meltdown and Spectre. He told ZDNet's Zack Whittaker that "almost every system" based on Intel chips since 1995 was affected by the flaws. It turned out the problem was even worse."
https://www.tomsguide.com/us/intel-cpu-kernel-pc-mac,news-26320.html

Could it be ever derivative from / copy of Pentium has this issue? Or just something that was convergent evolution? Or even an industry standard?

I know Google claims ARM is also affected, but I still don't believe ARM has the computational power to drive datacentres and public clouds.
 

commach

Great Supremacy Member
Deluxe Member
Joined
Apr 11, 2001
Messages
53,997
Reaction score
15
Note: Fanboyism is not welcomed in the forum, 1 warning and 1 infraction already given in this thread for nuisance reply.

Ok for disagreement but no room for disrespectful.
 

Rock-kun

Senior Member
Joined
Sep 10, 2007
Messages
991
Reaction score
1

Let me drill that down for you:

But what remains to be seen is if this work will be pulled into Linux 4.15 Git or not. We're within three weeks of the executed debut of Linux 4.15.0 stable and it isn't clear if these tip changes will be requested to be pulled into Linux 4.15 or be postponed until the start of the Linux 4.16 kernel merge window, since the safe bulk of the x86 PTI work is already in Git master. Right now the branch name doesn't indicate it's in any fixes/urgent queue nor has there been any pull request yet asking Torvalds to take it into his repository: normally tip.git master is with material for linux-next.

So we'll have to see what ends up happening in the days ahead, but regardless, at least the "AMD patch" is now sitting within a known tree that will eventually flow into the mainline Linux tree whether it be 4.15 or 4.16.

It's pulled in the main repository where it will eventually be considered for merging into mainline. But as of now, it is still not committed for the upcoming 4.15 kernel.

Update: based on Linus's reply in LKML, it's anyone's guess whether AMD's patch is accepted. But it seems like he takes issue with the whole 'treat every x86 processor as affected' initial patch.
 
Last edited:

commach

Great Supremacy Member
Deluxe Member
Joined
Apr 11, 2001
Messages
53,997
Reaction score
15
Update: 1 warning and 2 infractions given in this thread for nuisance replies.
 

lamesensei

Senior Member
Joined
Aug 17, 2007
Messages
1,373
Reaction score
0
I think this episode just proves again the power of AMD's fanboy army, which managed to twist reality... for one day.
Would be the worst marketing spending if they weren't working for free.

intel say amd affected,

amd say amd not affected

both not fanboy + pr machine at work?

who more **. :s11:
 

wwenze

Great Supremacy Member
Joined
Dec 2, 2002
Messages
73,361
Reaction score
18,263
More summary from reading:

While with the Linux development code currently, AMD CPUs are marked as insecure and those PTI applied, as covered earlier today, being staged via the tip tree is the much talked about AMD patch. But if that patch will land in time for this month's Linux 4.15 kernel release or be held off until the Linux 4.16 kernel cycle remains to be seen. Regardless, that AMD patch will end up landing some point soon so AMD CPU owners won't be negatively impacted as their hardware appears immune to this latest security issue.

- Reiterating from yesterday's article, systems having PCID (Process Context ID) should lessen the impact of PTI being enabled. (Those interested can check for the presence of "pcid" in their "/proc/cpuinfo" output.) PCID has been present on Intel hardware since the Westmere days, so basically any Sandy Bridge era system or newer should be in better shape. I did manage to pull out an old Lenovo ThinkPad W510 with an Intel Core i7 720QM Clarksfield that is from 2009 and lacks PCID but is affected by this cpu_insecure issue.

- On that old Clarksfield-era ThinkPad I wasn't going to be surprised if the performance was disastrous, but it wound up being better than I had anticipated given all the ongoing drama... In general purpose workloads there was no reportable performance difference in our frequent benchmark test cases. Under I/O, the PTI-using kernel did yield some slower results but not by the margins seen on the newer systems with faster storage. The laptop consumer-grade HDD in this laptop appeared to be the main bottleneck and kernel inefficiencies weren't causing as dramatic slowdowns.

- To some surprise, when carrying out network benchmarks with netperf/iperf3, in at least those contexts PTI didn't have a noticeable impact on the network throughput performance.

Wonder what about USB3 and PCI-E impact tho...
 

Psycovirus

Senior Member
Joined
Jan 3, 2007
Messages
1,756
Reaction score
332
I think this episode just proves again the power of AMD's fanboy army, which managed to twist reality... for one day.
Would be the worst marketing spending if they weren't working for free.

AMD is not affected by the bug that Intel suffers.

Two types of vulnerabilities were documented.

Meltdown flaw affects virtually every microprocessor made by Intel.

The other flaw, Spectre, affects most processors now in use, though the researchers believe this flaw is more difficult to exploit. There is no known fix for it.

From this article

Google is mentioning two different vulnerabilities. Intel bug still remains as the top priority to fix.
 

wwenze

Great Supremacy Member
Joined
Dec 2, 2002
Messages
73,361
Reaction score
18,263
I know Google claims ARM is also affected, but I still don't believe ARM has the computational power to drive datacentres and public clouds.

Oh that you'd be wrong xia.

Those systems powered by nVidia / ARM combo?
 

furyoo

Supremacy Member
Joined
Mar 10, 2002
Messages
6,557
Reaction score
77
intel say amd affected,

amd say amd not affected

both not fanboy + pr machine at work?

who more **. :s11:
There are two seperate issues. It is still only a rumour that AMD chips have the vunerability. We can assume they do not since there has been no explicit work on closing the gap specifically for AMD.

The second issue is that there is no guarantee right now that the Intel patch will not affect AMD chip performance. Yes, there is a workaround, but officially this has not been accepted. So AMD will get screwed over in the short term too until the patches get refined over time. But it is a real concern that even AMD fanboys have voiced out.
 

Ark Law

Arch-Supremacy Member
Joined
Jan 29, 2013
Messages
11,540
Reaction score
495
TLDR of a TLDR;
2e4ksid.jpg



Here's Intel's press release :s13::s13:
dq51g3.jpg
 
Important Forum Advisory Note
This forum is moderated by volunteer moderators who will react only to members' feedback on posts. Moderators are not employees or representatives of HWZ. Forum members and moderators are responsible for their own posts.

Please refer to our Community Guidelines and Standards, Terms of Service and Member T&Cs for more information.
Top