TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

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

297 pointsby kingsleyoparaabout 1 year ago

12 comments

jerfabout 1 year ago
As long as we&#x27;re getting efficiency cores and such, maybe we need some &quot;crypto cores&quot; 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 &quot;crypto processor&quot;. Given how many features these things <i>wouldn&#x27;t</i> have, they wouldn&#x27;t be much silicon for the cores themselves, in principle.<p>This is the sort of thing that would metaphorically drive me to drink if I were implementing crypto code. It&#x27;s an uphill battle at the best of times, but even if I finally get it all right, there&#x27;s dozens of processor features both current and future ready to blow my code up at any time.
评论 #39781478 未加载
评论 #39781796 未加载
评论 #39787667 未加载
评论 #39782350 未加载
评论 #39781591 未加载
评论 #39780965 未加载
评论 #39781357 未加载
评论 #39788558 未加载
评论 #39782330 未加载
xiconfjsabout 1 year ago
From the paper: &quot;OpenSSL reported that local side-channel attacks (...) fall outside of their threat model. The Go Crypto team considers this attack to be low severity&quot;.
评论 #39801093 未加载
theobservorabout 1 year ago
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.<p>As long as these effects cannot be exploited remotely, it&#x27;s not a concern. Of course multi-tenant cloud-based virtualization would be a no go.
评论 #39782773 未加载
评论 #39790652 未加载
评论 #39783023 未加载
saagarjhaabout 1 year ago
&gt; Can the DMP be disabled?<p>&gt; 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.<p>Surely there is a chicken bit somewhere to do this?
评论 #39789371 未加载
john_alanabout 1 year ago
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.<p>Also looks like they need to predetermine aspects of the key.<p>Very cool but I don’t think it looks particularly practical.
woadwarrior01about 1 year ago
Reminded me of the Augury attack[1] from 2022, which also exploits the DMP prefetcher on Apple Silicon CPUs.<p>[1]: <a href="https:&#x2F;&#x2F;www.prefetchers.info" rel="nofollow">https:&#x2F;&#x2F;www.prefetchers.info</a>
评论 #39781275 未加载
评论 #39780928 未加载
0xeddabout 1 year ago
Why does Apple have so many hardware backd... innocent bugs?
评论 #39792684 未加载
评论 #39817369 未加载
olliejabout 1 year ago
If you&#x27;re writing cryptographic routines you should either use the platform cryptography libraries, or follow the documentation:<p><a href="https:&#x2F;&#x2F;developer.apple.com&#x2F;documentation&#x2F;xcode&#x2F;writing-arm64-code-for-apple-platforms#Enable-DIT-for-constant-time-cryptographic-operations" rel="nofollow">https:&#x2F;&#x2F;developer.apple.com&#x2F;documentation&#x2F;xcode&#x2F;writing-arm6...</a>
slowmovintargetabout 1 year ago
So malware scanning and virus scanners just became relevant for Macs and IPads.<p>(Compromise must be running on the same hardware.)
Shtirlicabout 1 year ago
Is it naive to ask whether implementing this mitigation would impact performance and memory interaction speed?
d-z-mabout 1 year ago
what&#x27;s the attack vector here? access to an encrypt oracle and co-location on the target machine?
martinky24about 1 year ago
Why does every attack needs its own branding, marketing page, etc...? Genuine question.
评论 #39780907 未加载
评论 #39781540 未加载
评论 #39780673 未加载
评论 #39792998 未加载
评论 #39780816 未加载
评论 #39780483 未加载
评论 #39784154 未加载
评论 #39783441 未加载
评论 #39781528 未加载