Reading privileged memory with a side-channel • Hacker News Board

Re: Reading privileged memory with a side-channel

#621

Post by pgt » Fri, Jan 05, 2018, 6:12 PM UTC

314 wrote: post #537

hyperion2010 wrote: post #430

An analogy that was useful for explaining part of this to my (non-technical) father. Maybe others will find it helpful as well. Imagine that you want to know whether someone has checked out a particular library book. The library refuses to give you access to their records and does not keep a slip inside the front cover. You can only see the record of which books you have checked out. What you do is follow the person…

Your analogy is more apt for side-channel attacks in general. Here is a more specific version for Meltdown: A library has two rooms, one for general books and one for restricted books. The restricted books are not allowed out of the library, and no notes or recordings are allowed to be taken out of the restricted room. An attacker wants to sneak information out of the restricted room. To do this the pick up a pile of…

I don't understand this explanation :/ Why is the room considered restricted if you can go inside? Do I know how all books that exist in the library? How does the order of the thrown out books pertain to the secret book?

Re: Reading privileged memory with a side-channel

#622

Post by bonzini » Fri, Jan 05, 2018, 8:03 PM UTC

PeterisP wrote: post #618

bonzini wrote: post #539

Earlier quoted context omitted.

Disabling indirect branch prediction (and thus speculation after indirect branches) while in kernel mode, or flushing the indirect branch predictor on kernel mode entry. Both need OS support in addition to the microcode, but the change is less invasive than PTI.

Wouldn't that be a serious performance hit?

It is. Same ballpark as PTI on microbenchmarks, but a little better on macrobenchmarks.

Re: Reading privileged memory with a side-channel

#623

Post by bonzini » Fri, Jan 05, 2018, 8:10 PM UTC

contrarian_ wrote: post #562

londons_explore wrote: post #545

Earlier quoted context omitted.

The mistake is clear from the design - thats why all CPU vendors are vulnerable to variants of the same bugs. Previously side channel attacks like this have been seen by the security community as unreliable things which only work in very specific cases and have to be averaged over millions of runs. This attack shows a side channel which is general purpose, reliable, and fast.

