4 ms·

As a ROP mitigation measure some recent CPU models have a feature that can require code to branch to a special instruction signifying a valid target; jumps to a

by wahern 3y ago

As a ROP mitigation measure some recent CPU models have a feature that can require code to branch to a special instruction signifying a valid target; jumps to an address that doesn't contain that instruction result in a CPU fault. On OpenBSD such a fault is translated to SIGILL, apparently, which can also occur when the CPU encounters other issues, like an invalidly encoded instruction. This patch differentiates the new type of fault so it's easier to identify within process signal handlers by adding a new reason code, ILL_BTCFI, to SIGILL info (siginfo_t). The full patch is at https://github.com/openbsd/src/commit/88580652a3669007813512ab28f5ee7ceeae4a78 https://github.com/openbsd/src/commit/88580652a3669007813512... I'm not sure if this patch is noteworthy on its own, but perhaps it was posted because it implies this CPU feature is now supported or soon to be supported by OpenBSD.

brynet 3y ago
> I'm not sure if this patch is noteworthy on its own, but perhaps it was posted because it implies this CPU feature is now supported or soon to be supported by OpenBSD. OpenBSD has supported mandatory BTI/IBT on Intel CPUs (11th Gen+) and arm64 (Apple M2) since 7.4 (Oct 16, 2023). https://www.openbsd.org/innovations.html https://www.openbsd.org/innovations.html "Mandatory enforcement of indirect branch targets (BTI on arm64, IBT on Intel amd64), unless a linker flag (-Wl,-z,nobtcfi) requests no enforcement." https://marc.info/?l=openbsd-ports&m=168899645126958&w=2 https://marc.info/?l=openbsd-ports&m=168899645126958&w=2 OpenBSD recently disabled retpolines by default because they are incompatible with IBT, so there has been some work done recently that this patch could help with, e.g: adding missing indirect branch target instructions (endbr64), previously hidden by retpoline. OpenBSD has done a lot of work to push these changes into the entire software ecosystem.
- guenthert 3y ago
  Did I get that right? The company which brought us SPECTRE now brings us a feature requiring us to disable SPECTRE mitigation? I haven't followed this and surely misrepresent the facts above. This is just a plea for someone in the know to clarify the situation.
MuffinFlavored 3y ago
> As a ROP mitigation measure some recent CPU models have a feature that can require code to branch to a special instruction signifying a valid target; jumps to an address that doesn't contain that instruction result in a CPU fault. How much of a performance flow mitigation is this, 3-5%?
- jeffbee 3y ago
  Compiler-based CFI has low single digits impact. Hardware with ENDBR will be hard to notice, "none" being a reasonably accurate estimate of the impact, unless your code is weird and unusually dense with valid indirect branch targets.
- kevingadd 3y ago
  in fast paths almost all the code you're running is in icache, and even the decoded micro-ops are probably cached, so I bet it's even cheaper than that.
sweetjuly 3y ago
For more context, CET and friends don't actually act as a ROP mitigation in it of themselves. CET is a coarse forward edge CFI technique. For completeness, you must pair it with both some software function type assert (prevent argument type confusion by swapping function pointers, etc.) as well as a backwards edge CFI mitigation (such as secure a shadow stack for storing link addresses). Both are quite hard problems. ARM's Pointer Authentication extension is an interesting alternative which does all of this in one feature by cryptographically signing pointers in memory.
- admax88qqq 3y ago
  Jesus. The amount of engineering that has to happen to protect against C is astounding.
  - wahern 3y ago
    Protecting JIT-compiled code, e.g. within browsers, is at least as important a concern. Some would argue much more important, especially as usage of services like Cloudflare Workers increases. Techniques like CHERI could replace MMUs in some environments, potentially improving performance.
    - admax88qqq 3y ago
      There's no way to express an out of bounds memory read/write in JavaScript. So you don't actually need an MMU, or CHERI, or pointer signing, or any of the stack smashing mitigations put in place for C. You do have to generate correct code but that's actually a solvable problem, web assembly did it. In theory this could unlock tons of performance (and free up some silicon) if we could ever get the rest of the system away from C
      - deleted 3y ago
        [deleted]
