Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Meltdown Proof-of-Concept

github.com

Post reply on HN
Print view View original

181–187 of 187 posts

Re: Meltdown Proof-of-Concept

#181

Post by krylon »

tptacek wrote: post #128
krylon wrote: post #79

Earlier quoted context omitted.

> by the way, that PoC was intense. Makes you wonder if the NSA knew about it all along :) Colin Percival found a very similar issue with Intel's implementation of SMT on the Pentium 4 in 2005: http://www.daemonology.net/papers/htt.pdf So the general idea of using timing attacks against the cache to leak memory has been known for at least that long. In 2016, two researchers from the University of Graz gave a talk at…

Can I put a plug in again for how fucking cool the Meltdown and Spectre attacks are? They're much more interesting than just cache timing, which as you note have been well-known for at least a decade (and much earlier in the covert channel literature). Unlike "vanilla" cache-timing attacks: * Meltdown and Spectre involve transient instructions, instructions that from the perspective of the ISA never actually run . *…

> Can I put a plug in again for how fucking cool the Meltdown and Spectre attacks are?

Yes, you can! :)

I get your point. From the perspective of somebody who normally does not deal with such low-level affairs, the difference to prior cache timing attacks is not /that/ obvious. It all looks like black magic to me, even after I roughly understand how it works.

Re: Meltdown Proof-of-Concept

#182

Post by Rondom »

vardump wrote: post #38
runesoerensen wrote: post #25

Earlier quoted context omitted.

Perhaps you're thinking of this bug report https://bugs.chromium.org/p/project-zero/issues/detail?id=11... Project Zero evaluated and relaxed their disclosure policy after that incident as described here https://googleprojectzero.blogspot.com/2015/02/feedback-and-...

One could also consider Microsoft leaking Meltdown here: https://twitter.com/aionescu/status/930412525111296000

Last time I checked, Alexandru Ionescu was not a Microsoft employee.

Re: Meltdown Proof-of-Concept

#183

Post by ridgeguy »

K0nserv wrote: post #158
ridgeguy wrote: post #138

Earlier quoted context omitted.

That link shows Meltdown in reference only to High Sierra, not Sierra. What am I missing?

You're right, can't believe I missed that. Edit: See the archive[0] apparently I'm not going mad and it used to say that the patch was applied to Sierra and El Capitan, but Apple has since changed that. 0: https://web.archive.org/web/20180105102220/https://support.a...

Thanks. I thought I was going nuts, too.

Re: Meltdown Proof-of-Concept

#184

Post by tsukikage »

tomatocracy wrote: post #119
tzs wrote: post #105

Earlier quoted context omitted.

> I believe one solution would be to put permission checks before the memory access, which would add serialized latency to all memory access. I don't see why that would have to add latency to all (or any) memory access. The addresses generated by programs (except in real mode, when everything has access to everything anyway so we don't care about these issues then) are virtual addresses, so they have to be translated…

Indeed - Meltdown has an "easy" fix and now it's known it should be possible to design chips which are not vulnerable. Spectre is, as you say, harder - but more because the line of what sort of state should be separate isn't as clear-cut as we might like it to be (i.e. it's not neccessarily just "processes" as the OS sees it - e.g. JVM/JavaScript interpreter state should allow for an effective sandbox between the exe…

If we're looking at hardware design changes, it really feels like what we actually need is to add a place to hold a nonce that the OS/hypervisor can set per-process/per-vm, and incorporate those bits in the CPU cache tags so cache lines never match across security boundaries, which would close the side channel used to exfiltrate information.

Re: Meltdown Proof-of-Concept

#185

Post by foota »

nialv7 wrote: post #163
foota wrote: post #98

Earlier quoted context omitted.

I don't think you can allow two speculatively executing instructions to read from the same L0 cache. For example say the memory address you want to look for being cached is either 0x100 or 0x200 (not realistic addresses but it works for example) based on some kernel memory bit. Then run instructions in userspace that try to fetch 0x100 (with flushes in between). If you notice one that completes quickly, then it must…

L0 is only used by speculatively executed uOPs, before they are actually committed. Therefore anything that reads from L0 has to be speculatively executed too. So if the uOP populated the L0 was reading from kernel memory, then it won't be committed. And subsequent uOP read from the L0 won't be committed either. So you can't get timing information from them.

But if another instruction reads from the same cache then that one could retire.

Re: Meltdown Proof-of-Concept

#186

Post by PeterisP »

samsonradu wrote: post #169

High-level programmer here. Can someone explain please (already read the ELI5 in previous threads) how does the attacker extract the actual data from the processor L1 cache after tricking the branch prediction and have the CPU read from an unauthorized memory location? I understood the "secret" data stays in the caches for a very short time until the branch prediction is rolled back, which makes this a timing attack…

It does not "stays in the caches for a very short time until the branch prediction is rolled back", the core of the problem is that speculative instructions caused by out of order execution or branch prediction leave a side-effect (whether some memory location was fetched to cache or not) that can be read for a long time afterwards.

The covert channel consists of a "sender" and a "receiver". The receiver can't extract contents of L1 cache, but it can detect which pages were in cache by timing differences. So the sender encodes the secret data by fetching particular addresses calculated so that the receiver can afterwards recover the secret by verifying which page(s) were in cache.

In Meltdown attack, the sender consists of instructions controlled by you - e.g. x=memory_you_shouldn't_access; y=array[1000x] - and after an Intel processor notices that you shouldn't access that memory and rolls back the instructions (invalidating y and x), the 1000x location was already pulled to cache, and you can check - is array[1000] cached? is array[2000] cached? is array[142000] cached? to determine x.

In Spectre attack, the sender consists of code in the vulnerable application that happens to contain similar instructions. Spectre attack means that if your application anywhere contains code like if (parameter is in bounds) {x=array1[parameter]} (...possibly some other code...) y=array2[x], then any attacker that (a) runs on the same CPU and (b) can manipulate the parameter somehow can trick this code to process the path "protected" by 'if' and reveal random memory out of bounds of that array1. The difference from ordinary buffer overflow bugs is that code like that is normal, common and (in general) not a bug, since the instructions "don't get executed", and the vulnerability persists even if you validate all input.

Re: Meltdown Proof-of-Concept

#187

Post by Skunkleton »

abritinthebay wrote: post #137
Skunkleton wrote: post #74

Earlier quoted context omitted.

> The only way to make it make sense is add that we also know there is an entire spacefaring group of mercenaries whose entire hobby and/or job is deliberately throwing asteroids in Earths general direction. Maybe there is, but they are hilariously incompetent?

This sounds like a new BlackAdder pitch... "Sir, I have a cunning plan" "Does it involve that legion of rabid space weasels again?" "... maybe."

As long as I can retire to my great big turnip in the country when it is all over I am happy.
Post reply on HN