D4D4 | Hacker News Reader

D4D4

nmichaels.org

475 pointscsense56 comments

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.

* https://undeadly.org/cgi?action=article;sid=20170622065629

* https://isopenbsdsecu.re/mitigations/trapsled/

The article states that on ARM Thumb, the instruction meant to be interpreted as a trap does not trap but jumps, instead.

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

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.

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. (-:

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?

So now you're saying this is a bad reinvention?

Your first comment says "it's intentional that it works this way".

I think you're misunderstanding. 32 bit ARM has TWO instruction encodings. OpenBSD apparently only knows about one. In thumb encoding, the instruction is a branch, not a trap.

It can’t be a trap in regular ARM assembly, either, can it?

There, all instructions are 32 bits and D4D4 is only 16 bits.

It just fills the memory with 0xd4 bytes. That happens to be a trapping instruction if it's filling space between aligned 32-bit ARM instructions. It doesn't work to infill 16-bit holes in thumb instructions at all (i.e. it's not a trap), but when used for its intended purpose it presumably works fine.

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

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.

Yes yes, but it's only an exploit mitigation if the bytes encode a mitigating instruction. On 32 bit ARM, they do. In thumb mode[1], they don't. That's interesting enough to be worth a blog post.

[1] For those who don't realize: author is on a Cortex-M processor per the ISA Ref they cite. These devices support *only* thumb instructions. Although as of thumb2, the encoding is now variable-length and there are lots of not-at-all-orthogonal-with-big-ARM 32 bit variants too. It's... not really the same architecture at all, to be honest.

The discussions you linked to are about amd64, where 0xcc is indeed reliably a trap. The OP is about ARM, and it’s about 0xd4d4, not 0xcc.

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.

Hex D4xxxxxx is indeed (almost) BRK... on ARM64 [1].

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

I'm confused, because d4d4d4d4 doesn't look like a trap in 32-bit ARM either:

  0x0000000000000000:  D4 D4 D4 D4    ldrble sp, [r4], #0x4d4

(from https://shell-storm.org/online/Online-Assembler-and-Disassem...)

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.

Only tangentially related, but RISC-V intentionally makes any instruction starting with 0x0000 an illegal instruction instead of a NOP, for exactly the reason to prevent NOP-sleds. The official NOPs are 0x0001 (compressed 16-bit instruction) and 0x00000013 (regular 32-bit instruction; instructions are LE so 0x13 is the first byte in memory), both equivalent to addi x0, x0, 0, though many other instructions can act as NOPs by virtue of writing to the zero register.

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.

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.

It's also not always feasible. How would you write self documenting code that explained what the commit message did?

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.

Git blame won't show you the history you care about if the line is changed in the future.

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.

Maybe there should be a convention around comments which describe functionality, those which describe history, and I’m sure we can find other types of comments. Then we can have our editors hide certain types of comments based on what we want to see.

The issue is really that the comments' semantics aren't validated. That might be an AI startup idea; going through a codebase and linting comments.

I think this is saying there is a habit of updating code without reading and updating the comments associated with the code. I would argue the fix is to have people get in the habit of maintaining comments, as opposed to not writing any comments at all.

If people already have the habit of ignoring comments that are right there in the code, I am not sure they would spend the extra effort to go after commit history. Also, some commits might have originated from private repositories where commit history is not accessible, and the most context we get out of "git blame" might be "code was imported on this date".

It’d be nice if comments were always updated, but the reality of it is that they often aren’t.

Sometimes it’s because the later developer doesn’t think the comment needs to be fixed - maybe they tried to fix a bug in John Doe’s approach, accidentally introduced a new bug, but thought they didn’t touch the clever algorithm.

Sometimes it’s because the comment isn’t proximate to the code it refers to. For example, in the “XYZ initializer” case, maybe XYZ is changed down the line to remove the ABC behaviour, but the comment stays because it is attached to some faraway usage of XYZ.

Notes in commit messages don’t fix either of these problems, obviously. But, on the other hand, they obviously refer to a specific point in time, unlike comments, which makes it easier to figure out if the notes are still relevant or not.

You don't have any control over the people who touch the code after you so you cannot "fix" the risk that someone updates your code without the comment. You do have control over your own commit though.

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.

Cluttered? A sentence describing a magic value is not clutter.

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

A variable name that explains both what this is, and why that specific value was chosen would be a very long and cumbersom name. And would beed to be changed if the value was ever changed (to explain the new value).

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.

[1] https://github.com/llvm/llvm-project/blob/b20c291baec94ba370...

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.

> What's the downside to having a 2 to 3 line comment above a constant in a C file?

That the code gets changed in the future such that the comment is a lie[1]. This happens with shocking regularity. Comments sound like a great idea until you deal with them in a long term maintenance situation.

As a corrolary, they also increase the cost of maintenance because if you end up doing refactoring that makes the comments a lie, it's never acceptable in review to just remove them. People expect you to write the same kind of treatise that the original author did. And original authors are horrifyingly verbose. All those doxygen crumbs you're leaving only act to confuse and irritate the pour souls coming after you.

Code is code. It should explain itself. If it does not, comments should do the absolute minimum needed (c.f. citing the relevant section in the ISA reference by number in this case) to rectify that.

[1] c.f. Guy Steele: https://softwarequotes.com/quote/don-t-get-suckered-in-by-th...

Digging into this a bit the best mnenomic I have found for a trap on ARM is "udf #0" which works on all the arm's on godbolt (and with -mthumb).

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.

Sounds like this could cause some awful heisenbugs if the instruction was ever reached?

God I love blame for use cases like this

Why do the compilation units need to be padded if the functions don't need to be aligned.

I'm a pretty rusty on ARM asm but from what I remember the opcodes to efficiently load constants into registers are pretty inflexible so it's common to store larger constants inline with the code. I'm guessing you need to keep the code aligned to preserve the alignment of these constants.

May this be exploited?

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.

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.

You have almost, with that statement, figured out what this really is and why it is there.

* https://news.ycombinator.com/item?id=44970832

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.

TLDR: Linker is kicking up the 4d3d3d3.

Now Tayne I can get into!

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

I think it’s just an artifact of objdump and not even real.

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 reminds me of coding with AI where slightly changing the prompt gives you different code and you don't really understand why but you use it anyway. In this case it's not even the compiler that's adding the incorrect instructions - it's the linker. Someday we'll just trust the AI to spit out working code the same way we assume that the C toolchain produces reasonable assembler. And when it doesn't it's remarkable enough to warrant a blog post and HN discussion.

Reply on news.ycombinator.com