Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

cyberus-technology.de

Post reply on HN
Print view View original

131–140 of 337 posts

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#131

Post by yalok »

ynnn wrote: post #120
yalok wrote: post #106

> macOS performance: Testing conducted by Apple in May 2019 showed as much as a 40% reduction in performance with tests that include multithreaded workloads and public benchmarks. Performance tests are conducted using specific Mac computers. Actual results will vary based on model, configuration, usage, and other factors. from here: https://support.apple.com/en-us/HT210107

Yeah, if you choose to turn off hyperthreading. Pretty expected tbh - hyperthreading helps quite a bit for some things.

but I don't see Intel mentioning this 40% anywhere... by Intel words, the worst degradation is 9%, and it creates an impression that it's with HT off.

If you choose not to disable HT, you stay vulnerable even with updated microcode, right?

In any case, Apple's stats are much more gruesome...

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#132

Post by dfrage »

TomVDB wrote: post #43
faissaloo wrote: post #18

Earlier quoted context omitted.

I wonder at what point the hardware fix for these issues stop becoming worthwhile and if we'll see a resurgence of processors without speculative execution or any of these other speed ups.

If ARM and AMD CPUs are not affected, then speculative execution in general is not the issue.

But they are, ARM to both a Meltdown variant and Spectre, as well IBM's POWER and mainframe chips, and AMD to Spectre.

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#133

Post by dfrage »

kentonv wrote: post #83
makomk wrote: post #30

Earlier quoted context omitted.

Not necessarily. This is more like Meltdown in that it involves one context just outright accessing data in a completely different context, and AMD chips seem to be totally immune from that attack. Any chip with a microarchitecture that actually enforces the architecturally-guaranteed checks, rather than ignoring them and fixing the results up later, can avoid such attacks. Spectre, on the other hand, is harder both…

