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

71–80 of 187 posts

Re: Meltdown Proof-of-Concept

#71

Post by JdeBP »

tptacek wrote: post #66
JdeBP wrote: post #60

Earlier quoted context omitted.

Tarring all of the BSDs with the same brush is wrong, both in general and here specifically. There's also the matter of both Matthew Dillon and Theo de Raadt discussing this topic months or even years before Google Project Zero made its discovery. * https://news.ycombinator.com/item?id=16086047 * https://news.ycombinator.com/item?id=16074531 * https://news.ycombinator.com/item?id=16075744 Moreover, the OpenBSD people…

The bugs Theo was talking about were unrelated to these ones.

I did point to https://news.ycombinator.com/item?id=16074531 . However, it is also wrong to err in the other direction as you have and to say that they were unrelated. Others have already made this point in https://news.ycombinator.com/item?id=16075744 , which I also pointed to.

Re: Meltdown Proof-of-Concept

#72

Post by Skunkleton »

odonnellryan wrote: post #35
hannasanarion wrote: post #11

Earlier quoted context omitted.

If you don't know the difference between the existence of an earthbound asteroid and the existence of people who write computer viruses, I don't know what to tell you.

What's the name for this logical fallacy? You see this shit all the time.

Its like circular logic on steroids. Parent is using the word "speculative" to discredit the vulnerabilities that use speculative execution.

Re: Meltdown Proof-of-Concept

#73

Post by white-flame »

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!

Actually, my preferred solution would be to eliminate the notion of distributing machine code binaries entirely, but that's a bit beyond the scope of these discussions. ;-)

Re: Meltdown Proof-of-Concept

#74

Post by Skunkleton »

abritinthebay wrote: post #30
john_teller02 wrote: post #4

These two bugs (Meltdown and Spectr) are really very speculative things. It is like when human beings became aware of astroid orbits they thought that earth is in danger of being hit by one. Now that is indeed a theoritical possibility but what are the chances? These two bugs have been existent for 20 years and there is no known exploits of them. In the GitHub demos also they mention that the demos will work only if…

I think you're being harshly down-voted without people explaining why. For a start - this is hardly a remote possibility when we already have proof of concepts like the linked repo. Secondly - your analogy makes no sense. 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 dir…

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

Re: Meltdown Proof-of-Concept

#75

Post by martin1975 »

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

Earlier quoted context omitted.

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

Actually, my preferred solution would be to eliminate the notion of distributing machine code binaries entirely, but that's a bit beyond the scope of these discussions. ;-)

so run everything in a VM?

Re: Meltdown Proof-of-Concept

#76

Post by white-flame »

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

Earlier quoted context omitted.

Actually, my preferred solution would be to eliminate the notion of distributing machine code binaries entirely, but that's a bit beyond the scope of these discussions. ;-)

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 instructions from being used at all. Security or optimization updates would affect all running programs automatically. Granted, these current speculative vulnerabilities would be much more difficult to statically detect.

But it would follow the crazy gentoo dream of having everything optimized for your environment better, allow much better compatibility across systems, and prevent entire classes of privilege escalation issues.

Re: Meltdown Proof-of-Concept

#77

Post by jimrandomh »

white-flame wrote: post #68
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…

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…

Flushing cache lines doesn't work, at least not straightforwardly. The attacker can arrange things so that the cache line is pre-populated with something else that it has access to, with a colliding address that will be evicted by the speculative load. Flushing undoes the load, but can't easily undo the eviction.

Re: Meltdown Proof-of-Concept

#78

Post by spullara »

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!

i'm not so sure. memory accesses are so slow (hundreds of cycles) it probably wouldn't be that much slower to issue them a few instructions later. when it was introduced memory access and cycles were much closer together, only a few cycles and it saved a huge amount of time.

Re: Meltdown Proof-of-Concept

#79

Post by krylon »

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 the 33C3, where they showed that they had managed to use that technique to establish a covert channel between VMs running on the same physical host. They even managed to run ssh over than channel. https://media.ccc.de/v/33c3-8044-what_could_possibly_go_wron...

In light of that, I would be surprised if the NSA had not known about this.

Re: Meltdown Proof-of-Concept

#80

Post by thisoneforwork »

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…

Not a CPU designer, but my guess is that they will move the cache management logic from the MMU to the µOP scheduler, which will commit to cache on retirement of the speculatively executed instruction. They would then need to introduce some sort of L0 cache, accessible only at the microarchitectural level, bound to a speculative flow, and flushed at retirement.
Post reply on HN