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

311–320 of 337 posts

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

#311

Post by dfrage »

nine_k wrote: post #308
dfrage wrote: post #137

Earlier quoted context omitted.

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.

Indeed! Though time-sharing was more like a terminal server, or shared hosting, while OS/VM was more like a modern VM host. It's interesting though why cross-process data exfiltration based on speculative execution was not tried with any success in the shared hosting environment of 1990s and early 2000s. I suppose it has something to do with the use of non-JIT-ted interpreted languages, like PHP, Perl, or SQL, on suc…

> It's interesting though why cross-process data exfiltration based on speculative execution was not tried with any success in the shared hosting environment of 1990s and early 2000s.

According to several of the researchers who found Meltdown and/or Spectre, they'd always assumed Intel et. al. were too careful to let this happen, at least at useful data rates. But when they looked for reasons I forget, Katie bar the door!

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

#312

Post by nine_k »

cfallin wrote: post #88
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…

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…

Really, different trust domain cannot seriously benefit from a common cache: their datasets are by definition disjoint.

So it would be safest to execute them on separate CPUs not sharing a common cache, e.g. pinning them to different CPU sockets on a multi-socket machine, or to different physical machines altogether.

This may be still faster than running on old ARMs.

I wonder if dedicated cloud boxes, where all VMs you spin on a particular physical machine belong only to your account, will become available from major cloud providers any time soon. In such a setup, you don't need all the ZombieLoad / Meltdown / Spectre mitigations if you trust (have written) all the code you're running, so you can run faster.

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

#313

Post by gnode »

makomk wrote: post #110
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…

That's not exactly true. Broadly speaking, there have been two very different kinds of speculative execution vulnerabilities with different security implications and workarounds. Spectre and its relatives are an attack on trusted code that process untrusted data using certain code patterns guarded by conditionals that can be speculatively executed; they're inherent to speculative execution past branches, but they req…

> There's nothing inherent about modern high-performance CPUs that requires them to be designed this way.

Assuming by "designed this way" you mean: to speculatively execute past security checks, I'd disagree.

I'd say the relevant performance measure for CPUs (as opposed to other kinds of processor) is the speed at which they can execute serial operations. As electronic performance improvements offer increasingly marginal gains, we need to resort to improved parallelism. When operations are needfully serial due to dependency, as are security checks, the only way to accelerate that beyond the limits of the electronics is to make assumptions (speculations).

It's not inherently wrong to do this, but requires speculations never have effects outside of their assumptive execution context.

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

#314

Post by dfrage »

nine_k wrote: post #312
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…

Really, different trust domain cannot seriously benefit from a common cache: their datasets are by definition disjoint. So it would be safest to execute them on separate CPUs not sharing a common cache, e.g. pinning them to different CPU sockets on a multi-socket machine, or to different physical machines altogether. This may be still faster than running on old ARMs. I wonder if dedicated cloud boxes, where all VMs y…

> different trust domain cannot seriously benefit from a common cache: their datasets are by definition disjoint.

Datasets, yes, but what about instructions from shared libraries?

I'll make a wild guess this being seriously beneficial would be limited to uncommon server configurations....

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

#315

Post by nine_k »

dfrage wrote: post #314
nine_k wrote: post #312

Earlier quoted context omitted.

Really, different trust domain cannot seriously benefit from a common cache: their datasets are by definition disjoint. So it would be safest to execute them on separate CPUs not sharing a common cache, e.g. pinning them to different CPU sockets on a multi-socket machine, or to different physical machines altogether. This may be still faster than running on old ARMs. I wonder if dedicated cloud boxes, where all VMs y…

> different trust domain cannot seriously benefit from a common cache: their datasets are by definition disjoint. Datasets, yes, but what about instructions from shared libraries? I'll make a wild guess this being seriously beneficial would be limited to uncommon server configurations....

Let's dissect.

- Same OS, server: you likely control all the processes in it anyway, no untrusted code.

- Different OSes in different VMs, server: they likely run different versions of Linux kernel, libc, and shared libraries anyway. They don't share the page caches for code they load from disk.

- Browser with multiple tabs, consumer device: likely they might share common JS library code on the browser cache level. The untrusted code must not be native anyway, and won't load native shared libraries from disk.

- Running untrusted native code on a consumer device: well, all bets are off if you run it under your own account; loading another copy of msvcrt.dll code is inconsequential compared to the threat of it being a trojan or a virus. If you fire up a VM, see above.

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

#316

Post by effie »

rini17 wrote: post #134
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.

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.

That sounds interesting. Is there some analysis out there which shows tagged pointers to be superior to the status quo?

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

#317

Post by bitdivine »

nine_k wrote: post #312
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…

Really, different trust domain cannot seriously benefit from a common cache: their datasets are by definition disjoint. So it would be safest to execute them on separate CPUs not sharing a common cache, e.g. pinning them to different CPU sockets on a multi-socket machine, or to different physical machines altogether. This may be still faster than running on old ARMs. I wonder if dedicated cloud boxes, where all VMs y…

Scaleway is one such provider. They call it not virtualization but physicalisation.

I should add that AWS has "dedicated instances" which are exclusive to one customer. They are more expensive than standard instances but they are used by e.g. the better financial services companies for handling customer data.

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

#318

Post by [deleted] »

close04 wrote: post #154
fakwandi_priv wrote: post #114

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?

[deleted]

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

#319

Post by dfrage »

nine_k wrote: post #315
dfrage wrote: post #314

Earlier quoted context omitted.

> different trust domain cannot seriously benefit from a common cache: their datasets are by definition disjoint. Datasets, yes, but what about instructions from shared libraries? I'll make a wild guess this being seriously beneficial would be limited to uncommon server configurations....

Let's dissect. - Same OS, server: you likely control all the processes in it anyway, no untrusted code. - Different OSes in different VMs, server: they likely run different versions of Linux kernel, libc, and shared libraries anyway. They don't share the page caches for code they load from disk. - Browser with multiple tabs, consumer device: likely they might share common JS library code on the browser cache level. T…

There's also Same OS, operating system level virtualization, like Docker, it's the less expensive default for https://www.ramnode.com/vps.php for example. Not at all familiar with this technology, but scanning Wikipedia if you used Docker would the libcontainer library be shared between container instances?

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

#320

Post by effie »

aflag wrote: post #282
mda wrote: post #197

Earlier quoted context omitted.

Sure, but please don't downplay this, so far Intel CPU's are affected by way more vulnerabilities that could be exploited much easily. It is a no brainer to pick if I have to choose between AMD and Intel today.

Way more known vulnerabilities. They also have a much smaller share of the market. I'd be surprised if researchers were targeting it as much.

Yes, but also I would be surprised if attackers were targeting AMD as much.
Post reply on HN