- dwattttt 3y ago
  CET is both Indirect Branch Tracking and Shadow Stacks; IBT is the coarse towards CFI, but SSs are a direct ROP mitigation, but enforcing that any address returned to must have been CALL'd from.

by wahern 3y ago

brynet 3y ago

> I'm not sure if this patch is noteworthy on its own, but perhaps it was posted because it implies this CPU feature is now supported or soon to be supported by OpenBSD. OpenBSD has supported mandatory BTI/IBT on Intel CPUs (11th Gen+) and arm64 (Apple M2) since 7.4 (Oct 16, 2023). https://www.openbsd.org/innovations.html https://www.openbsd.org/innovations.html "Mandatory enforcement of indirect branch targets (BTI on arm64, IBT on Intel amd64), unless a linker flag (-Wl,-z,nobtcfi) requests no enforcement." https://marc.info/?l=openbsd-ports&m=168899645126958&w=2 https://marc.info/?l=openbsd-ports&m=168899645126958&w=2 OpenBSD recently disabled retpolines by default because they are incompatible with IBT, so there has been some work done recently that this patch could help with, e.g: adding missing indirect branch target instructions (endbr64), previously hidden by retpoline. OpenBSD has done a lot of work to push these changes into the entire software ecosystem.

guenthert 3y ago
Did I get that right? The company which brought us SPECTRE now brings us a feature requiring us to disable SPECTRE mitigation? I haven't followed this and surely misrepresent the facts above. This is just a plea for someone in the know to clarify the situation.

MuffinFlavored 3y ago

> As a ROP mitigation measure some recent CPU models have a feature that can require code to branch to a special instruction signifying a valid target; jumps to an address that doesn't contain that instruction result in a CPU fault. How much of a performance flow mitigation is this, 3-5%?

jeffbee 3y ago
Compiler-based CFI has low single digits impact. Hardware with ENDBR will be hard to notice, "none" being a reasonably accurate estimate of the impact, unless your code is weird and unusually dense with valid indirect branch targets.
kevingadd 3y ago
in fast paths almost all the code you're running is in icache, and even the decoded micro-ops are probably cached, so I bet it's even cheaper than that.

sweetjuly 3y ago

For more context, CET and friends don't actually act as a ROP mitigation in it of themselves. CET is a coarse forward edge CFI technique. For completeness, you must pair it with both some software function type assert (prevent argument type confusion by swapping function pointers, etc.) as well as a backwards edge CFI mitigation (such as secure a shadow stack for storing link addresses). Both are quite hard problems. ARM's Pointer Authentication extension is an interesting alternative which does all of this in one feature by cryptographically signing pointers in memory.

admax88qqq 3y ago
Jesus. The amount of engineering that has to happen to protect against C is astounding.
- wahern 3y ago
  Protecting JIT-compiled code, e.g. within browsers, is at least as important a concern. Some would argue much more important, especially as usage of services like Cloudflare Workers increases. Techniques like CHERI could replace MMUs in some environments, potentially improving performance.
  - admax88qqq 3y ago
    There's no way to express an out of bounds memory read/write in JavaScript. So you don't actually need an MMU, or CHERI, or pointer signing, or any of the stack smashing mitigations put in place for C. You do have to generate correct code but that's actually a solvable problem, web assembly did it. In theory this could unlock tons of performance (and free up some silicon) if we could ever get the rest of the system away from C
    - deleted 3y ago
      [deleted]
dwattttt 3y ago
CET is both Indirect Branch Tracking and Shadow Stacks; IBT is the coarse towards CFI, but SSs are a direct ROP mitigation, but enforcing that any address returned to must have been CALL'd from.