Live data from Hacker News

Meltdown Proof-of-Concept

github.com

101–110 of 187 posts

Re: Meltdown Proof-of-Concept

#101

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!

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

Re: Meltdown Proof-of-Concept

#103
post #83

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…

I've been thinking along the same lines for the last few years. If you did this, you could have a multi-user operating system in a single address space and avoid the cost of interrupts for system calls (which would just be like any other function call).

Sounds similar to some ideas explored in the experimental OS "Singularity" - https://en.wikipedia.org/wiki/Singularity_(operating_system)

Re: Meltdown Proof-of-Concept

#104

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 with heartbleed).

[1]: https://www.washingtonpost.com/business/technology/huge-secu...

Re: Meltdown Proof-of-Concept

#105

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…

> 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 to get the actual memory address.

The permission information for a page is stored in the same place as the physical address translation information for that page. The processor fetches it at the same time it fethes the physical base address of the page.

They should also have the current permission level of the program readily available. That should be enough to let them do something about Meltdown without any performance impact. They could do something as simple as if the page is a supervisor page and the CPU is not in supervisor mode don't actually read the memory. Just substitute fixed data.

Note that AMD is reportedly not affected by Meltdown. From what I've read that is because they in fact do the protection check before trying to access the memory, even during speculation, and they don't suffer any performance loss from that.

Note that since Meltdown is only an issue when the kernel memory read is on the path that does NOT become the real path (because if it becomes the real path, then the program is going to get a fault anyway for an illegal memory access), the replacing of the memory accesses with fixed data cannot harm any legitimate program.

Spectre is going to be the hard one for the CPU people to fix, I think. I think they may have to offer hardware memory protection features that can be used in user mode code to protect parts of that code from other parts of that code, so that things that want to run untrusted code in a sandbox in their own processes can do so in a separate address space that is protected similar to the way kernel space is protected from user space.

It may be more complicated than that, though, because Spectre also does some freaky things that take advantage of branch prediction information not being isolated between processors. I haven't read enough to understand the implications of that. I don't know if that can be defeated just be better memory protection enforcement.

Re: Meltdown Proof-of-Concept

#106
post #9

Earlier quoted context omitted.

This is the closest thing to a javascript implementation I have seen: http://xlab.tencent.com/special/spectre/js/check.js from: http://xlab.tencent.com/special/spectre/spectre_check.html

Nice. Reviewing the code, it is as the PDF said where they are just constantly incrementing a val in the shared buffer to get a fairly precise timer. But it seems to be using the timing to determine across 256 indices (99 tries to check) to check cache hits. So just removing this timer is not enough, it just increases the surface area of bytes you have to read and sift through to see if you have other mem? Anyone hav…

Isn't the high-precision timer required to detect a cache hit or miss-- as in, the side channel being exploited here is in the timing of a cache hit or miss; there's no data leaked directly into Javascript?

That's not to say that removing SharedArrayBuffer (and high-precision performance timers, which were removed a couple years back to mitigate some other timing-related vulnerabilities) is enough to completely eliminate Spectre; there might be other methods that can time accurately enough to reveal information.

(I might be completely wrong here, but this is my current understanding of the situation, at least.)

Re: Meltdown Proof-of-Concept

#107

Earlier quoted context omitted.

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?

Nah, they're really far away, and there's an accumulated round-off error in their distance conversion between bloits (used by the client) and metrons (used by the subcontractor), so they're shooting at a target a quarter of a light-year away, and won't realize it for another 500 years.

Re: Meltdown Proof-of-Concept

#110
post #27

Linux 4.15 and the appropriate modules protect against the attack. To test, set CONFIG_PAGE_TABLE_ISOLATION=y. That is: sudo apt-get build-dep linux sudo apt-get install gcc-6-plugin-dev libelf-dev libncurses5-dev cd /usr/src wget https://git.kernel.org/torvalds/t/linux-4.15-rc7.tar.gz tar -xvf linux-4.15-rc7.tar.gz cd linux-4.15-rc7 cp /boot/config-`uname -r` .config make CONFIG_PAGE_TABLE_ISOLATION=y deb-pkg

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 the second test had a 100% success rate (read 1575 values in a few seconds).

Post reply on HN