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

GoFetch: New side-channel attack using data memory-dependent prefetchers

gofetch.fail

Post reply on HN
Print view View original

31–40 of 100 posts

Re: GoFetch: New side-channel attack using data memory-dependent prefetchers

#31

Post by tadfisher »

bee_rider wrote: post #23
FiloSottile wrote: post #17

Earlier quoted context omitted.

Speaking as a cryptography implementer, yes, these drive us up the wall. However, crypto coprocessors would be a tremendously disruptive solution: we'd need to build mountains of scaffolding to allow switching to and off these cores, and to share memory with them, etc. Even more critically, you can't just move the RSA multiplication to those cores and call it a day. The key is probably parsed from somewhere, right? D…

I don’t think the security community is also going to become experts in chip design, these are two full skill sets that are already very difficult to obtain. We must stop running untrustworthy code on modern full-performance chips. The feedback loop that powers everything is: faster chips allow better engineering and science, creating faster chips. We’re not inserting the security community into that loop and slowing…

> The feedback loop that powers everything is: faster chips allow better engineering and science, creating faster chips. We’re not inserting the security community into that loop and slowing things down just so people can download random programs onto their computers and run them at random. That’s just a stupid thing to do, there’s no way to make it safe, and there never will be.

Note that in the vast majority of cases, crypto-related code isn't what we spend compute cycles on. If there was a straightforward, cross-architecture mechanism to say, "run this code on a single physical core with no branch prediction, no shared caches, and using in-order execution" then the real-world performance impact would be minimal, but the security benefits would be huge.

Re: GoFetch: New side-channel attack using data memory-dependent prefetchers

#32

Post by _factor »

theobservor wrote: post #11

The end result of these side channel attacks would be to have CPUs that perform no optimizations at all and all opcodes would run in the same number of cycles in all situations. But that will never happen. No one wants a slow CPU. As long as these effects cannot be exploited remotely, it's not a concern. Of course multi-tenant cloud-based virtualization would be a no go.

This is why high core counts and isolation matter. Isolate the code to a specific core. Assuming everything is working as intended, an exploit won’t compromise other tenants.

Re: GoFetch: New side-channel attack using data memory-dependent prefetchers

#33

Post by arp242 »

FiloSottile wrote: post #26
bee_rider wrote: post #23

Earlier quoted context omitted.

I don’t think the security community is also going to become experts in chip design, these are two full skill sets that are already very difficult to obtain. We must stop running untrustworthy code on modern full-performance chips. The feedback loop that powers everything is: faster chips allow better engineering and science, creating faster chips. We’re not inserting the security community into that loop and slowing…

> download random programs onto their computers and run them at random To be clear that includes what we're all doing by downloading and running Javascript to read HN. Maybe I can say "don't run adversarial code on my same CPU" and only care about over-the-network CPU side-channels (of which there are still some), because I write Go crypto, but it doesn't sound like something my colleagues writing browser code can do…

Is this exploitable through JavaScript?

In general from what I've seen, most of these JS-based CPU exploits didn't strike me as all that practical in real world conditions. I mean, it is a problem, but not really all that worrying.

Re: GoFetch: New side-channel attack using data memory-dependent prefetchers

#34

Post by graemep »

bee_rider wrote: post #28
theobservor wrote: post #11

The end result of these side channel attacks would be to have CPUs that perform no optimizations at all and all opcodes would run in the same number of cycles in all situations. But that will never happen. No one wants a slow CPU. As long as these effects cannot be exploited remotely, it's not a concern. Of course multi-tenant cloud-based virtualization would be a no go.

We need to drop all the untrusted code on some horrible in-order, no speculative execution, no prefetching, 5 stage pipeline from architectures 101 class core.

It might be preferable.

We have ridiculously fast hardware. In many use cases (client machines in particular) we do not usually really need that. I would gladly drop features for security.

Re: GoFetch: New side-channel attack using data memory-dependent prefetchers

#36

Post by bee_rider »

titzer wrote: post #29
bee_rider wrote: post #23

Earlier quoted context omitted.

I don’t think the security community is also going to become experts in chip design, these are two full skill sets that are already very difficult to obtain. We must stop running untrustworthy code on modern full-performance chips. The feedback loop that powers everything is: faster chips allow better engineering and science, creating faster chips. We’re not inserting the security community into that loop and slowing…

