• Guest, The rules for the P & N subforum have been updated to prohibit "ad hominem" or personal attacks against other posters. See the full details in the post "Politics and News Rules & Guidelines."
  • Community Question: What makes a good motherboard?

Massive security hole in CPU's incoming?Official Meltdown/Spectre Discussion Thread

Page 61 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

LTC8K6

Lifer
Mar 10, 2004
28,523
1,569
126
This was responsibly disclosed, and continues to be responsibly disclosed in about the most efficient way possible given the surrounding factors. Both the entities (Amazon Security Research and Cyberus) are highly reputable and have skin in the game (especially given the AWS Datacenter underpinnings Amazon Security Research supports). Why do you believe "headlines and clicks" are driving this effort? This disclosure, and many of the Meltdown / Spectre disclosures have been handled very well given the scope, especially compared to that farce of a disclosure that was Ryzenfall.
I thought these were kept under wraps until solutions were found so that they could not be used by hackers. I thought that was the whole purpose of keeping them secret? Presumably hackers are unaware of them until they are published.

Fortunately no use of them has ever been found.
 

thecoolnessrune

Diamond Member
Jun 8, 2005
9,464
385
126
I thought these were kept under wraps until solutions were found so that they could not be used by hackers. I thought that was the whole purpose of keeping them secret? Presumably hackers are unaware of them until they are published.

Fortunately no use of them has ever been found.
All these assumptions you're making are based on the premise that there is a low possibility of hackers knowing about them. This is a false assumption. In this particular exploit, there's already an example of one researcher producing a functioning exploit in 5 hours. Patches were already in flight on BSD even though they didn't have all the details needed to address it (they fixed it based off rumors). Your assumptions on how these are disclosed also disregard the 2 way street that responsible disclosure composes.

Security researchers reach out to the affected product owner (and associated parties) and everyone agrees on a time table based largely on 3 factors.
1. That the product owner is interested in actually fixing the product.
2. That the product owner is making steady progress on resolving the issue.
3. That the issue itself does not become well known during that time.

In this case, it's really Point 3 that became the differentiating factor. Between the proof of concept exploits, and the various commits popping up in OS Patches, the exploit was considered too easy to implement (even if the practical application of it is too hard), to make it sensible to remain under wraps. In the interest of continued responsible disclosure, the attack process and other serious data are still being withheld at the request of Intel.

I'm still curious what you believe ASR and Cyberus have to gain from headlines and clicks.
 

LTC8K6

Lifer
Mar 10, 2004
28,523
1,569
126
All these assumptions you're making are based on the premise that there is a low possibility of hackers knowing about them. This is a false assumption. In this particular exploit, there's already an example of one researcher producing a functioning exploit in 5 hours. Patches were already in flight on BSD even though they didn't have all the details needed to address it (they fixed it based off rumors). Your assumptions on how these are disclosed also disregard the 2 way street that responsible disclosure composes.

Security researchers reach out to the affected product owner (and associated parties) and everyone agrees on a time table based largely on 3 factors.
1. That the product owner is interested in actually fixing the product.
2. That the product owner is making steady progress on resolving the issue.
3. That the issue itself does not become well known during that time.

In this case, it's really Point 3 that became the differentiating factor. Between the proof of concept exploits, and the various commits popping up in OS Patches, the exploit was considered too easy to implement (even if the practical application of it is too hard), to make it sensible to remain under wraps. In the interest of continued responsible disclosure, the attack process and other serious data are still being withheld at the request of Intel.

I'm still curious what you believe ASR and Cyberus have to gain from headlines and clicks.
Tom's for clicks, not Cerberus...
 

Gideon

Golden Member
Nov 27, 2007
1,094
1,945
136
OpenBSD is disabling hyperthreading because of security concerns. Now this will most certainly be a sizable hit (~30%) for some workloads:
https://www.phoronix.com/scan.php?page=article&item=intel-ht-2018&num=1

