Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reading privileged memory with a side-channel

googleprojectzero.blogspot.com

Post reply on HN
Print view View original

531–540 of 639 posts

Re: Reading privileged memory with a side-channel

#531

Post by 314 »

bloorp wrote: post #217
mtanski wrote: post #185

Earlier quoted context omitted.

Speculative execution as a concept should not be flawed. My take is that the results of illegal speculation should never be leaked in a visable way.

As I read through the meltdown paper, it looks really difficult to have the security we want and the performance we want at the same time. It's pretty crazy, but here's my limited understanding: There's a huge shared buffer between two threads. 256 * 4K. One thread reads a byte of kernel memory, literally any byte it wants, and it then reads one of those 4K pages from that buffer in order to cache that one memory pag…

Not allow user processes to recover from a SEGV. The attack depends on a signal hander that traps the signal and resumes execution. If this is disabled then the attack will not work. This would affect two types of systems:

1. Badly written code where bugs are being masked by the handler. 2. Any kind of virtualization?

So, for cloud providers it looks like a 30% performance hit, but for the rest of us I would rather have a patch that stops applications handling the SEGV trap.

Re: Reading privileged memory with a side-channel

#532

Post by blattimwind »

Symmetry wrote: post #528
Symmetry wrote: post #266

Earlier quoted context omitted.

If you're using an in order processor, a Nexus 9 tablet say, then you should be safe.

I wasn't thinking straight last night. Basically all in order application processors use speculative execution.

Even a low-power core like a Cortex-M7 can do some speculative execution through its branch predictor.

Though of course a M7 isn't running VMs, and probably isn't running any kind of attacker-controlled code (scripting included - its there, but rare), so many of the vectors aren't present.

Re: Reading privileged memory with a side-channel

#535

Post by mike_hearn »

londons_explore wrote: post #333
MBCook wrote: post #8

Earlier quoted context omitted.

See the Twitter thread here: https://twitter.com/nicoleperlroth/status/948678006859591682 (Edit: there are 9 posts total, go to her user page to see them all) Seems there are two issues. One, called Meltdown, only effects Intel and is REALLY bad, but the kernel page table changes everyone is making fixes it. The other, dubbed Spectre, is apparently common to the way all processors handle speculative execution and is…

I can't really see how it would be fixable even with new hardware. Speculative execution is fundamental to getting decent performance out of a CPU. Without it you should probably divide your performance expectations by 5 at least. Rolling back all state rather than just user visible state in the CPU is neigh on impossible. When you evict something from the cache, you delete it. Undeleting is hard. There are also a lo…

It effectively means wiping the caches, TLBs, BTBs and any other caches and optimisations on any form of context switch, as far as I can see? Which yes will likely require new silicon.

Re: Reading privileged memory with a side-channel

#536

Post by [deleted] »

hyperion2010 wrote: post #430

An analogy that was useful for explaining part of this to my (non-technical) father. Maybe others will find it helpful as well. Imagine that you want to know whether someone has checked out a particular library book. The library refuses to give you access to their records and does not keep a slip inside the front cover. You can only see the record of which books you have checked out. What you do is follow the person…

[deleted]

Re: Reading privileged memory with a side-channel

#537

Post by 314 »

hyperion2010 wrote: post #430

An analogy that was useful for explaining part of this to my (non-technical) father. Maybe others will find it helpful as well. Imagine that you want to know whether someone has checked out a particular library book. The library refuses to give you access to their records and does not keep a slip inside the front cover. You can only see the record of which books you have checked out. What you do is follow the person…

Your analogy is more apt for side-channel attacks in general. Here is a more specific version for Meltdown:

A library has two rooms, one for general books and one for restricted books. The restricted books are not allowed out of the library, and no notes or recordings are allowed to be taken out of the restricted room.

An attacker wants to sneak information out of the restricted room. To do this the pick up a pile of non-restricted books and go into the restricted room. Depending on what they read in there they rearrange the pile of non-restricted books into a particular order. A guard comes along and sees them, they are thrown out of the restricted room and their pile of non-restricted books is put on the issue desk ready to be put back into circulation.

Their conspirator looks at the order of the books on the issue desk and decodes a piece of information about the book in the restricted room. They repeat this process about 500000 times a second until they have transcribed the secret book.

Re: Reading privileged memory with a side-channel

#538

Post by lrem »

Certhas wrote: post #517
user5994461 wrote: post #441

Earlier quoted context omitted.

They say they can reliably read memory around 120kB/s with one vulnerability and 1kB/s with the other. It just works, all the time. Some of the PoC takes a few minutes to initialize. I'd say difficulty level is easy.

However, only one of the PoCs runs on AMD, and that doesn't cross process boundaries. So how easy is it to turn that PoC into something I should worry about? Seems like browsers are the most affected by this scenario, but that also means harden the browser (separate process per page) and it might be difficult to exploit.

As a general rule of thumb, if everyone already has a PoC, you should assume someone has been doing targeted practical attacks for a while.

Re: Reading privileged memory with a side-channel

#539

Post by bonzini »

contrarian_ wrote: post #525
bonzini wrote: post #465

Earlier quoted context omitted.

New CPU microcode is enough, though at a performance price. On pre-Zen AMD there is also a chicken bit to disable indirect branch prediction. (It feels good to be finally able to speak about this freely!!!) I don't know for which processors Intel and AMD plan to release microcode updates.

> New CPU microcode is enough What would that entail? Disabling speculation completely? Disabling memory accesses during speculation?

Disabling indirect branch prediction (and thus speculation after indirect branches) while in kernel mode, or flushing the indirect branch predictor on kernel mode entry. Both need OS support in addition to the microcode, but the change is less invasive than PTI.

Re: Reading privileged memory with a side-channel

#540

Post by Sean1708 »

comex wrote: post #188
tankenmate wrote: post #177

Earlier quoted context omitted.

But that means the root user or someone with root effective privs or CAP_* to load programs into a kernel interpreter or kernel JIT. If you've given someone permission to do this from a user process you've probably opened up to more mundane issues. I suspect this is why AMD says the issue is near zero, if you've given away the keys to the kernel you're already in trouble. AMD's ASID blocks the issues for VM guests (a…

For variant 1, a kernel JIT is definitely helpful, which is why the Project Zero PoC used it, but it's not required. For variant 2, Project Zero used the eBPF interpreter as a gadget , a fake branch destination, without having to actually create an eBPF program or use the normal userland-facing eBPF APIs at all. And they only chose it as the least "annoying" option (see quote below). edit: I'm not sure how ASID suppo…

> For variant 1, a kernel JIT is definitely helpful, which is why the Project Zero PoC used it, but it's not required.

If I'm understanding the post correctly it says that JIT's not required for Intel CPUs, but is required for AMD.

Post reply on HN