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

111–120 of 187 posts

Re: Meltdown Proof-of-Concept

#111

Post by londons_explore »

Terr_ wrote: post #100
white-flame wrote: post #76

Earlier quoted context omitted.

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…

> no way to run raw machine code bytes otherwise [...] restrictions of what may be executed, enforce runtime checks, or prevent certain instructions from being used at all [...] everything optimized for your environment better, allow much better compatibility across systems and prevent entire classes of privilege escalation issues. So... basically re-inventing Java? :) "Raw machine code bytes" aren't distributed but…

Arguably x64 assembly code is the same...

A privileged process (the microcode) enforces restrictions and converts it to micro-ops which execute on the real processor.

Re: Meltdown Proof-of-Concept

#112

Post by londons_explore »

gpderetta wrote: post #101
spullara wrote: post #78

Earlier quoted context omitted.

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.

Main memory access take an order of hundred cycles. D1 cache hit access usually take usually 3-4 cycles. Microarchitecture designers will take heroic efforts to even shave a single cycle here. Adding an overhead of even a couple of cycles would be a huge deal. Having said that, AMD CPUs are the existence proof that you can be immune to meltdown with no significant overhead. Spectre is a completely different issue tho…

AMD CPUs have pretty poor single threaded performance.

Perhaps that because they haven't taken the speed short-cuts that Intel took...?

Re: Meltdown Proof-of-Concept

#113

Post by SheinhardtWigCo »

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…

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. government would never put a major company like Intel in a position of risk" is obviously bullshit. TAO's job necessarily involves exposing companies both in the US and overseas to that kind of risk on a daily basis.

Re: Meltdown Proof-of-Concept

#114

Post by londons_explore »

CiPHPerCoder wrote: post #24
ehPReth wrote: post #14

Earlier quoted context omitted.

I wonder what happened to "This bug is subject to a 90 day disclosure deadline. After 90 days elapse or a patch has been made broadly available, the bug report will become visible to the public." Executive meddling? Edit: Probably the 'extreme circumstances' bit mentioned in https://news.ycombinator.com/item?id=16108434

https://bugs.chromium.org/p/project-zero/issues/detail?id=12... > Project Member Comment 4 by hawkes@google.com, Aug 7 > Labels: Deadline-Grace It looks like Ben Hawkes would know the reason why, but I think the speculation that this grace period was done due to the scope and severity of this finding is likely correct.

Perhaps project zero wasn't the first to discover the vulnerability. If they discover it 2nd, I think it is only reasonable for the initial discoverer to set the disclosure process.

Re: Meltdown Proof-of-Concept

#115

Post by noobermin »

trendia wrote: post #110
noobermin wrote: post #99

Earlier quoted context omitted.

I have CONFIG_PAGE_TABLE_ISOLATION on. I roll my own kernel and all that. Trying the kaslr program right now, it's not figuring out the direct map offset and it's probably already been a minute or two. So it works? EDIT: After 40 minutes, it has attempted all addresses and did not find the direct map offset.

It took about an hour for it to find the offset for me. I think that the page isolation slows it down, even if it doesn't completely eliminate it. The second test had something like a 0.05% success rate on my PC, and took over an hour to get a few dozen values read. After trying this with the new kernel, I started up an AWS instance and ran the tests there. The first test (KASLR) succeeded within a few seconds, and t…

Basically, the first test (kaslr.c) did not even work for me, and it scanned all addresses and wrapped around and started again.

You probably know this (saw you're the person I replied to initially), but for others reading this to check that it's on, "dmesg | grep isolation" should be able to tell you whether the page table isolation is on after you enable it in the kernel.

Given the other tests require the offset, I think I'm safe? I'm going to run it again just to be sure.

Re: Meltdown Proof-of-Concept

#116

Post by stefs »

pbhjpbhj wrote: post #81

First I read about this, so I thought "who's shorting Intel now I wonder", turns out it's the CEO [kinda]: >"reports this morning that Intel chief executive Brian Krzanich made $25 million from selling Intel stock in late November, when he knew about the bugs, but before they were made public" ( https://qz.com/1171391/the-intel-intc-meltdown-bug-is-hittin... ) I assume he's supposed to now be prosecuted, that sounds…

as far as conspiracy theories go (i read that some days ago on reddit), he's wont be persecuted because he cooperates with the NSA. refuse to cooperate with them and join Nacchio and Qwest.

Re: Meltdown Proof-of-Concept

#117

Post by chacham15 »

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…

There was a HN article a while ago that discussed making use of an existing cpu isa extension to solve the problem in a performant manner: PCID. More here: http://archive.is/ma8Iw

Re: Meltdown Proof-of-Concept

#118

Post by garblegarble »

che_shirecat wrote: post #34
VikingCoder wrote: post #22

Can the videos be put on YouTube for convenience?

#1 - realtime password input - https://www.youtube.com/watch?v=yTpXqyRYcBM #2 - physical memory leak - https://www.youtube.com/watch?v=kn0FopiF16o the videos aren't very long, someone should compress it to <10mb as an animated gif and do a pull request to put it in the README

>the videos aren't very long, someone should compress it to There's no need to use an awful format like gif, just embed an efficiently compressed video file with the tag

Re: Meltdown Proof-of-Concept

#119

Post by tomatocracy »

tzs wrote: post #105
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…

> 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 executing interpreter/JVM process and what the running JVM/JavaScript code can see). And worse, those are precisely the cases where one probably cares most about separation given that's where untrusted code is typically run.

But hardware assistance could help - in simple terms, I'd imagine that allowing a swap out of more of the internal processor state (to the extent that one process "training" the branch-predictor doesn't impact how the branch predictor acts in another process) would be pretty effective. That might be expensive in terms of performance per-transistor/per-watt however (though probably not absolute performance).

Re: Meltdown Proof-of-Concept

#120

Post by cookiecaper »

krylon wrote: post #51

I have run the first test on several machines, with mixed results, but on my workhorses (ThinkPad x220, Zenbook UX305) the exploit seems to work. I thought the recent kernel-/firmware-/ucode-patches should have prevented that. EDIT: The other demos fail, though, as they should. sigh EDIT: For some reason, demo #2 (breaking kaslr) works on my Ryzen machine, but not on the others. :-?

Spectre should work on most modern computers. There are no kernel patches in stable to prevent Spectre right now. Only Meltdown is mitigated by KPTI. The new Intel microcode and the kernel code to control it will propagate out in the next couple of weeks.
Post reply on HN