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

361–370 of 639 posts

Re: Reading privileged memory with a side-channel

#361

Post by FranOntanaya »

diyseguy wrote: post #355
ErikAugust wrote: post #209

Earlier quoted context omitted.

I've thrown the C code in the Spectre paper up if anyone wants to feel the magic: https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9...

I thought it was supposed to be exploitable by javascript? If you can get to the machine and run c code, well, that doesn't seem like an exploit?

My understanding is it's anything that can make a running process mis-train the CPU core and read the values back. Consider, for example, shared hosts without separate process pools, running code from different users with the same interpreter processes.

Re: Reading privileged memory with a side-channel

#362

Post by ENOTTY »

dpwm wrote: post #341
ErikAugust wrote: post #209

Earlier quoted context omitted.

I've thrown the C code in the Spectre paper up if anyone wants to feel the magic: https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9...

Just tested this on systems of varying age. Works on processors going back as far as 2007 (the oldest I have access to now is an Athlon 64 X2 6000+), but the example code relies on an instruction that the Atom D510 does not suport. Because Spectre seems to be an intrinsic problem with out-of-order execution, which is almost as old as the FDIV bug in intel processors, I would be very surprised if the Atom D510 did not…

The D510 might not have speculative execution. https://en.wikipedia.org/wiki/Bonnell_(microarchitecture)

Re: Reading privileged memory with a side-channel

#363

Post by language »

Pyxl101 wrote: post #336
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…

Do you need root or comparable privileges to take advantage of BPF? I did not think that was the case. My understanding was that BPF code executes within the kernel. BPF is employed by the `bpf()` syscall for socket packet filtering, as well as by `seccomp` itself for its syscall filtering. Is this threat vector not available to untrusted processes?

iirc I think that the BPF JIT is disabled by default? Your kernel might be compiled with `CONFIG_BPF_JIT`, but I think the sysctl knob (`bpf_jit_enable`) is set to 0 by default. Also there's a sysctl for unprivileged BPF called `unprivileged_bpf_disabled`. On my system it seems to default to 0.

https://elixir.free-electrons.com/linux/v4.15-rc6/source/ker...

Re: Reading privileged memory with a side-channel

#364

Post by mtanski »

mtanski wrote: post #318
jerf wrote: post #262

Earlier quoted context omitted.

I can imagine some ways to armor the branch predictor, similar in principle to how languages like Perl have to include a random seed in their hash code (in some circumstances) to avoid being able to pre-compute values that will all hash to the same thing [1]. There should be some ways to relatively cheaply periodically inject such a randomization into the prediction system enough to prevent that aspect of the attack.…

I'm thinking you might be right. It's going to be really hard to give up real world gains from branch prediction. Branch prediction can make a lot of real world (read "not the finest code in the world") run at reasonable speeds. Another common pattern to give up would be eliding (branch predicting away) nil reference checks. > short of entirely preventing speculating code from being able to load things into the cache…

This rant/thread is a good reading as well: https://lkml.org/lkml/2018/1/3/797

It's possible to key the cache in the kernel on CPL so at least there should be no user / kernel space scooping of cache lines.

It's possible we can never fully prevent all attacks in same address space. So certain types of applications (JIT and sandboxes) might forever be a cat and mouse game since we're unlikely to give up on branch prediction.

Re: Reading privileged memory with a side-channel

#365

Post by erichurkman »

londons_explore wrote: post #323
kibwen wrote: post #277

Earlier quoted context omitted.

> I think users can turn it off in firefox, how about Chrome? This month's stable Chrome release will be outright disabling SharedArrayBuffer until additional mitigations are enacted.

Which sucks for people who've built sites which rely on it. It isn't exactly polyfillable.

That shouldn't be that many sites. It only hit Chrome stable in July 2017; Firefox in August 2017; and Edge November 2017.

Re: Reading privileged memory with a side-channel

#366

Post by kuschku »

hinkley wrote: post #307
Filligree wrote: post #224

Earlier quoted context omitted.

There's no mitigation. We'll need new CPUs. Meanwhile, don't ever run untrusted code in the same process as any kind of secret. Better yet, don't ever run untrusted code.

I wonder what fraction of data inside a kernel is really ‘private’. Obviously we want 100% of the data in the kernel not to be writeable, but if only a small amount shouldn’t be accessible at all then maybe the long term solution is to handle that data in a special way. Something that makes using it slower but doesn’t make every other syscall suffer as much as a consequence. Or maybe the solution is to prioritize mov…

Well the good news is that now microkernels can take over. With KPTI (also known as FUCKWIT), a syscall is now as expensive as a context switch to another userland process.

Of course, that means now monolithic kernels run just as slow as microkernels.

Re: Reading privileged memory with a side-channel

#367

Post by rasz »

webaholic wrote: post #235
static_noise wrote: post #121

Earlier quoted context omitted.

Only if your speculative reads do cause irreversible side-effects on those caches. You could implement them in a way that doesn't modify the caches... but that would be complicated and probably use more power and have lower performance.

One of the main reasons for speculative execution is to fetch data into the caches ahead of them being needed. If you don't modify the cache, then you throw that away. May be one way would be to use a smaller, separate cache for speculative execution and then copy that value to the regular cache once speculation is confirmed? This would add a one cycle latency for cache-to-cache transfer but there might be better way…

no need for cache-to-cache transfer, just like with invisible registers we could have cache line renaming

Re: Reading privileged memory with a side-channel

#368

Post by zAy0LfpBZLC8mAC »

partiallypro wrote: post #16

So, is AMD effected or not? This seems fairly important. The Google blog post sort of goes against itself in this regard. AMD itself has said: "The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time." So either AMD is lying or Goog…

As almost everyone seems to be getting this wrong: It's "affected", not "effected". "effected" means roughly "caused", while "affected" means roughly "influenced".

Re: Reading privileged memory with a side-channel

#369

Post by dzhiurgis »

wslh wrote: post #64

Has Google the best security team in the world? It seems like Google security is in a complete different league. I cannot imagine how this impacts companies handling fiat money or cryptocurrencies in the cloud like Coinbase in AWS.

I wonder how much of it relates to their mastery in data science.

I keep wondering if they got some “””AI””” fuzzer that helps them a ton? Plus tons of compute power to spend (remember SHA-256 clash they found “just because”?)

Re: Reading privileged memory with a side-channel

#370

Post by ytpete »

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…

Couldn't you do something like have a separate chunk of "speculative cache" which you only commit to the main cache once the speculatively-executed instructions are retired? Sounds complex, sure - but it seems like that would give you the performance benefits of speculative execution while still being able to roll back (or prevent in the first place) any cache-state side effects when branches were mispredicted. Could also imagine processors start segregating cache by privilege level.

I guess part of the question you're raising is: are there so many different caches, translation buffers, etc. in a modern CPU that keeping 'uncommitted buffers' for the state of all of them would be just as complex as throwing a whole other core in there?

Post reply on HN