ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs • Hacker News Board

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

#321

Post by effie » Wed, May 15, 2019, 9:14 PM UTC

jancsika wrote: post #61

gmueckl wrote: post #35

Earlier quoted context omitted.

Would be cool to see a source for that one. Theo de Raadt is a hardliner whom I don't always agree with, but I'd like to know how visionary he actually was in this case (quite a bit by the looks of it).

I'm not a security person but I wanna practice trying to sum up his points: 1. There's no way in hell that a bunch of VMs running on one physical server is more secure than a bunch of different physical servers each running an OS. If there were architectural hooks for those VMs to provide additional security beyond what the host OS provides, then an OS like OpenBSD would already be making use of it. 2. Running a bunc…

Almost right, except one thing: I think Theo de Raadt wrongly did not acknowledge the valid point of his opponent: in practice, separating applications into virtual machines does have some security benefits, when compared to running them on single OS.

I think security guarranties are better if you follow practices of a little selfcentered project such as OpenBSD (run only trusted code) than if you follow practices of QubesOS (running whatever untrusted code you desire in Xen domains and relying on VM separation).

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

#322

Post by redrabbyte » Wed, May 15, 2019, 10:26 PM UTC

bitL wrote: post #136

Fej wrote: 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.

the inclusivity types don't really play a role in these types of attack (until you get to a very practical stage where this might matter), not least because there are other sidechannels that can be exploited. an inclusive llc is just convenient.

that said, some newer Intel LLCs are non-inclusive, and amd changed its cache relations as well in ryzen

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

#323

Post by nine_k » Wed, May 15, 2019, 10:50 PM UTC

dfrage wrote: post #319

nine_k wrote: post #315

Earlier quoted context omitted.

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?

Likely it would be. But really Docker is more about convenience of deployment and (much) less about security. I would not run seriously untrusted code in merely a (Docker) container; I don't know much about the isolation guarantees of OpenVZ.

In any case, containers share OS kernel, OS page cache, etc. This can be beneficial even for a shared hosting as a way to offer a wide range of preinstalled software as ro-mounted into the container's file tree. Likely code pages of software started this way would also be shared.

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

#324

Post by redrabbyte » Wed, May 15, 2019, 11:48 PM UTC

ahartmetz wrote: post #206

p1necone wrote: post #170

I'm sure I remember a post on here (or possibly /r/programming) a couple of years ago from an Intel employee mentioning that Intel was cutting a lot of QA staff, and that we should expect more bugs in the future. I could be imagining things though.

I remember a leak about a call to become "more agile" like some ARM designers, implying less time spent on verification.

verification wouldn't catch any of this, the processors operate correctly on an architectural level

most of this seems to be behaving as intended, they just didn't foresee the side channels this opens up

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

#325

Post by amluto » Wed, May 15, 2019, 11:49 PM UTC

amluto wrote: post #193

cfallin wrote: post #148

Earlier quoted context omitted.

Yes, that's true, several of the vulnerabilities involve checks that are performed late (not at time of speculative access, but at some point before instruction commit). Not excusing the design choice at all, but it's conceivable that an engineer could make this choice if (i) side-channel effects of the speculation are not considered at all, and (ii) the postponement of the check allows the load latency to be reduced…

I’m not a CPU architect, but it seems like Intel saved a couple gates by putting garbage instead of zeroes in the pipeline.

After reading more of the (limited, publicly known) details, it looks like the data leaked isn’t, strictly speaking, total garbage. But I do wonder whether Intel got a meaningful latency improvement by putting potentially wrong data into the pipeline instead of using zeroes or stalling. Zeroes or a stall would require knowing that the data is invalid before continuing with execution, which could be a performance issue.

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

#326

Post by redrabbyte » Wed, May 15, 2019, 11:58 PM UTC

XorNot wrote: post #169

dexen wrote: post #50

Earlier quoted context omitted.

>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…

Except that's objectively wrong - x86 virtualization breakouts have been extremely rare in practice, and fixable till recently. The new class of attacks we now see target any type of shared code execution environment. OpenBSD is as vulnerable to this as anything else.

there's a foreshadow-ng variant specifically for vms, and it's arguably the worst

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

#327

Post by repolfx » Thu, May 16, 2019, 9:07 AM UTC

zelon88 wrote: post #250

So far there seem to be far more of these vulnerabilities in Intel CPUs. Is that a reflection of engineering differences or a statistical byproduct of the market share of Intel CPUs? I run AMD not because of the security implications but because I feel every dollar that goes to Intel competition will push Intel and thus the entire industry forward.

Probably both - AMD chips have lower market share because they have lower performance, and they have lower performance (maybe) because they speculate less aggressively. Intel did these optimisations for a reason after all; the market rewards them.

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

#328

Post by makomk » Thu, May 16, 2019, 9:42 AM UTC

dang wrote: post #57

Url changed from https://zombieloadattack.com , which points to this. There is a home page about today's vulnerability disclosures at https://news.ycombinator.com/item?id=19911715 . We're disentangling these threads so discussion can focus on what's specific about the two major discoveries. At least I think there are two.

I think there's two seperate branded annoucemenst of three or four different vulnerabilities depending on how you count. (There are four CVEs and Intel lists four, but the researchers announced three.) Haven't seen much discussion of the specific differences between them, probably because they're subtle and not terribly relevant to most folks - they all involve one process speculatively reading memory it shouldn't be able to access via the memory access buffers within Intel CPUs, they just vary in which parts of the memory access machinery they use and how exactly they're exploited.

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

#329

Post by nathan_long » Thu, May 16, 2019, 6:58 PM UTC

These style of exploits remind me of "The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software" (2005) - http://www.gotw.ca/publications/concurrency-ddj.htm

> Chip designers are under so much pressure to deliver ever-faster CPUs that they’ll risk changing the meaning of your program, and possibly break it, in order to make it run faster.

> ...

> applications will increasingly need to be concurrent if they want to fully exploit CPU throughput gains that have now started becoming available and will continue to materialize over the next several years. For example, Intel is talking about someday producing 100-core chips; a single-threaded application can exploit at most 1/100 of such a chip’s potential throughput.

It seems the trend in programming languages is towards better concurrency support. But why don't we yet see 100-core chips? If chip makers had to forego all speculative execution and similar tricks, would that push us toward the many-core future?

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

#330

Post by TheOperator » Thu, May 16, 2019, 9:20 PM UTC

bitL wrote: post #273

TheOperator wrote: post #211

Earlier quoted context omitted.

1080p strikes me as the pinnacle of a workstation display for laptops right now since I highly doubt any productivity improvement from higher dpi is gonna beat out battery life in the vast majority of cases. Even in the one use case where it matters, 4k video production, theres a reasonable argument for using screens similar to what your consumers will use at least some of the time. Especially if it saves you money a…

Counterpoint to battery life argument against HiDPI displays are obviously retina MacBooks since 2012 (7 years ago). In addition I have a ZenBook with 3200x1800 and Core-M and its battery life is great. By outdated 1080p displays I also meant color accuracy, no HDR, bad viewing angles, slow latency etc. Seems like most AMD laptops are a dumping ground for old tech that can't be marketed as premium any longer. I'd rat…

Yeah but MBP aren't running 4k. 3k/2560p screens seem to have a lot easier time with battery life at the moment. I actually think Apple is being more sensible than say, Samsung when it comes to the resolutions they choose.

I looked at reviews of several laptops with a 1080 vs a 1440 vs a 4k option and 1440 > 4k was the biggest drop in battery life.