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

51–60 of 100 posts

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

#51

Post by wmf »

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.

If untrusted code includes JavaScript that would make Web apps ridiculously slow. (I know what you're thinking...)

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

#52

Post by bee_rider »

wmf wrote: post #51
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.

If untrusted code includes JavaScript that would make Web apps ridiculously slow. (I know what you're thinking...)

Oh no, a totally unexpected side effect, less complex webpages.

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

#53

Post by crest »

saagarjha wrote: post #42
titzer wrote: post #29

Earlier quoted context omitted.

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…

Turning off bounds checks is like a 5% performance penalty. Turning off prefetching is like using a computer from twenty years ago.

Turning off prefetching while running crypto code would be a performance gain before you can implement the algorithms safely without even more expensive and fragile software mitigations. Just give me the option of configuring parts of the caches (at least data + instructions + TLBs) as scratchpad and and a "run without timing side-channels pretty please" bit with a clearly defined API contract and accessible (by default) to unprivileged userspace code. Lots of cryptographic algorithms have such small working sets that they would profit from a constant-time accessible scratchpad in the L1d cache if they get to use data dependent addresses into it again.

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

#55

Post by samatman »

cryptonector wrote: post #50
arp242 wrote: post #33

Earlier quoted context omitted.

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.

> Is this exploitable through JavaScript? Why wouldn't it be?

How is JavaScript going to run a chosen-input attack against one of your cores for an hour?

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

#56

Post by Kluggy »

jerf wrote: post #7

As long as we're getting efficiency cores and such, maybe we need some "crypto cores" added to modern architectures, that make promises specifically related to constant time algorithms like this and promise not to prefetch, branch predict, etc. Sort of like the Itanium, but confined to a "crypto processor". Given how many features these things wouldn't have, they wouldn't be much silicon for the cores themselves, in…

Isn't that the entire point of the secure enclave[1]?

https://support.apple.com/guide/security/secure-enclave-sec5...

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

#57

Post by snvzz »

saagarjha wrote: post #43
bee_rider wrote: post #36

Earlier quoted context omitted.

> 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 developme…

How is RISC-V going to solve anything here?

It is significantly less complex yet without compromising anything. This means a larger portion of a chip's design effort can be put elsewhere such as into preventing side channel attacks.

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

#58

Post by saagarjha »

snvzz wrote: post #57
saagarjha wrote: post #43

Earlier quoted context omitted.

How is RISC-V going to solve anything here?

It is significantly less complex yet without compromising anything. This means a larger portion of a chip's design effort can be put elsewhere such as into preventing side channel attacks.

I don't really see how the design of RISC-V avoids the need to have a DMP

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

#59

Post by a-dub »

jerf wrote: post #7

As long as we're getting efficiency cores and such, maybe we need some "crypto cores" added to modern architectures, that make promises specifically related to constant time algorithms like this and promise not to prefetch, branch predict, etc. Sort of like the Itanium, but confined to a "crypto processor". Given how many features these things wouldn't have, they wouldn't be much silicon for the cores themselves, in…

see DIT and DOIT flags referenced in the paper and in the faq question about mitigations. newer CPUs apparently provide functions to do just that.

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

#60

Post by john_alan »

saagarjha wrote: post #41

> Can the DMP be disabled? > Yes, but only on some processors. We observe that the DIT bit set on m3 CPUs effectively disables the DMP. This is not the case for the m1 and m2. Surely there is a chicken bit somewhere to do this?

I’ve often wondering how are these bits set?

Like can you do it from Swift? Or need assembly?

Post reply on HN