New code for SIGILL faults to help identify misbranches on OpenBSD

Re:New code for SIGILL faults to help identify misbranches o... by wahern on Thursday February 22, 2024 @03:01PM (#39472295)

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/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.

[ Parent | on HN ]

Re:New code for SIGILL faults to help identify misbranches o... by brynet on Thursday February 22, 2024 @05:48PM (#39474421)

> 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

"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

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.

[ Parent | on HN ]

Re:New code for SIGILL faults to help identify misbranches o... by guenthert on Friday February 23, 2024 @03:56AM (#39478428)

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.

[ Parent | on HN ]

Re:New code for SIGILL faults to help identify misbranches o... by MuffinFlavored on Thursday February 22, 2024 @08:10PM (#39475618)

> 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%?

[ Parent | on HN ]

Re:New code for SIGILL faults to help identify misbranches o... by jeffbee on Thursday February 22, 2024 @08:35PM (#39475801)

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.

[ Parent | on HN ]

Re:New code for SIGILL faults to help identify misbranches o... by kevingadd on Thursday February 22, 2024 @08:41PM (#39475849)

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.

[ Parent | on HN ]

Re:New code for SIGILL faults to help identify misbranches o... by sweetjuly on Thursday February 22, 2024 @09:16PM (#39476127)

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.

[ Parent | on HN ]

Re:New code for SIGILL faults to help identify misbranches o... by admax88qqq on Thursday February 22, 2024 @09:19PM (#39476149)

Jesus. The amount of engineering that has to happen to protect against C is astounding.

[ Parent | on HN ]

Re:New code for SIGILL faults to help identify misbranches o... by wahern on Thursday February 22, 2024 @10:47PM (#39476715)

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.

[ Parent | on HN ]

Re:New code for SIGILL faults to help identify misbranches o... by admax88qqq on Monday February 26, 2024 @12:21PM (#39514027)

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

[ Parent | on HN ]

Re:New code for SIGILL faults to help identify misbranches o... by dwattttt on Friday February 23, 2024 @04:24AM (#39478612)

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.

[ Parent | on HN ]