I almost gave you up an upvote until your third paragraph, but I have to now give a hard disagree. We're running more untrusted code than ever, and we absolutely should trust it less than ever and have hardware and software designed with security in mind. Security should be priority #1 from here on out. We are absolutely awash in performance and memory capacity but keep getting surprised by bad security outcomes beca…

> I fundamentally don't understand the mindset of people who want to take that kind of risk for a 10% boost in their games' FPS[1]

Me either. But, lots of engineers are out there just writing single threaded matlab and python codes with lots of data-dependencies and just hoping the system manages to do a good job (for those operations that can’t be offloaded to BLAS). So I'm glad gamer dollars subsidize the development of fast single threaded chips that handle branchy codes well.

> In reality, the vast majority of the 1000x increase in performance and memory capacity over the past four decades has come from shrinking transistors and increasing clockspeeds and memory density

I disagree, modern designs include deep pipelines, lots of speculation, and complex caches because that’s the only way to spend that higher transistor budget for higher clocks and compensate for the fact that memory latencies haven’t kept up.

> Part of that is paying back the debt that decades of cutting corners has yielded us.

It will be tough, but yeah, server and mainframe users need to roll back the decision to repurpose consumer focus chips like the x86 and arm families. RISC-V is looking good though and seems open enough that maybe they can pick-and-choose which features they take.

> I almost gave you up an upvote until your third paragraph, but I have to now give a hard disagree.

I’m not too worried about votes on this post; this site has lots of web devs and cloud users, pointing out that the ecosystem they rely on is impossible to secure is destined to get lots of downvotes-to-disagree.

Re: GoFetch: New side-channel attack using data memory-dependent prefetchers

#37

Post by bee_rider »

graemep wrote: post #34
bee_rider wrote: post #28

Earlier quoted context omitted.

We need to drop all the untrusted code on some horrible in-order, no speculative execution, no prefetching, 5 stage pipeline from architectures 101 class core.

It might be preferable. We have ridiculously fast hardware. In many use cases (client machines in particular) we do not usually really need that. I would gladly drop features for security.

It will also be good because users will become more annoyed when people try to sneak full programs into their websites, hopefully resulting in a generally less bloated internet.

Re: GoFetch: New side-channel attack using data memory-dependent prefetchers

#38

Post by csande17 »

FiloSottile wrote: post #26
bee_rider wrote: post #23

Earlier quoted context omitted.

I don’t think the security community is also going to become experts in chip design, these are two full skill sets that are already very difficult to obtain. We must stop running untrustworthy code on modern full-performance chips. The feedback loop that powers everything is: faster chips allow better engineering and science, creating faster chips. We’re not inserting the security community into that loop and slowing…

> download random programs onto their computers and run them at random To be clear that includes what we're all doing by downloading and running Javascript to read HN. Maybe I can say "don't run adversarial code on my same CPU" and only care about over-the-network CPU side-channels (of which there are still some), because I write Go crypto, but it doesn't sound like something my colleagues writing browser code can do…

Speak for yourself; I've got JavaScript disabled on news.ycombinator.com and it works just fine.

Re: GoFetch: New side-channel attack using data memory-dependent prefetchers

#39

Post by bee_rider »

tadfisher wrote: post #31
bee_rider wrote: post #23

Earlier quoted context omitted.

I don’t think the security community is also going to become experts in chip design, these are two full skill sets that are already very difficult to obtain. We must stop running untrustworthy code on modern full-performance chips. The feedback loop that powers everything is: faster chips allow better engineering and science, creating faster chips. We’re not inserting the security community into that loop and slowing…

> The feedback loop that powers everything is: faster chips allow better engineering and science, creating faster chips. We’re not inserting the security community into that loop and slowing things down just so people can download random programs onto their computers and run them at random. That’s just a stupid thing to do, there’s no way to make it safe, and there never will be. Note that in the vast majority of cas…

I’m in favor of adding some horrible in-order, no speculation, no prefetching, 5 stage pipeline architectures 101 core which can be completely verified and bulletproof to chips.

But the presence of this bulletproof core would not solve the problem of running bad code on modern hardware, unless all untrusted code is run on it.

Re: GoFetch: New side-channel attack using data memory-dependent prefetchers

#40

Post by john_alan »

On reading it seems a lib like libsodium can simply set the disable bit prior to cryptographic operations that are sensitive on M3 and above.

Also looks like they need to predetermine aspects of the key.

Very cool but I don’t think it looks particularly practical.

Post reply on HN