It's not exploitable. It's an exploit mitigation, in fact. It's not a bug; it's intentional that it works this way. And Nathan Michaels didn't think that if you want to find Theo de Raadt writing on some subject, better try OpenBSD discussion fora, not the LLVM mailing list. (-:
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.
The instructions have to be trap instructions for it to work.
The conditional branch-backward instruction it is is almost as bad as the series of NOPs, since it is still likely to redirect an attacker to functioning code. (If the attacker can clear the mi flag first, these are just NOPs!)
Hence yes, this is a broken exploit mitigation.
JdeBP 3 hours ago [-]
And this is where the OpenBSD people will paraphrase Henry Spencer and say that those who do not understand OpenBSD are doomed to reinvent it badly. (Personally, I think that that's putting OpenBSD onto a pedestal. It's no ideal; one gets the same tradeoffs and problems as everywhere else.) In this case, the reinvention for LLVM targetting ARM, that credits seeing this committed to OpenBSD by Theo de Raadt, totally ignored that the original for gas targetting x86 both trapped and jumped.
I intentionally also pointed you to a collection of several critiques of the whole idea, long-since made. (-:
colanderman 2 hours ago [-]
Why, in your own words, is the jump supposed to be there? (Keep in mind this code is in between two functions.)
And why, in your own words, is it OK for the jump to be a conditional backwards jump?
2 hours ago [-]
tourist2d 2 hours ago [-]
[dead]
Dylan16807 4 hours ago [-]
> It's not exploitable.
The article doesn't say it is.
> It's an exploit mitigation, in fact.
The article made that clear.
> It's not a bug; it's intentional that it works this way.
What is "this way"? Trap or jump? If you're saying a jump is supposed to count as a trap, it's a pretty bad one. It still allows a lot of jumps to the padding to continue and execute valuable code.
JdeBP 3 hours ago [-]
[flagged]
Dylan16807 3 hours ago [-]
It says why it jumps over nops in the middle of a function. No explanation for jumping backwards at the end of a function.
And it replaces the nops with int3. Not another jump. This code keeps stacking d4.
MayeulC 3 hours ago [-]
Putting instructions that halt execution in unreachable parts of the code would make sense, but this is just a jump with a fixed offset, which may technically still be exploitable.
If trap instructions are not possible, I would at least try to make it an unconditional jump to create an infinite loop.
Aurornis 39 minutes ago [-]
> It's not exploitable. It's an exploit mitigation, in fact. It's not a bug; it's intentional that it works this way.
If the instructions are branching instead of trapping (as explained in the article) then it would be exploitable as a ROP gadget and it would be a bug.
vintagedave 4 hours ago [-]
The article states that on ARM Thumb, the instruction meant to be interpreted as a trap does not trap but jumps, instead.
JdeBP 3 hours ago [-]
Welcome to a world where people copy ideas from OpenBSD and miss parts of them. If you believe some OpenBSD people, this happens all the time. (-:
Don't get them talking, for starters, about the flag files problems that people have introduced to doas, for example, because they didn't copy the OpenBSD kernel feature that original doas relies upon. Or you'll invoke the spirit of Ted Unangst.
Here, they've missed the clear explanation in the original of how and why it both traps and jumps. (And what caution made them add the jump, even though Microsoft had prior to that time been doing the trap-only version for years.)
colanderman 3 hours ago [-]
You are misunderstanding the purpose of the initial jump in a trap sled. It is to redirect code which expects to flow through the sled past the traps, while leaving the traps for anything else which lands in that range.
The padding the article is talking about lives between functions. It is not meant to be executed, nothing is needed to jump over it. (The unconditional bx lr before it is the return at the end of the function.)
JdeBP 2 hours ago [-]
I'm not misunderstanding it. Quite the contrary. I've not written the straw man words that you have just tried to put into my mouth, or said anything other than look to Todd Mortimer's own explanation for this. The actual misunderstanding is yours. You've not read Todd Mortimer's and Theo de Raadt's explanations of the OpenBSD original being for both scenarios, and their not knowing of a way to distinguish them in gcc at the point where they are placing the patch.
And you also haven't spotted, even though Nathan Michaels called it out, that the LLVM version is from someone who either read what Theo de Raadt wrote in the commit or read Todd Mortimer's account of the BSDCan conversation, and copied the idea from GCC for x86 into LLVM for ARM. Rui Ueyama, like you, didn't absorb all of the original explanation, however, otherwise xe would have caught why Todd Mortimer didn't originally do the Microsoft-style string of all-the-same instructions that Rui Ueyama then did.
colanderman 2 hours ago [-]
From your own link:
> The trapsleds implemented in this diff convert NOP sleds longer than 2 bytes from a series of 0x66666690 instructions to a 2 byte short JMP over a series of INT3 instructions that fill the rest of the gap.
The BMI instructions in the article are not jumping over breakpoint (INT3) instructions. They're conditionally jumping backwards by some amount.
Why in your belief is this? Please use your own words or a relevant direct quote to state your understanding of how a trapsled works.
tourist2d 2 hours ago [-]
[dead]
quantumwoke 31 minutes ago [-]
Your second link suggests that this mitigation is not very helpful these days. I suppose in that light it doesn't really matter if LLVM changes it to a trap instruction or not.
4 hours ago [-]
Normal_gaussian 5 hours ago [-]
This is cool; and yes, fairly clearly a bug with the commit showing both the name (trap instruction) and INT3 (debug) being used for x86.
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.
colanderman 3 hours ago [-]
Hex D4xxxxxx is indeed (almost) BRK... on ARM64 [1].
Cool story! If I may rant off topic a bit though, it boggles my mind that people put stuff like this:
> [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.
lionkor 4 hours ago [-]
I really like putting context into commits, not into code comments. The reasoning is pretty simple: Comments aren't checked. I might write "This is done this way because John Doe suggested it, it's much more efficient this way", and then someone else changes the code to be buggy, wrong, and slow. Now, the comment is explaining behavior that is no longer there, and wrongly suggests that the code does/means something it doesn't.
Another argument is comments-as-noise, as I would call it. The more "unnecessary" comments you write, the more core developers (who write and read most of the code), will learn to ignore comments. Then, critical comments like "Be careful not to call this when XYZ isn't initialized yet, unless you don't mind ABC happening" are ignored, and ta-da! comments are now useless.
Commit messages are attached to specific changes. If I want to know why a line of code is the way it is, I can git blame it, and see which commit is to blame, together with issue numbers, authors, maybe reviewers, context, history, etc.
Should there be a comment briefly explaining this patch? Probably. But the commit message should add the other context.
Kwpolska 1 hours ago [-]
Git blame won't show you the history you care about if the line is changed in the future.
lionkor 29 minutes ago [-]
It does, you can use various parameters to go through the history of a line of code. And, usually, you only care about why it is the way it is.
ahofmann 4 hours ago [-]
But this works as intended? The code isn't cluttered with documentation, that doesn't necessarily makes sense when reading the code, but by reading the commit, one can understand why the code was written like that.
Dylan16807 3 hours ago [-]
Cluttered? A sentence describing a magic value is not clutter.
lintfordpickle 3 hours ago [-]
I'm not necessarily disagreeing with you (because apparently this is missing), but a descriptive constant/variable name would be even less clutter than even a 1-line comment
Ghoelian 4 hours ago [-]
A lot of developers think code should be self-documenting, which I fully agree with.
Unfortunately though I don't think I've ever worked on a project that was actually self-documented, even though that is what the leads wanted.
mananaysiempre 3 hours ago [-]
Huh? Quoting a bit more from the article:
> [W]e find this in ARM.cpp:
> trapInstr = {0xd4, 0xd4, 0xd4, 0xd4};
The only thing left to explain is that the trap instruction is used as padding, but you can’t tell from here if that’s obvious or not. Opening the actual code[1], we see that the occurrences of trapInstr are all along the lines of
> void ARM::writePlt( /* ... */ ) {
> /* ... */
> memcpy(buf + 12, trapInstr.data(), 4); // Pad to 16-byte boundary
which isn’t the absolute best, but seems clear enough (if of course you know what a PLT is, which you should if you’re writing a linker).
I do think this merits an explanation that we’re using (what’s intended to be) a trap because the traditional option of using a nop makes ASLR less effective. But then the commit message you’re quoting doesn’t mention that either.
I think it's a human thing. The Torah is succinct; The Talmud has a lot to say about it. For a large codebase, the comments would be huge, and also I think distracting.
In fact, as a former code auditor I can say that comments at times make bug finding harder -- they frame you up a certain way. I definitely preferred to audit without comments.
Anyway, there are definitely valid reasons. I think the commit log or dev notes files are generally preferable, especially when combined with good naming.
davedx 5 hours ago [-]
Sounds like this could cause some awful heisenbugs if the instruction was ever reached?
3 hours ago [-]
nokeya 5 hours ago [-]
May this be exploited?
pm215 5 hours ago [-]
If you can already subvert the flow of execution enough to jump somewhere you shouldn't be, you probably have better targets elsewhere in the binary than a conditional branch.
Aurornis 49 minutes ago [-]
A common exploit technique is to use what’s called “Return Oriented Programming” to jump to different locations throughout the file to trigger little “ROP gadget” instruction combos to accomplish what you need to do.
Normal_gaussian 4 hours ago [-]
Certainly true if you control the entire value; but if you can only flip a bit or two then this does provide a trampoline to increase the exploits range.
Probably more of a "stick it in the toolbox for automatic use" rather than building an exploit around it type of situation however.
JdeBP 4 hours ago [-]
You have almost, with that statement, figured out what this really is and why it is there.
Do you want obfuscated supply-chain state-actor vulnerabilities? Because this is how you get obfuscated supply-chain state-actor vulnerabilities!
(Unless someone stays up all night to find the bugs....)
rokkamokka 5 hours ago [-]
God I love blame for use cases like this
rasz 5 hours ago [-]
TLDR: Linker is kicking up the 4d3d3d3.
k33n 4 hours ago [-]
I think it’s just an artifact of objdump and not even real.
terminalbraid 3 hours ago [-]
How does someone reconcile your statement with the second part of the article where they find the LLVM source that's explicitly generating it with comments suggesting why?
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
* https://isopenbsdsecu.re/mitigations/trapsled/
The conditional branch-backward instruction it is is almost as bad as the series of NOPs, since it is still likely to redirect an attacker to functioning code. (If the attacker can clear the mi flag first, these are just NOPs!)
Hence yes, this is a broken exploit mitigation.
I intentionally also pointed you to a collection of several critiques of the whole idea, long-since made. (-:
And why, in your own words, is it OK for the jump to be a conditional backwards jump?
The article doesn't say it is.
> It's an exploit mitigation, in fact.
The article made that clear.
> It's not a bug; it's intentional that it works this way.
What is "this way"? Trap or jump? If you're saying a jump is supposed to count as a trap, it's a pretty bad one. It still allows a lot of jumps to the padding to continue and execute valuable code.
And it replaces the nops with int3. Not another jump. This code keeps stacking d4.
If trap instructions are not possible, I would at least try to make it an unconditional jump to create an infinite loop.
If the instructions are branching instead of trapping (as explained in the article) then it would be exploitable as a ROP gadget and it would be a bug.
Don't get them talking, for starters, about the flag files problems that people have introduced to doas, for example, because they didn't copy the OpenBSD kernel feature that original doas relies upon. Or you'll invoke the spirit of Ted Unangst.
* https://news.ycombinator.com/item?id=37314526
Here, they've missed the clear explanation in the original of how and why it both traps and jumps. (And what caution made them add the jump, even though Microsoft had prior to that time been doing the trap-only version for years.)
The padding the article is talking about lives between functions. It is not meant to be executed, nothing is needed to jump over it. (The unconditional bx lr before it is the return at the end of the function.)
And you also haven't spotted, even though Nathan Michaels called it out, that the LLVM version is from someone who either read what Theo de Raadt wrote in the commit or read Todd Mortimer's account of the BSDCan conversation, and copied the idea from GCC for x86 into LLVM for ARM. Rui Ueyama, like you, didn't absorb all of the original explanation, however, otherwise xe would have caught why Todd Mortimer didn't originally do the Microsoft-style string of all-the-same instructions that Rui Ueyama then did.
> The trapsleds implemented in this diff convert NOP sleds longer than 2 bytes from a series of 0x66666690 instructions to a 2 byte short JMP over a series of INT3 instructions that fill the rest of the gap.
The BMI instructions in the article are not jumping over breakpoint (INT3) instructions. They're conditionally jumping backwards by some amount.
Why in your belief is this? Please use your own words or a relevant direct quote to state your understanding of how a trapsled works.
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.
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...
> [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.
Another argument is comments-as-noise, as I would call it. The more "unnecessary" comments you write, the more core developers (who write and read most of the code), will learn to ignore comments. Then, critical comments like "Be careful not to call this when XYZ isn't initialized yet, unless you don't mind ABC happening" are ignored, and ta-da! comments are now useless.
Commit messages are attached to specific changes. If I want to know why a line of code is the way it is, I can git blame it, and see which commit is to blame, together with issue numbers, authors, maybe reviewers, context, history, etc.
Should there be a comment briefly explaining this patch? Probably. But the commit message should add the other context.
> [W]e find this in ARM.cpp:
> trapInstr = {0xd4, 0xd4, 0xd4, 0xd4};
The only thing left to explain is that the trap instruction is used as padding, but you can’t tell from here if that’s obvious or not. Opening the actual code[1], we see that the occurrences of trapInstr are all along the lines of
> void ARM::writePlt( /* ... */ ) {
> /* ... */
> memcpy(buf + 12, trapInstr.data(), 4); // Pad to 16-byte boundary
which isn’t the absolute best, but seems clear enough (if of course you know what a PLT is, which you should if you’re writing a linker).
I do think this merits an explanation that we’re using (what’s intended to be) a trap because the traditional option of using a nop makes ASLR less effective. But then the commit message you’re quoting doesn’t mention that either.
[1] https://github.com/llvm/llvm-project/blob/b20c291baec94ba370...
In fact, as a former code auditor I can say that comments at times make bug finding harder -- they frame you up a certain way. I definitely preferred to audit without comments.
Anyway, there are definitely valid reasons. I think the commit log or dev notes files are generally preferable, especially when combined with good naming.
Probably more of a "stick it in the toolbox for automatic use" rather than building an exploit around it type of situation however.
* https://news.ycombinator.com/item?id=44970832
(Unless someone stays up all night to find the bugs....)