from Hacker News

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

by kingsleyopara on 3/21/24, 2:51 PM with 92 comments

  • by jerf on 3/21/24, 4:37 PM

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

    This is the sort of thing that would metaphorically drive me to drink if I were implementing crypto code. It's an uphill battle at the best of times, but even if I finally get it all right, there's dozens of processor features both current and future ready to blow my code up at any time.

  • by xiconfjs on 3/21/24, 4:53 PM

    From the paper: "OpenSSL reported that local side-channel attacks (...) fall outside of their threat model. The Go Crypto team considers this attack to be low severity".
  • by theobservor on 3/21/24, 4:44 PM

    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.

  • by saagarjha on 3/21/24, 8:35 PM

    > 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?

  • by john_alan on 3/21/24, 8:24 PM

    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.

  • by woadwarrior01 on 3/21/24, 3:56 PM

    Reminded me of the Augury attack[1] from 2022, which also exploits the DMP prefetcher on Apple Silicon CPUs.

    [1]: https://www.prefetchers.info

  • by 0xedd on 3/22/24, 1:18 PM

    Why does Apple have so many hardware backd... innocent bugs?
  • by olliej on 3/22/24, 4:36 PM

    If you're writing cryptographic routines you should either use the platform cryptography libraries, or follow the documentation:

    https://developer.apple.com/documentation/xcode/writing-arm6...

  • by slowmovintarget on 3/23/24, 5:09 PM

    So malware scanning and virus scanners just became relevant for Macs and IPads.

    (Compromise must be running on the same hardware.)

  • by Shtirlic on 3/21/24, 9:16 PM

    Is it naive to ask whether implementing this mitigation would impact performance and memory interaction speed?
  • by d-z-m on 3/22/24, 2:52 AM

    what's the attack vector here? access to an encrypt oracle and co-location on the target machine?
  • by martinky24 on 3/21/24, 4:08 PM

    Why does every attack needs its own branding, marketing page, etc...? Genuine question.