> This is more like Meltdown in that it involves one context just outright accessing data in a completely different context, and AMD chips seem to be totally immune from that attack. No, AMD has been largely immune to bugs involving speculating past a page fault . Both Meltdown and L1TF involved speculating past page faults, and the ZombieLoad paper also mentions exploiting bad behavior during page faults (but, discl…

And ARM had one design that had a Meltdown variant, and both of IBMs', POWER and mainframe as well. Every vendor with speculative out-of-order designs is vulnerable to Spectre.

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#134

Post by rini17 »

faissaloo wrote: post #18
jamiek88 wrote: post #5

9% hit potentially on performance in data center. Add in all the Spectre and meltdown mitigations and we have potentially lost nearly two generations of Intel performance increases. Just shows the hoops and tricks needed to keep making, on paper, faster processors year on year but without node shrinks to give headroom. 14nm++++ is played out.

I wonder at what point the hardware fix for these issues stop becoming worthwhile and if we'll see a resurgence of processors without speculative execution or any of these other speed ups.

The industry will probably get dragged, kicking and screaming, into using tagged pointers. CPU could then use the information to put safe lid on speculative execution.

And it will be tough as no compiler supports it, moreover C/C++ are architected from the beginnign to not bother with runtime information about object types/sizes.

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#135

Post by FluffyKitty »

yalok wrote: post #131
ynnn wrote: post #120

Earlier quoted context omitted.

Yeah, if you choose to turn off hyperthreading. Pretty expected tbh - hyperthreading helps quite a bit for some things.

but I don't see Intel mentioning this 40% anywhere... by Intel words, the worst degradation is 9%, and it creates an impression that it's with HT off. If you choose not to disable HT, you stay vulnerable even with updated microcode, right? In any case, Apple's stats are much more gruesome...

It really is going to depend on what test you are running. HT has the greatest effect when the running process has a lot of "downtime" for things like memory retrieval or any I/O as it allows for other processes to make use of this downtime. So if your tests are just doing calculations with very little file/network I/O it could very well be in the 9% range.

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#136

Post by bitL »

Fej wrote: post #94
cfallin wrote: post #88

Earlier quoted context omitted.

The stream of critical CPU vulnerabilities starting with Spectre/Meltdown last year are related to speculative execution , not just Intel. (AMD and ARM CPUs are also vulnerable to Spectre, for example.) Intel CPUs are sometimes vulnerable to additional attacks because they speculate in more scenarios than other designs. But fundamentally, as long as multiple different trust domains are sharing one CPU that speculates…

Yes, the vulnerabilities are not just Intel, but they're mostly limited to Intel CPUs. Why is AMD less prone to these mistakes? Perhaps there are simply fewer researchers looking into AMD processors?

They have different cache architectures; Intel uses inclusive (i.e. all levels contain keys from previous levels), AMD uses exclusive cache (each level contains unrelated entries to any other level). This might have different effects on classes of vulnerabilities they are prone to.

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#137

Post by dfrage »

nine_k wrote: post #16
ksec wrote: post #10

Sorry for being naive. Are these kind of CPU Securities vulnerabilities new? Why it is in the past 20 years we have had close to zero in the news ( At least I wasn't aware of any ) and ever since Spectre and Meltdown we have something new like every few months. And as far as I am aware they are mostly Intel CPU only. Why? And Why not AMD? Something in the Intel design process went wrong? And yet all the Cloud Vendor…

Running many instances of various untrusted code on the same server is "new": it came with the cloud infrastructure. Running many instances of various untrusted code on the same client machine is "new": it came with web apps, and with mobile apps. Before several years ago, it was sort of a non-issue, because to exploit such a vulnerability one would need to write a virus or a trojan, and with this approach, there are…

https://en.wikipedia.org/wiki/Time-sharing

Time sharing was very big in the 1970s, and non-OS/VM methods of sharing mainframes for batch processing were also big at times I'm less sure of.

Inviting complete randoms to routinely run untrusted code in your own security domain, as we do with browsers, that's "new". And thus the popularity of NoScript and uMatrix.

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#138

Post by echopom »

Fej wrote: post #76

What is the recommended course of action? Stop buying Intel products, and devices which contain them? What about devices with older processors? I'm still running a Sandy Bridge rig and it works fine, except for the side channel vulnerablities. It's probably not going to be patched. I also have a cheaper computer with a Skylake processor, which is newer yet still vulnerable! It's only a matter of time until something…

> What is the recommended course of action? Stop buying Intel products, and devices which contain them?

There is absolutely nothing to be done on our level about this.

I'm fairly convinced this is systemic issue that can only be solved by redesigning almost entirely modern cpus and computers architecture.

I can draw a parallel to approximately all Intel cpus which are know to have a dedicated "mini cpu" called "Minix" which is an absolute "black box" and have been found to be vulnerable for to a wide variety of attack for nearly decades...

Not only we need to redesign computers and cpu architecture but we desperately need to make that entire process and knowledge open source , available to all and more transparent.

Today this entire knowledge is the hand of few gigantic corps whom are keeping it to ensure their monopolistic position.

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#139

Post by bitL »

INTPenis wrote: post #104

So I'd love to post an Ask HN: Which AMD Laptops would you recommend for work, alternatives to Thinkpads? I've noticed some Thinkpads with AMD CPUs but I feel like I'm on virgin ground when it comes to AMD and their integrated GPU offerings.

You can't really find a good AMD workhorse laptop; all of them end up with some outdated 1080p displays at best :( There is like only one notebook with a decent HiDPI screen with Ryzen (some HP, but not a workhorse). There was also terrible problem with Mobile Ryzen drivers resolved only like a month ago.

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#140

Post by Gibbon1 »

dexen wrote: post #50
farisjarrah wrote: post #45

Earlier quoted context omitted.

I feel like people with these sorts of hardline views on security, might just be so concerned with safety that their argument misses the whole opportunity cost of not being 100% safe in our usage of technology. If we needed to make sure everything was safe and perfectly secure, the world would have missed out on a lot of innovative software. Tough thing to contend with is that the security people are hardly ever wron…

>hardline views on security The only hardline view on security you'll encounter in the wild is "security is practical in our computational environments"[1]. Only half-joking here. My reading of Theo's quote is merely "the combination of x86/IA32/AMD64 and virtualization gives little to no factual security benefits, and plenty of pitfals". I don't see Theo as being a hardliner about security, just meticulous about goo…

> examples: "Rust/Java gives you security"

Reminds me a friend who worked on Javascript in the early days said it was the only thing that had any hope of providing minimal security at the time. Because Windows 3.1 and 95 +0x86 was a security trashfire.

Post reply on HN