> The mistake is clear from the design There is no fundamental reason why speculative instructions should be allowed to mutate the cache. OTOH the contention-based side channel attack on speculation has been public knowledge for over a decade. [1] [1] Z. Wang and R. B. Lee, "Covert and Side Channels Due to Processor Architecture," 2006 22nd Annual Computer Security Applications Conference (ACSAC'06), Miami Beach, FL,…

> There is no fundamental reason why speculative instructions should be allowed to mutate the cache.

There is: hundreds of instructions can be in flight speculatively at the same time, especially if you take hyperthreading into account. Good luck rolling them all back.

The question is not whether the cache should be mutated during speculative execution. It's what kinds of speculative execution are allowed, and in some cases it's not even clear if fences should be placed by the programmer (whack-a-mole style), the compiler (not sure how) or the processor (probably not). It's non-obvious enough that how to solve it is to some extent a research problem.

Re: Reading privileged memory with a side-channel

#624

Post by londons_explore » Sat, Jan 06, 2018, 1:11 AM UTC

gmueckl wrote: post #453

londons_explore wrote: post #350

Earlier quoted context omitted.

The "speculation time" can be hundreds of cycles if you have a branch or memory read that takes a long time to resolve. This problem is already solved with speculative writes to main memory - a speculative store buffer keeps a sequence of memory operations which need to be done when the operation retires. These buffers are very power hungry, because every future speculative read must check every entry in the speculat…

What you are describing is sinply plain associative memory. If I remember correctly, this is complex in its imolementation, but does not grow exponentially. Plesse correct me if I am wrong.

fully associative memory is generally very power hungry.

Thats why in CPU's caches are usually "2 way associative" or "4 way associative".

That means the data you're looking for might be in one of 2 (or 4) places. Fully associative means the data you're looking for might be in any memory slot, and you're gonna have to check them all. Checking them all in parallel is possible, so it isn't a speed issue, but it is a massive power issue. Average power use is the main limiting factor in CPU's today.

In general in a CPU, transistors which stay in the same state don't use much power. Transistors changing state use power. In a fully associative memory, the transistors doing the comparing change state with every comparison. Whereas with a regular memory only the transistors for the individual bit of the memory being read or written change state and use power.

(the above is a simplification, but contains the key elements).

Re: Reading privileged memory with a side-channel

#625

Post by wilun » Sat, Jan 06, 2018, 3:32 AM UTC

bonzini wrote: post #564

contrarian_ wrote: post #542

Earlier quoted context omitted.

That only fixes one variant of Spectre, and only for code running in kernel mode. The "out of bounds" Spectre variant is still feasible. Also: What about hyperthreads? It seems to be many people's assumption that the BTB is shared within a physical core.

The out of bounds variant is fixable in the OS, just add a fence instruction between the check and the load. For code running in user mode, you flush the branch predictor on each context switch---again, new microcode + patched OS. Hyperthreads are tricky. Those are not yet fixed by microcode AIUI, and in the future you may want a usermode program to say "I don't want indirect branch prediction because I am afraid of…

Great. Now we just have to think of new attacks using the same general idea to slow down all computers by yet another 10% :p

Re: Reading privileged memory with a side-channel

#626

Post by wilun » Sat, Jan 06, 2018, 3:48 AM UTC

bonzini wrote: post #459

jhallenworld wrote: post #248

Earlier quoted context omitted.

I would think that any sane implementation would not transmit privileged data to waiting instructions. Look at their Listing 2: Instructions 5 - 7 will be waiting for the privileged data from line 4 (they are not speculatively executed since they have a data dependency on line 4). So why is Intel releasing the privileged data to the waiting instructions? An answer could be that violation checking is delayed until ret…

> I would think that any sane implementation would not transmit privileged data to waiting instructions. The point of VIPT caches is exactly to use data before all the checks are completed. It's easy to judge the sanity of things ex post, but maybe it's not that easy if it took 20 years to find the issue.

About Meltdown, it was well known since even before that speculative execution has to stop at security boundaries.

Re: Reading privileged memory with a side-channel

#627

Post by wilun » Sat, Jan 06, 2018, 4:28 AM UTC

contrarian_ wrote: post #508

FranOntanaya wrote: post #356

Earlier quoted context omitted.

It doesn't look that hard, and in any case, we will suffer the mitigation consequences either way.

Worse, no mitigation will ever be complete against Spectre, unless flat out disabling speculation across memory loads.

With the right new instructions inserted at the right place, assisted by a good type system, and a processor that does not share its resources like crazy in highly uncontrolled ways, this seems fixable.

Sadly, I feel the only part that won't happen will be the programming language part, but who knows.

Re: Reading privileged memory with a side-channel

#628

Post by guftagu » Sat, Jan 06, 2018, 5:47 AM UTC

jotux wrote: post #115

Papers describing each attack: https://meltdownattack.com/meltdown.pdf https://spectreattack.com/spectre.pdf From the spectre paper: >As a proof-of-concept, JavaScript code was written that, when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs (cf. Listing 2). Scary stuff.

Guys, can't we just detect a program doing spectre-like behavior and just kill it instead of having every other application suffer a performance hit by the proposed changes? Antivirus software already does similar stuff

Re: Reading privileged memory with a side-channel

#629

Post by ohazi » Sat, Jan 06, 2018, 9:21 AM UTC

pgt wrote: post #621

314 wrote: post #537

Earlier quoted context omitted.

Your analogy is more apt for side-channel attacks in general. Here is a more specific version for Meltdown: A library has two rooms, one for general books and one for restricted books. The restricted books are not allowed out of the library, and no notes or recordings are allowed to be taken out of the restricted room. An attacker wants to sneak information out of the restricted room. To do this the pick up a pile of…

I don't understand this explanation :/ Why is the room considered restricted if you can go inside? Do I know how all books that exist in the library? How does the order of the thrown out books pertain to the secret book?

> Why is the room considered restricted if you can go inside?

That's the bug. The guard only checks to see whether you're supposed to have access after you walk in and start (speculatively) rearranging books. One way to fix this bug would be to have the guard check your access at the door.

Re: Reading privileged memory with a side-channel

#630

Post by anonu » Sat, Jan 06, 2018, 3:09 PM UTC

How come this wasn't discovered sooner?

It would seem to me that all the really smart people who designed super-scalar processors and all the nifty tricks that CPUs do today - would have thought that these attacks would be in the realm of possibility. If that's the case - who's to say these attacks haven't been used in the wild by sophisticated players for years now?

Seems like the perfect attack. Undetectable. No log traces.