Live data from Hacker News

ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

cyberus-technology.de

151–160 of 337 posts

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

#151
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.

Ironically, a high performance, general purpose architecture without speculative execution might require a deep reinvestment in SMT. Instead of trying to speculatively make one thread fast to mask IO stalls, run a large pool of threads that can stall frequently but still keep the execution units and memory channels busy.

To avoid reintroducing these spectre like bugs, you'd have to conservatively design the per-thread execution to avoid those covert channels. Not only synchronously enforcing all logical ISA guarantees for paging and other exception states, but also using more heavy-handed tagging methods to partition TLB, cache, etc. for separate protection domains.

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

#152
I just want to plug their course hardware security (at the VU University Amsterdam). It's an amazing course and it costs 1200 euro's for students who need to pay full price. I've learned a lot about Spectre, Meltdown and novel forms of cache attacks and Rowhammer when I took it.

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

#154

Apparently Intel attempted to play down the issue by trying to award the researchers with the 40,000 dollar tier reward and a separate 80,000 dollar reward as a "gift" (which the researchers kindly denied) instead of the maximum 100,000 reward for finding a critical vulnerability. Intel was also planning to wait for at least another 6 months before bringing this to light if it wasn't for the researchers threatening t…

> Intel was also planning to wait for at least another 6 months before bringing this to light

Of course, until the legally agreed date when they can dump shares so there’s no obvious proof that it’s insider trading. Isn’t that what (then) Intel CEO Brian Krzanich did after Meltdown/Spectre?

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

#155
Some information for Linux, from LWN.net (https://lwn.net/Articles/788381/): "See this page from the kernel documentation (https://www.kernel.org/doc/html/latest/x86/mds.html#mds) for a fairly detailed description of the problem, and this page (https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/m...) for mitigation information."

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

#156
Is there any clear source of info for sysadmins responding to the many CPU-level vulns in the past year? It's very difficult to keep track of whether fixes are needed at ucode, OS, and/or application level, and what version numbers fix each bug.

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

#157
post #136
post #94

Earlier quoted context omitted.

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.

I know that some AMD CPUs a long time ago had exclusive caches, but for Ryzen, I'm pretty sure that both L1 and L2 are inclusive, and L3 a victim cache.

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

#158

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.

Ironically, a high performance, general purpose architecture without speculative execution might require a deep reinvestment in SMT. Instead of trying to speculatively make one thread fast to mask IO stalls, run a large pool of threads that can stall frequently but still keep the execution units and memory channels busy. To avoid reintroducing these spectre like bugs, you'd have to conservatively design the per-threa…

AKA a barrel processor:

https://en.wikipedia.org/wiki/Barrel_processor

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

#159
post #39

Earlier quoted context omitted.

Well, dedicated machines for each security domain for each customer, a lot of the time it's fine for many applications to be in the same security domain.

Even this isn't enough. Sometimes mutually untrusted parties must exchange data (say you're running a trading platform, or a social network). You have to ensure every point of interaction between such parties is immune to timing attacks.

In theory, yes. But getting statistically meaningful data on sub-ms timing variations on a jittery connection with both round trip and jitter orders of magnitudes larger is hard... it would be a very, very slow attack and probably impractical in most cases.

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

#160
post #79

Earlier quoted context omitted.

But like, those bugs were there. They might have been being exploited and not been caught. Your argument sounds like an argument against responsible disclosure totally.

I'm not reading anything against responsible disclosure in deaken's comments. How are you getting that?

The whole "since they published that it happened, we've had a bunch of disclosures" which is a typical "I don't feel safer when people talk openly about unfixed vulnerabilities" argument.
Post reply on HN