by csense on 8/17/25, 3:42 PM with 56 comments
by JdeBP on 8/21/25, 9:45 AM
This was put into OpenBSD back in 2017. It's not "trap instructions". It's "trapsleds". The idea is to trap the sleds (a.k.a. slides) of NOP instructions that linkers used to put in between compiled code for alignment, and which could be exploited with "return-oriented programming" where an attacker could cause execution to jump to any address in the padding range (possibly needing the inexactitude because of constraints upon byte substitutions) and slide along all of the NOPs to the target function.
* https://undeadly.org/cgi?action=article;sid=20170622065629
by Normal_gaussian on 8/21/25, 9:35 AM
I definitely wouldn't have got this far looking at this - I'd have quickly assumed it was a sentinel value being used for padding and moved on with my day. Good work.
by colanderman on 8/21/25, 11:27 AM
Being ARM32, these should be BKPT (hex BExx). [2]
[1] https://developer.arm.com/documentation/ddi0602/2025-06/Base...
[2] https://developer.arm.com/documentation/ddi0597/2024-09/Base...
by nneonneo on 8/21/25, 11:32 PM
0x0000000000000000: D4 D4 D4 D4 ldrble sp, [r4], #0x4d4
This is "load byte at [r4 + 0x4d4] into sp, then add 0x4d4 to r4, but only if the condition flags signal a comparison result of less-than-or-equal". It is unlikely to be a useful instruction, since it causes the stack pointer register SP to be less than 0x100 (if [r4+0x4d4] is even a valid address), but it sure as heck isn't a trap. And, if the condition flags are right, this is just a NOP instruction.
As far as I can tell, 0xd4d4d4d4 is only invalid on AArch64, and only because it happens to not yet be a defined instruction. 0xd4 does in fact introduce an exception generation instruction, but 0xd4d4xxxx is invalid as it is an unallocated combination of bits. However, nothing prevents this from being a defined instruction in the future, which makes 0xd4d4d4d4 a really bad choice as it could turn out to be a valid instruction in the future that performs an unexpected operation.
In all, 0xd4 looks like a terrible choice for a padding byte for any ARM architecture, so it's a real mystery why this specific choice was made.
by Arnavion on 8/21/25, 10:18 PM
by skrebbel on 8/21/25, 9:43 AM
> [This patch] fills holes in executable sections with 0xd4 (ARM) or 0xef (MIPS). These trap instructions were suggested by Theo de Raadt.
into commit messages, but not in the code. What's the cost? What's the downside to having a 2 to 3 line comment above a constant in a C file? Why pretend like all this is super obvious when clearly it isn't?
There seems to be some unwritten cultural rule, particularly in FOSS land, that you're supposed to write code as if you're an all-knowing oracle, as if everything is obvious, and so comments are for losers (as are descriptive variable names). I simply can't understand how and why that developed.
by EDEADLINK on 8/21/25, 2:30 PM
This saves us from selecting between BRK and BKPT.
I have not found a single sequence of bytes that would work on thumb, armv7 and AARCH64.
by davedx on 8/21/25, 9:25 AM
by rokkamokka on 8/21/25, 9:16 AM
by thayne on 8/22/25, 12:16 AM
by nokeya on 8/21/25, 9:18 AM
by rasz on 8/21/25, 9:20 AM
by chaboud on 8/21/25, 9:32 AM
(Unless someone stays up all night to find the bugs....)
by k33n on 8/21/25, 10:30 AM
by mprovost on 8/21/25, 6:25 PM