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

71–80 of 100 posts

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

#71

Post by kbolino »

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.

If you account for all of the CPU "features" that can be exploited, you're looking at probably 80% of what makes it "ridiculously fast". If you also account for all of the ways in which the entire modern hardware ecosystem can be exploited, you're probably looking at gross performance loss of over 90% to remove these "holes".

An overclocked 486 PC that can only run a single program at a time and isn't continuously connected to a network might be very secure, but replacing every modern computer with something like it will not be even remotely feasible. In most situations, it would be better to have some risk tolerance, and couple modern hardware with mitigations, disposability, and supply-chain security instead.

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

#73

Post by olliej »

FiloSottile wrote: post #17
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…

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…

> No, processor designers "just" need to stop violating assumptions, or at least talk to us before doing it.

No, you don't get to say processor designers need to stop violating your assumptions. You need to stop making assumptions about behaviour if that behavior is important (for cryptographic or other reasons). Your assumptions being faulty are not a valid justification, because that would mean no one could have ever added any caches or predictors at any point because that would be "violating your assumptions". Also lets be real here: even if "not violating your assumptions" was a reasonable position to take, it is not reasonable in any way to make any kind of assumption about modern processors (anything.

If you care about constant time behaviour you should either be writing your code such that it is timing agnostic, or you could read the platform documentation rather than making assumptions. The apple documentation tells you how to actually get constant time behavior, rather than making assumptions.

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

#74

Post by olliej »

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?

Because JS/html provides APIs to perform cryptography(I can't recall whether the cryptography specs are part of ES or HTML/DOM) - if you try to implement constant time cryptography in JS you will run into a world of hurt due to the entire concept of "fast JS" being dependent on heavy speculation, and lots of exciting variations in timing of even "primitive" operations.

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

#75

Post by olliej »

crest wrote: post #53
saagarjha wrote: post #42

Earlier quoted context omitted.

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

Happily there are mechanisms to do just that, specifically for the purpose of implementing cryptography (I commented at the top level and don't want to just spamming the url).

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

#76

Post by olliej »

0xedd wrote: post #66

Why does Apple have so many hardware backd... innocent bugs?

why do we even need caches?

why do we need prefetchers?

But in answer to your bullshit backdoor conspiracy theory (JFC processors have caches and timing variants because people want fast CPUs, you cannot have constant time and fast, apple is not the only company with prefetchers), here's some apple provided documentation on how disable the hardware backd... enable constant time operations specifically for the purpose of cryptography, almost like it's designed into the hardware. So weird. https://developer.apple.com/documentation/xcode/writing-arm6...

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

#77

Post by FiloSottile »

olliej wrote: post #73
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…

> No, processor designers "just" need to stop violating assumptions, or at least talk to us before doing it. No, you don't get to say processor designers need to stop violating your assumptions. You need to stop making assumptions about behaviour if that behavior is important (for cryptographic or other reasons). Your assumptions being faulty are not a valid justification, because that would mean no one could have ev…

> you should either be writing your code such that it is timing agnostic, or you could read the platform documentation rather than making assumptions

Have you even read the paper? Especially the part where the attack applies to everyone’s previous idea of “timing agnostic” code, and the part where Apple does not respect the (new) DIT flag on M1/M2?

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

#78

Post by 12_throw_away »

martinky24 wrote: post #3

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

Dunno, but I'm glad they do it. In other fields of research, researchers often purposely hold off on naming something, so that the community kind of has no choice but to name it after the authors themselves.

Eg in my field, they would have called Spectre "the Horn-Genkin-Hamburg vulnerability" or something. Which one of these is hard-to-remember jargon, and which one is catchy and evocative?

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

#80

Post by olliej »

FiloSottile wrote: post #77
olliej wrote: post #73

Earlier quoted context omitted.

> No, processor designers "just" need to stop violating assumptions, or at least talk to us before doing it. No, you don't get to say processor designers need to stop violating your assumptions. You need to stop making assumptions about behaviour if that behavior is important (for cryptographic or other reasons). Your assumptions being faulty are not a valid justification, because that would mean no one could have ev…

> you should either be writing your code such that it is timing agnostic, or you could read the platform documentation rather than making assumptions Have you even read the paper? Especially the part where the attack applies to everyone’s previous idea of “timing agnostic” code, and the part where Apple does not respect the (new) DIT flag on M1/M2?

No, the paper targets "constant time" operations, not timing agnostic.

The paper even mentions that blinding works, and that to me is the canonical "separate the time and power use of the operation from the key material" solution. The complaint about this approach in the paper being is that it would be specific to these prefetchers, but it seems this type of prefetcher is increasingly prevalent across multiple cpus and architectures so it seems unlikely to be apple specific for long. The paper even mentions new intel processors have these prefetchers and so necessarily provide functionality to disable them there too. This is all before we get to the numerous prior articles showing that key extraction via side channels is already possible with these constant time algorithms (a la last months(I think?) "get the secrets from the power led" paper). The solution is to use either specialized hardware (as done for AES) or timing agnostic code.

Trying to create side channel free code by clever construction based on assumptions about power and performance of all hardware based on a simple model of how CPUs behave is going to just change the side channels, not remove them. If it's a real attack vector that you are really concerned about you should probably just do best effort and monitor for repeated key reuse or the like, and then start blinding at some threshold.

Post reply on HN