• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

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.
thecoolnessrune said:
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.
Click to expand...
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.
 
LTC8K6 said:
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.
Click to expand...

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.
 
thecoolnessrune said:
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.
Click to expand...
Tom's for clicks, not Cerberus...
 
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:
Gideon said:
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 ...
Click to expand...

"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? 🙁
 
Jimzz said:
"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? 🙁
Click to expand...
Why would Spectre/Meltdown affect you?
 
Jimzz said:
Are you joking? I have an intel CPU and all the fixes are reducing performance.
Click to expand...
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)
 
Gideon said:
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 ...
Click to expand...

maybe CMT design will come back ?
 
Jimzz said:
So you admit it hurts performance yet question why someone would care? Do you even read what you write?
Click to expand...
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.
 
LTC8K6 said:
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.
Click to expand...


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?
 
Jimzz said:
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?
Click to expand...
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.
 
LTC8K6 said:
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.
Click to expand...

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
Click to expand...

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/thread...oducts-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>.
Click to expand...

Just because you aren't sensitive to it doesn't mean there aren't significant and noticeable performance impacts.
 
LTC8K6 said:
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.
Click to expand...


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
 
IEC said:
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/thread...oducts-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.
Click to expand...
Thanks, that was a good and proper answer.
 
beginner99 said:
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.
Click to expand...

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 said:
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
Click to expand...


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.
 
Jimzz said:
Are you joking? I have an intel CPU and all the fixes are reducing performance.
Click to expand...
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.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top