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

161–170 of 187 posts

Re: Meltdown Proof-of-Concept

#161

Post by arkh »

arkadiyt wrote: post #104
martin1975 wrote: post #64

I'm curious if someone can point me to any source that discusses how the next generation of CPUs that Intel, AMD, ARM might be working on is actually going to address this & the Spectre issue architecturally.. It's great that we have a potentially performance killing fix but the real "fix" or rather, solution, is to alter the architecture. Since I'm not an EE/CE dude... is anyone aware of where such discussions on th…

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

Re: Meltdown Proof-of-Concept

#162

Post by mpweiher »

arkadiyt wrote: post #104
martin1975 wrote: post #64

I'm curious if someone can point me to any source that discusses how the next generation of CPUs that Intel, AMD, ARM might be working on is actually going to address this & the Spectre issue architecturally.. It's great that we have a potentially performance killing fix but the real "fix" or rather, solution, is to alter the architecture. Since I'm not an EE/CE dude... is anyone aware of where such discussions on th…

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

Note that it talks about "the flaw", whereas Intel claims it isn't a "flaw". So could be another instance of overly specific denial. "We didn't exploit this flaw, because it isn't a flaw. We exploited the processor operating as designed".

Re: Meltdown Proof-of-Concept

#163

Post by nialv7 »

foota wrote: post #98
thisoneforwork wrote: post #86

Earlier quoted context omitted.

Firstly, thanks for the question. As mentioned, not a CPU designer or trying to teach Intel what to do. More like relying on the hive mind to see if I have the right idea. A second instruction in the pipeline would read from the above mentioned L0 cache (let us call it load buffer), much like it would for tentative memory stores from the store buffer. Also, two memory fetches in parallel are not twice as long as a me…

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.

Re: Meltdown Proof-of-Concept

#164

Post by [deleted] »

martin1975 wrote: post #64

I'm curious if someone can point me to any source that discusses how the next generation of CPUs that Intel, AMD, ARM might be working on is actually going to address this & the Spectre issue architecturally.. It's great that we have a potentially performance killing fix but the real "fix" or rather, solution, is to alter the architecture. Since I'm not an EE/CE dude... is anyone aware of where such discussions on th…

[deleted]

Re: Meltdown Proof-of-Concept

#165

Post by palotasb »

gok wrote: post #85
srcmap wrote: post #53

From the papers, these two bugs are also exploitable from ARM. Does it mean a hacked IOS/Android app can also (in theory) sniff the password enter in system dialog as demo in the video? Realtime password input - https://www.youtube.com/watch?v=yTpXqyRYcBM

Important to differentiate between ARM the company, the instruction set architecture(s) and the specific implementation of those ISAs. The licensable nature of ARM means there very likely are (possibly undiscovered) implementations of the ARM ISAs floating around which are susceptible to Meltdown.

I was under the impression that they generally license the IP cores (or at least some IP blocks) to implement the ISA and downstream vendors don't implement those differently.

Re: Meltdown Proof-of-Concept

#166

Post by cesarb »

ckastner wrote: post #155
warkdarrior wrote: post #121

Earlier quoted context omitted.

Cache timing attacks have been known for a while, for example across VMs in 2009: https://cseweb.ucsd.edu/~hovav/dist/cloudsec.pdf

This paper from 2005 describes a cache timing attack that enabled an unprivileged process to another process' AES key: https://www.cs.tau.ac.il/~tromer/papers/cache.pdf IIRC, the only way to address the issue was the addition of the AES-NI instruction set, which came a few years later.

> IIRC, the only way to address the issue was the addition of the AES-NI instruction set, which came a few years later.

Another option would be to use a bitsliced implementation of AES, at some cost in speed. I could also imagine an implementation which read the whole table every time, using constant-time operations to select the desired element(s), but I don't know how slow that would be.

Re: Meltdown Proof-of-Concept

#168

Post by woliveirajr »

martin1975 wrote: post #64

I'm curious if someone can point me to any source that discusses how the next generation of CPUs that Intel, AMD, ARM might be working on is actually going to address this & the Spectre issue architecturally.. It's great that we have a potentially performance killing fix but the real "fix" or rather, solution, is to alter the architecture. Since I'm not an EE/CE dude... is anyone aware of where such discussions on th…

I'm curious on how Transmeta chips [0] would have suffered/be unaffected by such exploits. Being a CPU that runs cpu microcodes, probably the patch would be easier, it necessary at all.

[0] https://en.wikipedia.org/wiki/Transmeta

Re: Meltdown Proof-of-Concept

#169

Post by samsonradu »

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 but don't get how you actually read it.

EDIT

So perhaps someone can ELI5 me "4.2 Building a Covert Channel" [1] from the Meltdown paper which is what I didn't understand.

[1] https://meltdownattack.com/meltdown.pdf

Re: Meltdown Proof-of-Concept

#170

Post by ajanuary »

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 the cache.

After the speculative work is rolled back, the data that it fetched into the cache still remains. You then time how long it takes to fetch offset and offset+128. If offset comes back quickly, secret_bit was 0. If offset+128 comes back quickly, secret_bit was 1.

_That_ is where the timing attack part comes in: "timing attack" refers to using measurements of how long something took to glean information, not that you need to do it quickly.

[1] In reality you do it on the byte level and use &, but I wanted to keep it to guessing a single bit to make it simpler.

Post reply on HN