3 ms·

What are you basing “so it must not be used” on? I would think it can’t harm, ever.

adrian_b 4y ago
Like you say, it does not do much harm if used. Nevertheless, there is some small loss of performance, because instructions to compute the Pointer Authentication Code (PAC) must be inserted in the program, and possibly also instructions to authenticate the PAC, though the latter may be omitted if the function return instructions and the indirect jumps through pointers are replaced with instructions that combine the pointer authentication with the jump. I have no idea whether on the Apple CPUs the jumps/returns with authentication have the same speed with the simple jumps/returns. I suppose that the Apple compiler adds automatically the PAC computation and authentication instructions, so using this option does not increase the complexity of the source code. Nevertheless, even if the performance impact of using PAC might not be important, whenever a security feature that does not work is used, there is the danger that there will be some people who do not know that it does not work, so they will believe that exploits are impossible and there is no need to be careful to avoid the possibility that an adversary might be able to modify a pointer, e.g. by crafting a special input to the application. In general all the variants of pointer validation that have been recently introduced in all CPU architectures are just workarounds against the bugs introduced by programmers, because in a well written program there should be no way for an adversary to modify an internal pointer.
- astrange 4y ago
  "All programs must be well written" with nothing in the ISA to help you write them properly isn't a good way to do software. PAC helps you reduce bugs because it checksums your pointers.
  - adrian_b 4y ago
    The most important helping feature of an ISA is to provide an efficient way to compare indices and pointers against limits, so that the poor performance of limits checking will not discourage the compiler writers and the compiler users to always make such checks. Any decent C/C++ compiler has compile options to check all array accesses against limits, which, coupled with the good programming practice of always using indices and not pointers for memory accesses, can catch all the programming errors of the buffer overflow type. However, neither the compilers enable this option by default nor most programmers take care to always enable it, because of usually baseless worries of degrading the performance. Checking accesses against limits catches any such bugs at their origin, not much later when a corrupt pointer is identified by PAC, without knowing how it became corrupt. Intel has made an attempt with Skylake to introduce some instructions for easier limits checking, but unfortunately the instructions conceived by them were just dumb and not helpful at all, so they have been eventually deprecated. Better support exists in the IBM POWER ISA, which has conditional trap instructions.
dreamcompiler 4y ago
Security techniques that have known workarounds cause harm by engendering a false sense of security.
- _kbh_ 4y ago
  nearly every security feature in existence has known (situation dependent) work arounds. That does not mean you should turn them off.
- deleted 4y ago
  [deleted]

Like you say, it does not do much harm if used. Nevertheless, there is some small loss of performance, because instructions to compute the Pointer Authentication Code (PAC) must be inserted in the program, and possibly also instructions to authenticate the PAC, though the latter may be omitted if the function return instructions and the indirect jumps through pointers are replaced with instructions that combine the pointer authentication with the jump. I have no idea whether on the Apple CPUs the jumps/returns with authentication have the same speed with the simple jumps/returns. I suppose that the Apple compiler adds automatically the PAC computation and authentication instructions, so using this option does not increase the complexity of the source code. Nevertheless, even if the performance impact of using PAC might not be important, whenever a security feature that does not work is used, there is the danger that there will be some people who do not know that it does not work, so they will believe that exploits are impossible and there is no need to be careful to avoid the possibility that an adversary might be able to modify a pointer, e.g. by crafting a special input to the application. In general all the variants of pointer validation that have been recently introduced in all CPU architectures are just workarounds against the bugs introduced by programmers, because in a well written program there should be no way for an adversary to modify an internal pointer.

astrange 4y ago
"All programs must be well written" with nothing in the ISA to help you write them properly isn't a good way to do software. PAC helps you reduce bugs because it checksums your pointers.
- adrian_b 4y ago
  The most important helping feature of an ISA is to provide an efficient way to compare indices and pointers against limits, so that the poor performance of limits checking will not discourage the compiler writers and the compiler users to always make such checks. Any decent C/C++ compiler has compile options to check all array accesses against limits, which, coupled with the good programming practice of always using indices and not pointers for memory accesses, can catch all the programming errors of the buffer overflow type. However, neither the compilers enable this option by default nor most programmers take care to always enable it, because of usually baseless worries of degrading the performance. Checking accesses against limits catches any such bugs at their origin, not much later when a corrupt pointer is identified by PAC, without knowing how it became corrupt. Intel has made an attempt with Skylake to introduce some instructions for easier limits checking, but unfortunately the instructions conceived by them were just dumb and not helpful at all, so they have been eventually deprecated. Better support exists in the IBM POWER ISA, which has conditional trap instructions.

dreamcompiler 4y ago

Security techniques that have known workarounds cause harm by engendering a false sense of security.

_kbh_ 4y ago
nearly every security feature in existence has known (situation dependent) work arounds. That does not mean you should turn them off.
deleted 4y ago
[deleted]