4 ms·

I'm a bit confused - how do you do pointer arithmetic if the cpu encrypts pointers for your automatically and doesn't let you know the actual address in memory

• joshka 6y ago
  I know nothing of the implementation, but hypothetically a compiler could translate: p++ to instructions that effectively do: p = enc(dec(p)+1) Without exposing p outside the CPU. The implementation described (seems to be) new instructions for incrementing and dereferencing pointers.
  • bawolff 6y ago
    In which case, can't you just use it in your shell code? I guess the defense is info leaks are useless so you can't defeat aslr(?)
    • joshka 6y ago
      (that should have read without disclosing dec(p)) But yeah, you'd have to end up with equivalents to p* = 123 which becomes (dec(p)* = 123 etc. My guess is that due to the simon cipher they're allocating full blocks whenever you do the safe version of malloc, and then do a range check to ensure that there is no overrun when storing / incrementing etc.
• kazinator 6y ago
  This is, from what I gather from the paper, because the pointers are not individually encrypted via cipher. Rather, pointers in the same domain (domains being identified via a tagging scheme) are all displaced together by a common value, which comes from that encryption engine. So imagine that some pointers p and q are actually p + c and q + c under the hood. When the machine churns, c will change, and so all pointers have to be updated. There is some sort of moving barrier which indicates which parts of memory are "clean" (ready for use) and which are still using the old key.