6 ms·

With address space randomization, if you have a valid pointer to memory A, you can compute a valid pointer to memory B if they are from the same section. You c

With address space randomization, if you have a valid pointer to memory A, you can compute a valid pointer to memory B if they are from the same section. You can't do that with this, because the address is part of the signature.

deleted 9y ago
[deleted]
haberman 9y ago
This doesn't affect regular pointers. It creates a new type of pointer, a "signed pointer." You don't dereference or perform arithmetic on signed pointers. You create signed pointers with one instruction ("PAC") and decode/decrypt them into regular pointers with a different instruction ("AUT"). The decoding/decrypting checks the signature and decodes it into a NULL pointer if the signature is bad. All normal pointers and dereferencing continue to work the same. It only affects code that explicitly decides to use these special instructions to create/validate signed pointers. Only certain code (like the code that saves a return address to the stack) would choose to do this, for cases where an attacker is especially likely to try corrupting the pointer.
- im3w1l 9y ago
  > The decoding/decrypting checks the signature and decodes it into a NULL pointer if the signature is bad. Hmm wouldn't a trap be better?
  - fanf2 9y ago
    I expect this is to allow for code which might have an uninitialized pointer, and wants to decrypt it concurrently with other validity tests (relying on multiple issue width) Or, the designers didn't want to add an interlock between the memory subsystems that handle traps, and the crypto subsystem that does the decryption.
colejohnson66 9y ago
How does that not mess with pointer arithmetic?
- dreamcompiler 9y ago
  Looks like the current patch only deals with instruction pointers, but I'd assume that for data, the base pointers would have validation instructions automatically inserted before offset arithmetic is done.
- ris 9y ago
  You're not supposed to do pointer arithmetic with these pointers. It's generally meant for storing pointers "at rest".
- munin 9y ago
  You read the pointer from memory, unbox the pointer into an integer, do arithmetic, then box it back up and write it back into memory. The pointer-as-integer stays in registers while you do arithmetic on it.

deleted 9y ago

[deleted]

haberman 9y ago

This doesn't affect regular pointers. It creates a new type of pointer, a "signed pointer." You don't dereference or perform arithmetic on signed pointers. You create signed pointers with one instruction ("PAC") and decode/decrypt them into regular pointers with a different instruction ("AUT"). The decoding/decrypting checks the signature and decodes it into a NULL pointer if the signature is bad. All normal pointers and dereferencing continue to work the same. It only affects code that explicitly decides to use these special instructions to create/validate signed pointers. Only certain code (like the code that saves a return address to the stack) would choose to do this, for cases where an attacker is especially likely to try corrupting the pointer.

im3w1l 9y ago
> The decoding/decrypting checks the signature and decodes it into a NULL pointer if the signature is bad. Hmm wouldn't a trap be better?
- fanf2 9y ago
  I expect this is to allow for code which might have an uninitialized pointer, and wants to decrypt it concurrently with other validity tests (relying on multiple issue width) Or, the designers didn't want to add an interlock between the memory subsystems that handle traps, and the crypto subsystem that does the decryption.

colejohnson66 9y ago

How does that not mess with pointer arithmetic?

dreamcompiler 9y ago
Looks like the current patch only deals with instruction pointers, but I'd assume that for data, the base pointers would have validation instructions automatically inserted before offset arithmetic is done.
ris 9y ago
You're not supposed to do pointer arithmetic with these pointers. It's generally meant for storing pointers "at rest".
munin 9y ago
You read the pointer from memory, unbox the pointer into an integer, do arithmetic, then box it back up and write it back into memory. The pointer-as-integer stays in registers while you do arithmetic on it.