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

121–130 of 187 posts

Re: Meltdown Proof-of-Concept

#121

Post by warkdarrior »

krylon wrote: post #79
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…

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

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

Re: Meltdown Proof-of-Concept

#122

Post by dirtbox »

SheinhardtWigCo wrote: post #113
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…

It's odd to publicly state that they didn't know about it, because now if they don't do the same after the next big flaw comes out, the implication will be that they indeed knew and were quietly exploiting it. I thought that was why they generally don't comment on these things. The less-charitable assumption is that they'll make this claim every time regardless of whether it's true. The claim that "the U.S. governmen…

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

Re: Meltdown Proof-of-Concept

#123

Post by dannyw »

martin1975 wrote: post #69
white-flame wrote: post #68

Earlier quoted context omitted.

To my understanding, the memory subsystem is fetching a byte in parallel with access permission checks. If the byte is discarded due to mis-speculation, then the result of the permission check is ignored, but the cache is still in an updated state. I believe one solution would be to put permission checks before the memory access, which would add serialized latency to all memory access. Another would be to have the sp…

the first approach sounds kind of expensive to be done at the cpu level. I like your second one better. thank you!

AMD already takes the first approach to prevent Meltdown.

Re: Meltdown Proof-of-Concept

#124

Post by la6470 »

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…

For this demo, you either need the direct physical map offset (e.g. from demo #2) or you have to disable KASLR by specifying nokaslr in your kernel command line." - who disabled kaslr knowingly? I have never seen anyone dothis in 23 years of sysadmin experience.

Re: Meltdown Proof-of-Concept

#125

Post by boltzmann_brain »

K0nserv wrote: post #31
revelation wrote: post #21

Earlier quoted context omitted.

This is from Google Zero on Meltdown: We believe that this precondition is that the targeted kernel memory is present in the L1D cache. Not only is L1D tiny, but stuff like prefetch doesn't touch it. So how exactly do you force any memory into L1D cache unless, like in all the examples we have seen, the victim program is pretty much accessing it in a busy loop?

I'll try to explain the small snippet from the paper. The exploit uses a Flush+Reload attack to use the cache as a side channel to leak memory read in speculative execution. They use a 256 * 4096 byte memory region to leak a 1 byte value from any location mapped to the process. 4096 is the page size and is used to make sure the caching doesn't create false positives. Data across two pages are not cached apparently. H…

That's exactly it. I made a test using an exception (instruction raises an exception but others are already in pipeline), on Windows: https://github.com/bsekura/meltdown

Re: Meltdown Proof-of-Concept

#126

Post by mykull »

white-flame wrote: post #76
martin1975 wrote: post #75

Earlier quoted context omitted.

so run everything in a VM?

No, creating a block of machine code bytes to execute would be a privileged operation. All code would run through a privileged CPU-specific compiler first, and there'd be no way to run raw machine code bytes otherwise. If there are bugs that can be exposed through various machine code patterns, the compiler can centralize the restrictions of what may be executed, enforce runtime checks, or prevent certain instruction…

We'd need a better binary representation of uncompiled code, then. Moving around lots of code as ascii is kind of suboptimal... I wouldn't want that. By all means, show it as text to the user, but don't store it that way.

Re: Meltdown Proof-of-Concept

#127

Post by thebeardedone »

Moritz Lipp's twitter is actually interesting to follow. He is reconstructing images which do not fit into cache. Quite amazing.

https://twitter.com/mlqxyz/status/950378419073712129

(I personally do not have a twitter account but was looking for the paper and stumbled upon it, glad I did!)

Re: Meltdown Proof-of-Concept

#128

Post by tptacek »

krylon wrote: post #79
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…

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

* Spectre v1 undermines the entire concept of a bounds check; pre-Spectre, virtually every program that runs on a computer is riddled with buffer overreads. It's about as big a revelation as Lopatic's HPUX stack overflow was in 1995. There might not be a clean fix! Load fences after ever bounds check?

* Spectre v2 goes even further than that, and allows attackers to literally pick the locations target programs will execute from. Try to get your head around that: we pay tens of thousands of dollars for vulnerabilities that allow us to return to arbitrary program locations, and Spectre's branch target injection technique lets us use the hardware to, in some sense, do that to any program. And look at the fix to that: retpolines? Compilers can't directly emit indirect jumps anymore?

It's good that we're all recognizing how big a problem cache timing is. It was for sure not taken as seriously as it should have been outside of a subset of cryptographers. But Meltdown and Spectre are not simply cache timing vulnerabilities; they're a re-imagining of what you can do to a modern ISA by targeting the microarchitecture.

Re: Meltdown Proof-of-Concept

#129

Post by cm2187 »

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…

By the way, I understand the fixes are being rolled out now. Do we have a more precise idea of the performance hit on windows and linux?

Re: Meltdown Proof-of-Concept

#130

Post by mehrdadn »

dirtbox wrote: post #122
SheinhardtWigCo wrote: post #113

Earlier quoted context omitted.

It's odd to publicly state that they didn't know about it, because now if they don't do the same after the next big flaw comes out, the implication will be that they indeed knew and were quietly exploiting it. I thought that was why they generally don't comment on these things. The less-charitable assumption is that they'll make this claim every time regardless of whether it's true. The claim that "the U.S. governmen…

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?

Post reply on HN