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

91–100 of 100 posts

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

#91

Post by SpaghettiCthulu »

bee_rider wrote: post #24
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…

One option would be for people to stop downloading viruses and then running them.

Except when these vulnerabilities are exploitable from JavaScript in your web browser.

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

#93

Post by m0rshu »

FiloSottile wrote: post #19
martinky24 wrote: post #3

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

Names are critical to enable discussion. The "marketing" page is where documentation is. Summaries that don't require reading a whole academic papers are a good thing, and they are the place where all the different links are collected. Same reason software has READMEs. Logos... are cute and take 10-60 minutes? If you spend months on some research might as well take the satisfaction of giving it a cute logo, why not.

[dead]

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

#94

Post by cryptonector »

olliej wrote: post #86
cryptonector wrote: post #82

Earlier quoted context omitted.

No, the attack would be implemented in JS, not the victim code (though, that too, but that's not what's interesting here).

Ah, you’re concerned about person using js to execute the side channel portion of the attack, not the bit creating the side channel :)

FYI malicious JS executing in victim users' browsers is a huge concern. All sorts of vulnerabilities can be exploited via JS in this way -- every local side-channel like Spectre/Meltdown, worse things like Row Hammer, etc.

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

#95

Post by saurik »

saagarjha wrote: post #87
lxgr wrote: post #70

Earlier quoted context omitted.

It seems to be userspace accessible: https://developer.apple.com/documentation/xcode/writing-arm6... The kernel would have to be aware of it in order to be able to restore its state across context switches though, unless it's part of a set of registers that is automatically persisted. But given that Apple is publicly documenting this flag, I suppose it is. Here's an interesting conversation by the Go developers from…

No, that’s something else. I’m talking about the thing that disables DMP, which would not be part of the standard architecture.

Give the quote, I don't understand why you think these are different.

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

#96

Post by saagarjha »

saurik wrote: post #95
saagarjha wrote: post #87

Earlier quoted context omitted.

No, that’s something else. I’m talking about the thing that disables DMP, which would not be part of the standard architecture.

Give the quote, I don't understand why you think these are different.

While this doesn't have to be the case, in theory the DMP and DIT can be orthogonal, since leaking data from the DMP is done after-the-fact on caches that might have been populated from code running in constant time. More generally, you can't really know whether such effects are eliminated or not, because DIT specifies some architectural level of "things take the same time" and doesn't actually tell you more about what is going on in the chip. If Apple mistakenly thinks that the DMP is actually not sensitive, and they forget to wire it up to DIT, then you'll be stuck.

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

#97

Post by saurik »

saagarjha wrote: post #96
saurik wrote: post #95

Earlier quoted context omitted.

Give the quote, I don't understand why you think these are different.

While this doesn't have to be the case, in theory the DMP and DIT can be orthogonal, since leaking data from the DMP is done after-the-fact on caches that might have been populated from code running in constant time. More generally, you can't really know whether such effects are eliminated or not, because DIT specifies some architectural level of "things take the same time" and doesn't actually tell you more about wh…

So, what you are saying is that you believe the authors were incorrect when they stated "We observe that the DIT bit set on m3 CPUs effectively disables the DMP."; like, your response to my question is (effectively) "I don't believe that quote"?

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

#98

Post by saagarjha »

saurik wrote: post #97
saagarjha wrote: post #96

Earlier quoted context omitted.

While this doesn't have to be the case, in theory the DMP and DIT can be orthogonal, since leaking data from the DMP is done after-the-fact on caches that might have been populated from code running in constant time. More generally, you can't really know whether such effects are eliminated or not, because DIT specifies some architectural level of "things take the same time" and doesn't actually tell you more about wh…

So, what you are saying is that you believe the authors were incorrect when they stated "We observe that the DIT bit set on m3 CPUs effectively disables the DMP."; like, your response to my question is (effectively) "I don't believe that quote"?

My response to your specific question is "I believe them when they say that but there is no need for this to be true, and in fact apparently Apple didn't do them in older chip revisions and I'm not sure that is a bug". However I do believe the authors were incorrect when they said "there is no way to disable the DMP on M1 and M2" (surely not involving DIT).

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

#99

Post by saurik »

saagarjha wrote: post #98
saurik wrote: post #97

Earlier quoted context omitted.

So, what you are saying is that you believe the authors were incorrect when they stated "We observe that the DIT bit set on m3 CPUs effectively disables the DMP."; like, your response to my question is (effectively) "I don't believe that quote"?

My response to your specific question is "I believe them when they say that but there is no need for this to be true, and in fact apparently Apple didn't do them in older chip revisions and I'm not sure that is a bug". However I do believe the authors were incorrect when they said "there is no way to disable the DMP on M1 and M2" (surely not involving DIT).

No one claimed it needed to be true, merely that it is true: if we believe (as you claim you do) the first part of the quote, Apple clearly decided at some point -- maybe due to the dawning realization of this very kind of attack (even if the organization didn't model it as such) -- to make DIT also (if saying such makes you feel better) disable this feature, at which point this mechanism is available to userland... which you claimed it would not be (which honestly doesn't make sense anyway to assume as nothing prevents a new bespoke M-specific mechanism / register / whatever--even if it were undocumented!!--from being available to userland).

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

#100

Post by saagarjha »

saurik wrote: post #99
saagarjha wrote: post #98

Earlier quoted context omitted.

My response to your specific question is "I believe them when they say that but there is no need for this to be true, and in fact apparently Apple didn't do them in older chip revisions and I'm not sure that is a bug". However I do believe the authors were incorrect when they said "there is no way to disable the DMP on M1 and M2" (surely not involving DIT).

No one claimed it needed to be true, merely that it is true: if we believe (as you claim you do) the first part of the quote, Apple clearly decided at some point -- maybe due to the dawning realization of this very kind of attack (even if the organization didn't model it as such) -- to make DIT also (if saying such makes you feel better) disable this feature, at which point this mechanism is available to userland...…

Apple typically does not make these kinds of things (namely, special Apple silicon stuff) accessible to userland. I think they probably have some specific agreement with ARM to not do it.
Post reply on HN