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

211–220 of 337 posts

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

#211

Post by TheOperator »

bitL wrote: post #139
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.

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 and you get to use discounted top performing cpus to boot.

Realistically the AMD laptops lack of color accuracy compared to shit like the trutone Intel macs, and lack of display connectivity especially compared to a thunderbolt outfitted x1 extreme that can connect to four 4k displays is a bigger problem. Especially since external displays actually need the resolution.

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

#212

Post by waddlesplash »

IgorPartola wrote: post #174
dragontamer wrote: post #119

Earlier quoted context omitted.

> Why don't we have a CPU architecture where a master core is dedicated to running the kernel and a bunch of other cores run userland programs? How will your "userland core" switch to other userland programs safely? A pointer-dereference can be a MMap'd file, so its actually I/O. This will cause the userland program to enter kernel-mode to interact with the hardware (yes, on code as simple as blah = (this->next)... t…

Sounds like we would need a new paradigm for how to handle that. But it seems to me that x86 is in now way the panacea of COU design. Wouldn’t you gain some good trade offs by changing up how things are done?

What the commenter above you was describing about mmap'ed files and dereferencing invoking the kernel implicitly -- that's true on all current CPU architectures (everything from x86 to SPARC to ARM and back again.)

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

#213

Post by gpderetta »

IgorPartola wrote: post #175
mochomocha wrote: post #128

Earlier quoted context omitted.

You'd also need to duplicate the whole memory hierarchy of CPU caches to prevent cache attacks against your "kernel CPU".

Would the kernel even need RAM access for its internal operations? It seems like today’s CPU caches are so large that a kernel could safely operating without ever leaving the chip, aside from anything that the userland asks it to work on. So in that case you wouldn’t need to ever run userland code against kernel CPU’s caches.

The pagetable itself can be very large; disk cache and network buffers can also take a huge amount of memory and are probably great targets for data exfiltration.

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

#214

Post by cfallin »

tomxor wrote: post #188
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…

> The safest bet now for the best security is probably to stick to in-order CPUs out-of-order execution != speculative execution. It is possible to have OoO without speculative execution. On the other hand they do tend to come as a pair since they both utilise multiple execution units, for instance the Intel Pentium in 1993 was the first x86 to have OoO or branch prediction (486 and those before were scalar CPUs).

> It is possible to have OoO without speculative execution

That's technically correct (the best type of correct!), but without speculation, the CPU can't see beyond a branch, so the window in which the machine can reorder instructions is very small. (For x86 code, the usual rule of thumb is that branches occur once per 5 instructions.) So in practical terms, an OoO design (in the restricted-dataflow paradigm, i.e., all modern general-purpose OoO cores) always at least does branch prediction, to keep the machine adequately full of ops.

An interesting question, though, given that we're going to do speculation, is what types of speculation the core can do. The practical minimum is just branch prediction, but modern cores do all sorts of other speculation in memory disambiguation, instruction scheduling, and the like, some of which has enabled real side-channel attacks (e.g., Meltdown).

Also, FWIW, Pentium was 2-way superscalar, but not OoO in the fully general dataflow-driven sense; the Pentium Pro (aka P6), in 1995, was the first OoO. (Superscalar can technically be seen as OoO, I suppose, in that the machine checks dependencies and can execute independent instructions simultaneously, but it's not usually considered as such, as the "reordering" window is just 2 instructions.)

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

#215

Post by gpderetta »

saltcured wrote: post #151
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.

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…

SUN tried the flock of (in-order) chickens in the past, targeting JVM workloads. It wasn't great.

On the other hand GPUs are pretty much what are you describing: excellent for some specific workloads, terrible for others.

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

#216

Post by dfrage »

gpderetta wrote: post #208
tomxor wrote: post #188

Earlier quoted context omitted.

> The safest bet now for the best security is probably to stick to in-order CPUs out-of-order execution != speculative execution. It is possible to have OoO without speculative execution. On the other hand they do tend to come as a pair since they both utilise multiple execution units, for instance the Intel Pentium in 1993 was the first x86 to have OoO or branch prediction (486 and those before were scalar CPUs).

OoO without speculation is completely pointless: the tipical reorder window is orders of magnitude larger than the average number of instructions between conditional jumps. I don't think there have ever been an OoO CPU without speculation. OTOH speculation without OoO Is not only possible but in fact very common. For example the majority of non ancient in-order CPUs. In fact the original pentium, contrary to your sta…

> I don't think there have ever been an OoO CPU without speculation.

To the extent I've looked at it, without reading original documents, the original OoO design that current systems are based on, the IBM System 360/Models 91 and 95's floating point unit using Tomasulo's algorithm https://en.wikipedia.org/wiki/Tomasulo_algorithm didn't extend to speculative execution.

No doubt because gates were dear, implemented with discrete transistors, and that processor was a vanity project of Tom Watson Jr's. And memory was slow, core except for NASA's two 95's with 2 MiB of thin film memory at the bottom, and cache was still a couple of years out, introduced with the 360/Model 85. OoO becomes compelling when you have a fast and unpredictable memory hierarchy, as we started to have in a big way in the 1990s when we returned to this technique.

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

#217

Post by tux1968 »

rurban wrote: post #71
spockz wrote: post #2

According to their blog post[1], there is little you can do against this. Running different applications on different cpus help against them reading each other’s data but an rogue process can still read data from the “super ordinated kernel” or hypervisor.

Of course you can fix it. I fixed it in Dec 2018 for most such attacks in my safelibc memset_s implementation, but nobody wanted to use it, because securely purging the buffers with secrets via mfence was deemed to slow. So everybody can read your secrets via sidechannel attacks. These tiny MDS buffers need to be purged with verw or l1d_flush followed by an lfence. This needs to be added to memset and memset_s varian…

> This is much faster.

Hi. Am trying to understand what you meant here. That both "verw" or "l1d_flush followed by an lfence" are faster than "mfence" which you implemented in safelibc?

If so, why didn't you use these faster options yourself? My understanding was that these faster options needed to be handled at the hypervisor/kernel level, rather than in libc. If so, how is the attitude of glibc maintainers relevant?

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

#218

Post by mattnewton »

cududa wrote: post #189
nullwasamistake wrote: post #185

Earlier quoted context omitted.

Not sure why down voted, this sounds like the most logical reason

Because they’d eventually have to disclose when the vulnerability was discovered and that’d be extremely obvious what they’re doing?

Is it obvious if they have an existing plan to sell shares and are simply waiting for it to trigger? They can reasonably claim they took this action to protect consumers until they had a better fix

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

#219

Post by Narishma »

spamizbad wrote: post #147
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…

Step one: switch to in-order cores. Step two: cheekily author a Medium article titled Tomasulo's Algorithm Considered Harmful

Are in-order cores even fast enough to render a Medium article?

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

#220

Post by cyphar »

cududa wrote: post #189
nullwasamistake wrote: post #185

Earlier quoted context omitted.

Not sure why down voted, this sounds like the most logical reason

Because they’d eventually have to disclose when the vulnerability was discovered and that’d be extremely obvious what they’re doing?

It might be obvious, but that's exactly what Brian Krzanich did in 2017. He didn't get in any actual trouble for it even though the timing smelled blatantly like insider trading.
Post reply on HN