4 ms·

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

by john_alan 3y ago

saagarjha 3y ago
It's probably in a MSR accessible from the kernel?
- lxgr 3y ago
  It seems to be userspace accessible: https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Enable-DIT-for-constant-time-cryptographic-operations 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 https://github.com/golang/go/issues/49702
  - saagarjha 3y ago
    No, that’s something else. I’m talking about the thing that disables DMP, which would not be part of the standard architecture.
    - saurik 3y ago
      Give the quote, I don't understand why you think these are different.
      - saagarjha 3y ago
        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.
        saurik 3y ago
        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"?
        saagarjha 3y ago
        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).
        saurik 3y ago
        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).
        saagarjha 3y ago
        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.

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

saagarjha 3y ago

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

lxgr 3y ago
It seems to be userspace accessible: https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Enable-DIT-for-constant-time-cryptographic-operations 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 https://github.com/golang/go/issues/49702
- saagarjha 3y ago
  No, that’s something else. I’m talking about the thing that disables DMP, which would not be part of the standard architecture.
  - saurik 3y ago
    Give the quote, I don't understand why you think these are different.
    - saagarjha 3y ago
      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.
      - saurik 3y ago
        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"?
        saagarjha 3y ago
        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).
        saurik 3y ago
        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).
        saagarjha 3y ago
        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.