The NX bit is not just about security

The NX bit is not just about security

September 4, 2026

While I’m taking a short break from low-level programming, here’s a story by a friend of mine, Sonya, about debugging a seemingly impossible bug in ARM code.

This bug hunting saga started several months ago. While developing a bare-metal hypervisor on ARM64 for postmarketOS, I hit a strange bug: if I enabled the CTR_EL0 intercept (which was the whole purpose of the HV, so could not be skipped), the phone would randomly lock itself up. After a few seconds, the watchdog kicked in and reset the system. At first I thought that the boot got slowed down so much that the system simply did not have enough time to boot, but disabling the watchdog did not help either (fortunately, the phone in question had removable battery, and I didn’t have to wait several hours for it to discharge). So, I started digging deeper.

Hypothesis #1: My emulation of MRS is wrong

On Aarch64, so-called Special Function Registers (which CTR_EL0 is one of) are accessed using MRS and MSR machine instructions:

mrs x3 , ctr_el0 msr ctr_el0, x3

These instructions move data between the specified SFR and the specified general-purpose register (in this case, X3 ), with all other registers remaining unchanged. So the failure must have meant that I was either corrupting some of the registers I had to preserve, or not writing the real output register correctly. Thus the first two things I verified were the exception handler trampoline:

trap_from_el1: sub sp , sp , #256 stp x0 , x1 , [ sp ] stp x2 , x3 , [ sp , #16 ] stp x4 , x5 , [ sp , #32 ] stp x28 , x29 , [ sp , #224 ] stp x30 , xzr, [ sp , #240 ] mov x0 , sp bl handle_trap_from_el1 mrs x1 , elr_el2 add x0 , x0 , x1 msr elr_el2, x0 ldp x0 , x1 , [ sp ] ldp x2 , x3 , [ sp , #16 ] ldp x4 , x5 , [ sp , #32 ] ldp x28 , x29 , [ sp , #224 ] ldp x30 , xzr, [ sp , #240 ] add sp , sp , #256 eret

And the stack allocation:

... continue reading