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

171–180 of 187 posts

Re: Meltdown Proof-of-Concept

#171

Post by amdavidson »

arkh wrote: post #161
arkadiyt wrote: post #104

Earlier quoted context omitted.

> Makes you wonder if the NSA knew about it all along :) Former head of TAO Rob Joyce said "NSA did not know about the flaw, has not exploited it and certainly the U.S. government would never put a major company like Intel in a position of risk like this to try to hold open a vulnerability." [1] Who knows if that's true or not, though. Certainly the U.S. government has done exactly that many times in the past (like w…

> the U.S. government would never put a major company like Intel in a position of risk like this to try to hold open a vulnerability The US government sure. The NSA? They sure would as this statement shows.

Are you arguing that the NSA does not fall under the umbrella of the "US Government"?

Re: Meltdown Proof-of-Concept

#172

Post by samsonradu »

ajanuary wrote: post #170
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…

Caveat: I am also a high level programmer. My understanding is that the problem is that the data in the cache _isn't_ rolled back. You fetch the secret data. You then fetch a different memory addressed based on the contents of the secret data e.g. fetch((secret_bit * 128) + offset) [1] so if secret_bit is 0 it's fetched the memory at offset into the cache, if secret_bit is 1 it's fetched the memory at offset+128 into…

> You fetch the secret data. You then fetch a different memory addressed based on the contents of the secret data ...

I was under the impression that there is no interface to read data from the CPU caches and that the cache is managed by the CPU itself only.

Re: Meltdown Proof-of-Concept

#173

Post by ajanuary »

samsonradu wrote: post #172
ajanuary wrote: post #170

Earlier quoted context omitted.

Caveat: I am also a high level programmer. My understanding is that the problem is that the data in the cache _isn't_ rolled back. You fetch the secret data. You then fetch a different memory addressed based on the contents of the secret data e.g. fetch((secret_bit * 128) + offset) [1] so if secret_bit is 0 it's fetched the memory at offset into the cache, if secret_bit is 1 it's fetched the memory at offset+128 into…

> You fetch the secret data. You then fetch a different memory addressed based on the contents of the secret data ... I was under the impression that there is no interface to read data from the CPU caches and that the cache is managed by the CPU itself only.

Right, which makes it a bit of a tricky attack to pull off. But if you know what you're doing you can do some operation that requires memory address x and be reasonably sure it will end up in the CPU cache. If you then do an operation on memory address x, and it happens really quickly, and you do an operation on memory address x+128, and it happens a bit slower, you can assume that x was in the cache and x+128 wasn't.

Re: Meltdown Proof-of-Concept

#174

Post by samsonradu »

ajanuary wrote: post #173
samsonradu wrote: post #172

Earlier quoted context omitted.

> You fetch the secret data. You then fetch a different memory addressed based on the contents of the secret data ... I was under the impression that there is no interface to read data from the CPU caches and that the cache is managed by the CPU itself only.

Right, which makes it a bit of a tricky attack to pull off. But if you know what you're doing you can do some operation that requires memory address x and be reasonably sure it will end up in the CPU cache. If you then do an operation on memory address x, and it happens really quickly, and you do an operation on memory address x+128, and it happens a bit slower, you can assume that x was in the cache and x+128 wasn't…

Yes, I got the part where you can time if memory address X is in cache and X+128 isn't. But how does one read the data at memory address X?

Re: Meltdown Proof-of-Concept

#175

Post by ajanuary »

samsonradu wrote: post #174
ajanuary wrote: post #173

Earlier quoted context omitted.

Right, which makes it a bit of a tricky attack to pull off. But if you know what you're doing you can do some operation that requires memory address x and be reasonably sure it will end up in the CPU cache. If you then do an operation on memory address x, and it happens really quickly, and you do an operation on memory address x+128, and it happens a bit slower, you can assume that x was in the cache and x+128 wasn't…

Yes, I got the part where you can time if memory address X is in cache and X+128 isn't. But how does one read the data at memory address X?

You load it into a register. If you're trying to drive it from a high level language, I guess you can do something like an add which will get compiled into instructions to load it into a register first.

Re: Meltdown Proof-of-Concept

#176

Post by tptacek »

mehrdadn wrote: post #159
tptacek wrote: post #146

Earlier quoted context omitted.

What's the "old" term for speculated instructions that aren't retired?

I've never heard of a term for them but I would find "speculated instructions" clear enough in context.

"Speculated instructions" is ambiguous, because it includes instructions that are retired, and we specifically care about the ones that aren't.

Re: Meltdown Proof-of-Concept

#177

Post by Uplink »

Not sure what this means, but while I'm mining Monero on the CPU with xmr-stak the PoC is thwarted.

First, the "Direct physical map offset" comes back wrong in Demo #2. Second, if I use the correct offset, the reliability is around 0.5% in Demo #3 - but not consistently... after a few tries it did come back with >99%

Basically, screw up your caches continuously.

Re: Meltdown Proof-of-Concept

#178

Post by alien_at_work »

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…

Mostly high-level programmer. I may be wrong or be thinking of another recent attack but my understand was this: the attacker allocates 256 seperate pages, ensures they're not in memory and then runs code like this:

    if(false_but_predictive_execution_cant_tell)
    {
      int i = (int)*protected_kernel_memory_byte;
      load_page(i, my_pages);
    }
Then it becomes a matter of checking speed of reading from those pages. Which ever one is too fast to be loaded when read must be the value read from protected memory.

Re: Meltdown Proof-of-Concept

#179

Post by jeshwanth »

aeleos wrote: post #90

I am running a razer blade 2017 with ubuntu 16.04 and so far all of the PoCs have worked. I currently have my kaslr offset and I am now testing the reliability. So far it doesn't seem very good with a 0.00% success rate at 60 reads. It did take a while to find my kaslr offset with multiple passes through the entire randomization space so I need to stress my CPU more in order to improve the success rate of having succ…

I installed the recent kernel release from Ubuntu, but the tests still working fine.

Re: Meltdown Proof-of-Concept

#180

Post by dirtbox »

mehrdadn wrote: post #130
dirtbox wrote: post #122

Earlier quoted context omitted.

It's the type of announcement that makes me wonder if they had the chip makers incorporate it specifically for them to exploit.

> It's the type of announcement that makes me wonder if they had the chip makers incorporate it specifically for them to exploit. ...sorry, what ? It makes you wonder if the NSA had chip makers incorporate speculative execution and caching because... timing attacks?

No.

It's just that it's highly suspicious that anyone is making any type of mention of it at all.

Post reply on HN