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

61–70 of 100 posts

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

#61

Post by john_alan »

Kluggy wrote: post #56
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...

If you look at the cryptokit API docs the Secure Enclave essentially only supports P-256. Which is maybe why they didn’t include ECC crypto in the examples.

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

#62

Post by snvzz »

saagarjha wrote: post #58
snvzz wrote: post #57

Earlier quoted context omitted.

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

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

Because it does not. I also do not see where, if at all, such claim was made.

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

#63

Post by saagarjha »

john_alan wrote: post #60
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?

It's probably in a MSR accessible from the kernel?

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

#64

Post by saagarjha »

snvzz wrote: post #62
saagarjha wrote: post #58

Earlier quoted context omitted.

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

>I don't really see how the design of RISC-V avoids the need to have a DMP Because it does not. I also do not see where, if at all, such claim was made.

Perhaps you should explain how this design effort spent preventing side-channel attacks is spent, then?

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

#65

Post by 0xedd »

saagarjha wrote: post #45
martinky24 wrote: post #3

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

Why does the comments of every such attack need a question about why it has its own branding, marketing page, etc…? Genuine question. (Seriously, this comes up every time, just do a search for it if you actually want to figure out why.)

Because it makes it feel like you need some marketing department if you want to publish your work. Rather than give _only_ the work merit, we give too much merit to its colorful presentation. That shouldn't be the case.

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

#67

Post by lenerdenator »

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.

> multi-tenant cloud-based virtualization

And that's why I'm not as worried about this as I was about the same vulnerability in Intel chips a few years ago.

There are a few cloud service providers that will rent you clock cycles on a rack-mounted Mac Mini, but not many, and even then they're for highly-specific workloads or build tasks. I suppose that's a problem for people paying far out the butt for that kind of service, but the vast majority of Apple Silicon devices are never, ever going to host cloud services.

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

#68

Post by epcoa »

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.

Anything specific?

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

#69

Post by lxgr »

Kluggy wrote: post #56
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...

The secure enclave is not a general-purpose/user-programmable processor. It only runs Apple-signed code, and access is only exposed via the Keychain APIs, which only support a very limited set of cryptographic operations.

Presumably latency for any operation is also many orders of magnitude higher than in-thread crypto, so that just doesn't work for many applications.

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

#70

Post by lxgr »

saagarjha wrote: post #63
john_alan wrote: post #60

Earlier quoted context omitted.

I’ve often wondering how are these bits set? Like can you do it from Swift? Or need assembly?

It's probably in a MSR accessible from the kernel?

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 as early as 2021 being suspicious of DIT: https://github.com/golang/go/issues/49702

Post reply on HN