Unfortunately they plan to eventually disable all SMT implementations it seems :(

EDIT:
I just realized that the biggest hit will probably be to ARM Server CPUs. Things like 4-way SMT Cavium
ThunderX2
etc, but also all of those ARM rooters and network devices running on BSD and SMT enabled chips ...
 
Last edited:

Jimzz

Diamond Member
Oct 23, 2012
4,354
149
106
OpenBSD is disabling hyperthreading because of security concerns. Now this will most certainly be a sizable hit (~30%) for some workloads:
https://www.phoronix.com/scan.php?page=article&item=intel-ht-2018&num=1

Unfortunately they plan to eventually disable all SMT implementations it seems :(

EDIT:
I just realized that the biggest hit will probably be to ARM Server CPUs. Things like 4-way SMT Cavium
ThunderX2
etc, but also all of those ARM rooters and network devices running on BSD and SMT enabled chips ...
"SMT (Simultanious Multi Threading) implementations typically share TLBs and L1 caches between threads. This can make cache timing attacks a lot easier and we strongly suspect that this will make several spectre-class bugs exploitable. Especially on Intel's SMT implementation which is better known as Hypter-threading. We really should not run different security domains on different processor threads of the same core."

Really? Now I need to disable HT on my intel 3770 to be some what secure? :(
 

LTC8K6

Lifer
Mar 10, 2004
28,523
1,569
126
"SMT (Simultanious Multi Threading) implementations typically share TLBs and L1 caches between threads. This can make cache timing attacks a lot easier and we strongly suspect that this will make several spectre-class bugs exploitable. Especially on Intel's SMT implementation which is better known as Hypter-threading. We really should not run different security domains on different processor threads of the same core."

Really? Now I need to disable HT on my intel 3770 to be some what secure? :(
Why would Spectre/Meltdown affect you?
 

maddie

Diamond Member
Jul 18, 2010
3,363
2,277
136
Seems like a temporary hit. Just keep domains on separate cores vs separate threads.
 

coercitiv

Diamond Member
Jan 24, 2014
4,043
4,663
136
Are you joking? I have an intel CPU and all the fixes are reducing performance.
Your are already quite secure as long as we're talking about personal use. The only attack vector we need to be concerned with at personal level is through software that executes external code (from various sources) such as the browser. The other vector, malicious software that gains access to the machine, can easily do the damage without any Specter/Meltdown exploit. At browser level all major browser makers have made adjustments in their software to make sure timing attacks are not possible, hence even an unpatched "vulnerable" system won't have problems browsing the net. It's not a perfect solution but a very efficient one.

Going forward, the more time passes after the initial vulnerability reveal, the more software becomes inherently hardened against them, meaning the cost of mounting such an attack eventually overtakes the rewards. (again, talking about average Joe and his personal data/finances, not corporate/government level)

That having been said, it's still better to patch as best as possible any machine, for two reasons:
  • security much more important than performance, some software one is using may still be vulnerable
  • the more secured systems around the world, the less likely a large scale attack becomes (just like vaccines, a large mass of secure systems protects the other ones due to diminishing returns on attack profit)
 

wahdangun

Golden Member
Feb 3, 2011
1,004
139
106
OpenBSD is disabling hyperthreading because of security concerns. Now this will most certainly be a sizable hit (~30%) for some workloads:
https://www.phoronix.com/scan.php?page=article&item=intel-ht-2018&num=1

Unfortunately they plan to eventually disable all SMT implementations it seems :(

EDIT:
I just realized that the biggest hit will probably be to ARM Server CPUs. Things like 4-way SMT Cavium
ThunderX2
etc, but also all of those ARM rooters and network devices running on BSD and SMT enabled chips ...
maybe CMT design will come back ?
 
  • Like
Reactions: lightmanek

Jimzz

Diamond Member
Oct 23, 2012
4,354
149
106
My Haswell systems are reported to be fully patched with good performance.
My Ivy Bridge system is reported to be Meltdown protected only, with slower performance, but I cannot notice any slower performance.

This is based on Inspectre:
https://www.grc.com/inspectre.htm

So you admit it hurts performance yet question why someone would care? Do you even read what you write?
 

LTC8K6

Lifer
Mar 10, 2004
28,523
1,569
126
So you admit it hurts performance yet question why someone would care? Do you even read what you write?
I asked why the exploits would affect him, not why he would care.

Unless he's running a server or something?

Most home users are unlikely to notice anything from the patches, unless they like to run benchmarks.

The exploits are also unlikely to affect unpatched systems, unless they are run recklessly.
 

Jimzz

Diamond Member
Oct 23, 2012
4,354
149
106
I asked why the exploits would affect him, not why he would care.

Unless he's running a server or something?

Most home users are unlikely to notice anything from the patches, unless they like to run benchmarks.

The exploits are also unlikely to affect unpatched systems, unless they are run recklessly.

YOU said "Why would Spectre/Meltdown affect you?". Then you admit they affect performance. Are you really that hard headed or just ignoring the obvious? Your post already come off like a intel fanboy and these just make you look worst.
So which is it?
 

LTC8K6

Lifer
Mar 10, 2004
28,523
1,569
126
YOU said "Why would Spectre/Meltdown affect you?". Then you admit they affect performance. Are you really that hard headed or just ignoring the obvious? Your post already come off like a intel fanboy and these just make you look worst.
So which is it?
Right, why would the exploits affect a home user?
Does anyone know?
Are normal home use computers really slowed down so much by the patches that it's noticeable without running a benchmark?

Only my IB system reports being slower, and it's not yet fully patched, and I cannot notice any slowdowns.
 

IEC

Elite Member
Super Moderator
Jun 10, 2004
13,923
3,588
136
Right, why would the exploits affect a home user?
Does anyone know?
Are normal home use computers really slowed down so much by the patches that it's noticeable without running a benchmark?

Only my IB system reports being slower, and it's not yet fully patched, and I cannot notice any slowdowns.
I mean, people like me have previously reported that there is a significant hit to disk performance and response time on consumer hardware. In fact, that's what prompted a lot of us to run the benchmarks in the first place as something felt "off" after the patches/microcode updates.

P1.30 UEFI (no MC patch):
Sequential Read (Q= 32,T= 1) : 1967.230 MB/s
Sequential Write (Q= 32,T= 1) : 1326.054 MB/s
Random Read 4KiB (Q= 8,T= 8) : 1169.721 MB/s [ 285576.4 IOPS]
Random Write 4KiB (Q= 8,T= 8) : 1034.159 MB/s [ 252480.2 IOPS]
Random Read 4KiB (Q= 32,T= 1) : 514.705 MB/s [ 125660.4 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 687.330 MB/s [ 167805.2 IOPS]
Random Read 4KiB (Q= 1,T= 1) : 43.424 MB/s [ 10601.6 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 156.527 MB/s [ 38214.6 IOPS]

P1.60 UEFI (0x84 MC patch):
Sequential Read (Q= 32,T= 1) : 1947.143 MB/s
Sequential Write (Q= 32,T= 1) : 1361.696 MB/s
Random Read 4KiB (Q= 8,T= 8) : 1047.426 MB/s [ 255719.2 IOPS] -10.46% IOPS
Random Write 4KiB (Q= 8,T= 8) : 1087.049 MB/s [ 265392.8 IOPS] +5.11% IOPS
Random Read 4KiB (Q= 32,T= 1) : 311.168 MB/s [ 75968.8 IOPS] -39.54% IOPS
Random Write 4KiB (Q= 32,T= 1) : 386.990 MB/s [ 94480.0 IOPS] -43.70% IOPS
Random Read 4KiB (Q= 1,T= 1) : 40.586 MB/s [ 9908.7 IOPS] -6.54% IOPS
Random Write 4KiB (Q= 1,T= 1) : 120.764 MB/s [ 29483.4 IOPS] -22.85% IOPS
This is before the new round of Spectre v3a/v4 (NG) patches are out which will come with additional 2-8% penalties per Intel.

And that's not counting my significantly reduced VM performance which is closer to the impacts (derived from real-world workplace testing) I described here:
https://forums.anandtech.com/threads/predictions-for-ryzen-epyc-nodes-and-products-into-2021.2548918/page-2#post-39465241

<redacted> on XenApp: 14-41% CPU utilization impact
<redacted> on Windows client OSes on Horizon VDI: 31%+ increase in CPU util and significant response time impact even after adding additional hardware
<redacted> on Horizon RDSH: 33%+ increase in CPU util and significant response time impact even after adding additional hardware

Skylake Xeons (Scalable series) shows the least impacts at 8-17% depending on workload while v3 and v4 Xeons can have over 40% CPU util impact and >70% response time impact in the worst case for <redacted>.
Just because you aren't sensitive to it doesn't mean there aren't significant and noticeable performance impacts.
 

Jimzz

Diamond Member
Oct 23, 2012
4,354
149
106
Right, why would the exploits affect a home user?
Does anyone know?
Are normal home use computers really slowed down so much by the patches that it's noticeable without running a benchmark?

Only my IB system reports being slower, and it's not yet fully patched, and I cannot notice any slowdowns.

So the systems are not slower unless you measure them... What?

I love how you keep dancing around it. Yea they are slower but I don't notice unless I measure it
 

LTC8K6

Lifer
Mar 10, 2004
28,523
1,569
126
I mean, people like me have previously reported that there is a significant hit to disk performance and response time on consumer hardware. In fact, that's what prompted a lot of us to run the benchmarks in the first place as something felt "off" after the patches/microcode updates.



This is before the new round of Spectre v3a/v4 (NG) patches are out which will come with additional 2-8% penalties per Intel.

And that's not counting my significantly reduced VM performance which is closer to the impacts (derived from real-world workplace testing) I described here:
https://forums.anandtech.com/threads/predictions-for-ryzen-epyc-nodes-and-products-into-2021.2548918/page-2#post-39465241



Just because you aren't sensitive to it doesn't mean there aren't significant and noticeable performance impacts.
Thanks, that was a good and proper answer.
 

wahdangun

Golden Member
Feb 3, 2011
1,004
139
106
Doubt it. One reason being stupid software licenses based on per-core basis. WIth cmt you pay for 2 cores while not actually having performance of 2 cores. With SMT you pay for 1 core only.
Depends on software, if it's open source, it's usually per socket.

It's just retarded way of licensing with per core. It's like limiting license based on frequency. And if wider core and smt take off in the future I'm expecting that retarded licensing will change to thread count.
 

amd6502

Senior member
Apr 21, 2017
830
274
106

wahdangun

Golden Member
Feb 3, 2011
1,004
139
106
This is why I think Piledriver based servers are still relevant today. Not the most energy efficient, but very robust.

There are some real concerns with SMT https://www.techspot.com/news/75240-researchers-warn-new-hyper-threading-based-intel-cpu.html

Maybe this is a big reason why in the acorn world SMT isn't all that widespread. It might be part of the appeal of ARM servers

But, even with performance hit, construction core is still slower.

Because for it's workload ARM cpu doesn't need smt and the core is not wide enough, and since they are quite small and power efficient they can just cramp as many core they can get.
 

ninaholic37

Golden Member
Apr 13, 2012
1,883
30
91
Are you joking? I have an intel CPU and all the fixes are reducing performance.
I thought LTC8K6 was saying "you don't need to patch your home system", not "adding the patches won't affect performance", as the former interpretation makes a lot more sense to me.
 

ASK THE COMMUNITY