8 ms·

The NX bit is not just about security

106 points by torutofu 12d ago

tripdout 10d ago
I really wish I understood this, it hits a bunch of topics that I've heard of and are/sound interesting, but I don't know enough to follow it. I don't get the link between the NX bit (which I get) and speculative access.
- zephen 10d ago
  In an attempt to go fast and beat benchmarks and other computers, CPUs attempt to speculatively execute code, and then later undo the results of the speculation if it turns out it was wrong. This causes all sorts of security issues (spectre, meltdown, and friends et al.) even when it's done relatively competently. When it's done incompetently as on this ARM implementation, then you can't even run perfectly good and correct code, because the CPU will attempt speculative execution on a location that you never asked it to execute code at, and then bork itself when it realizes that can't possibly work. Naturally, this is the sort of problem that requires tedious dissection of what exactly happened, and copious amounts of alcohol.
  - MBCook 10d ago
    So in this specific case, if I understood correctly, here’s what should happen: Interrupt(?) fires to trigger hypervisor, hypervisor figures out what it needs to do, jumps to that code, does its job, returns. The “figured out what it needs to do” is the issue right? So what was actually happening was: Same start… CPU predicts what hypervisor will do, speculatively loads instructions from mispredicted branch target, that wrong instruction reads memory(?) against the “no data prefetch” settings for that part of memory, CPU blows up/halts/whatever. The fix is to mark the area the branch was mispredicted to in such a way that the CPU won’t prefetch instructions. Thus that won’t be run and prefetch data, thus no violation. CPU execution continues taking the correct branch and everything is fine.
    - sleirsgoevy 9d ago
      No, that instruction does not read memory. That instruction is itself IN the inaccessible memory. It does not really matter how execution ended up in the HV in the first place. The misprediction happens due to having a branch-to-register instruction.
      - MBCook 9d ago
        Ah, thanks. So instruction loads also count as data loads?
        zephen 9d ago
        Well, that was the whole issue. After marking the memory as not accessible via a data load, the CPU was still executing there and borking itself. He had to also mark the memory as inaccessible for code loads. Which, honestly is kinda stupid. Because nobody asked the processor to start executing there. It just took it upon itself to try to start executing there, later decided that was a bad thing, and then borked itself. People talk about how terrible x86 is, but honestly, one of the reasons that x86 won for decades was because of making things that programmers did that might be suboptimal still work, even if a bit slowly (misaligned data accesses, for example). ARM does that now for that specific case, but didn't before 2002. So there's an implementation tradeoff for whether you decide to spend transistors to reduce the number of sharp edges on the tool. Obviously ARM just doesn't give a shit about this particular sharp edge.
  - repiret 10d ago
    Speculative instruction fetches fetch code from "a location that you never asked it to execute code at" by design. If it already knew you asked it to execute code there, it wouldn't be speculative. The Armv8/9-A architecture reference manual is clear that speculative instruction fetches are permitted in Device memory unless that memory is also marked NX. So if your hardware has side-effects from a certain address, but it maps it as Device non-NX memory, then your code is not "perfectly good and correct". Assigning correct memory attributes is one of the many things needed for correct code.
    - zephen 9d ago
      > Speculative instruction fetches fetch code from "a location that you never asked it to execute code at" by design. If it already knew you asked it to execute code there, it wouldn't be speculative. Sure, but (a) the speculation is supposed to be transparent; and (b) ARM's response to a failure in speculative execution is arguably broken. > The Armv8/9-A architecture reference manual Sure, but before then marking memory as not readable would make it non-executable, and also mostly before then there was no or minimal speculation. > then your code is not "perfectly good and correct". Certainly it won't work on that machine. It might have worked perfectly well on prior machines, and we could argue all day about how reasonable ARM's implementation decisions were, but I will merely say that a documented flaw is, in fact, still a flaw.
- RiverCrochet 10d ago
  Basically, the NX bit prevents CPU behavior (speculative fetches) that had a hand in Spectre-type vulnerabilities. That's surprising because that's not its purpose. This is for ARM CPUs.
  - jnwatson 10d ago
    No, NX precedes Spectre by a long shot. It was originally intended so an attacker couldn't use a buffer overflow to change the PC and execute directly out of the attacker-controlled buffer.
    - adrian_b 10d ago
      That is exactly what the poster to whom you replied said. So Arm did not add another means to disable this kind of speculative execution, after Spectre was discovered, but they just reused the existing NX flag, expanding its functionality.
      - samus 9d ago
        That poster wrote about speculative vulnerabilities. But buffer overflows have nothing to do with those.
- Nail2680 10d ago
  NX means not executable, so some bytes are excutable, some are non excutable. so some are instructions for the processor and others are data. Sometimes those are mixed and the cpu pukes out a bunch and restarts interpretation. most of the time those are normal. keep it normal and go fast.
Nail2680 10d ago
Hot take: NX bit is shit W^X is shit. proper JIT is having objects written as needed, and cache line flushing is full bullshit, we need self modifying code as a first class citizen and with modern techiques we can have it work and not be crazy slow, it is currently cuz shits fucked, but we can do better.
- RiverCrochet 10d ago
  L take. RAM is too slow for self-modifying code to be anywhere but F tier. This isn't 6502 land.
  - Nail2680 10d ago
    But it could be, there are bits about doing computation in RAM, self modifying code could work.
    - RiverCrochet 9d ago
      If DRAM gets the ability to modify itself (computations), it doesn't eliminate the cache layer between the CPU and DRAM. For the CPU to see updated DRAM values it has to bring in the DRAM to cache. Now, if that's a large amount of data, like 1MByte of computations, it's worth it, but for a couple of source/destination addresses in code, probably not. There's also the fact instruction and data caches are separate. Now, if the RAM in the CPU cache gets computational ability as well, that all changes, but not sure really that would be better than SIMD/SEE/AVX stuff or expanding what can be done with the new tile registers Intel's rolling out.
- Nail2680 10d ago
  Well it was a hot take.
  - eqvinox 10d ago
    Are you unaware that you can write code to RW memory, remap it to RX and then run it? That's how all JIT works these days. (Or did you confuse cache flushing with TLB flushing? The remap does the latter, not the former.)
crazy1_ 10d ago
this is so amazing
asveikau 10d ago
On this theme of it not being just about security: if you have a bug like a use after free and it happens to cover a function pointer, the nx bit can ensure that when you follow that pointer through a call, you get a clean trap as close to the failure point as possible. If it blindly executed stale bytes as code, maybe the crash and stack trace doesn't look as nice. But then, a lot of correctness bugs like that are also security problems.
- sleirsgoevy 9d ago
  I don't even have a real heap there, only a primitive 1-page allocator for pagetables.
mubbicles 10d ago
I appreciated this article. I've asked our CSP guy the difference, but this helps me better understand device vs ns. I also appreciate that this doesn't appear AI written.
eqvinox 10d ago
Honestly feels like a misdesign in ARM. Where does it ever make sense for Device memory to not be data prefetchable, but allow instruction prefetch? It should IMHO disable all prefetch…
- achierius 10d ago
  (Total guess) this feels like an attempt at restricting what parts of the hardware pipeline need to know what; if prefetches need to key off of both the device bit and the nx bit, then both of those need to be piped into the frontend, whereas if device is only relevant for data prefetches then only the nx bit needs to be available there (while device would be piped into the backend where the data prefetcher lives).
  - adrian_b 10d ago
    Not really. To the front end, one needs to pipe only appropriate logical combinations of the flags that describe the memory properties, not the flags as they are stored in some control register. So a control register should contain flags that are meaningful for the programmer, while the kind of flags that hardware happens to need can be generated with a few logic gates from them and routed through hardware wherever they are needed. It makes more sense to classify the memory in a few types, which must be specified by the programmer, including a "device memory" a.k.a. "memory-mapped peripherals" type, instead of having to specify for each memory area a long set of attributes about each kind of access that may be allowed, or not. This is how it is done in x86-64.
    - sleirsgoevy 9d ago
      x86_64 seems not to care much. I've had a UART mapped as normal memory, and it somehow still worked.
      - adrian_b 9d ago
        Did you really map it as normal memory? Standard UARTs are accessed in the x86 I/O space, which is uncacheable and strongly ordered, not in the normal memory space. Non-standard UARTs that are on PCIe add-on cards might be mapped into memory, but when the computer boots, the BIOS already maps the PCIe memory as uncacheable, with the Memory Type Range Registers. So if you do nothing, you get uncacheable memory for your UART, as you should. To map the UART in normal memory, i.e. write-back cacheable, you must do this explicitly in the UART device driver, either by allocating a dedicated MTRR for it, or more likely, by locking a memory page for it in the virtual address translation tables and using the PAT bits to set the memory type (Page Attribute Table). If you really mapped the UART as normal memory, i.e. write-back cacheable, it can work correctly only if you are incredibly lucky, because the writes to the UART control registers will not happen when you do them in your program, so I do not believe that you did that. With normal memory, not only you cannot predict when the UART registers will be written, but if you do multiple writes to the same register, all but the last will be omitted, so there is no way for the UART to work correctly. On x86-64, any memory-mapped peripheral must be mapped into uncacheable memory, except for memory banks that are located on PCIe cards, like the GPU memories, which should be mapped as write-combining memory.
dmitrygr 10d ago
This is doubly weird because actually purposefully executing from device memory is not allowed: “Trying to execute code from a region marked as Device is UNPREDICTABLE.” So: can’t reliably execute from there but can speculatively instruction fetch from there. Funsies! https://support.arm.com/documentation/100941/0101/Memory-types https://support.arm.com/documentation/100941/0101/Memory-typ...
achierius 10d ago
> while ARM does provide a reference implementation of the architecture, vendors are free to customize it at will, or even roll their own implementations A nitpick, but this is only true for some vendors, depending on their license, and is very much company-by-company. Many vendors, even big names like Meta, don't have the ability to roll their own. And even for the ones who do, 'customize at will' is a bit strong, as ARM very much does want to maintain uniformity across userspace implementations. E.g. Nvidia shouldn't add new traps for architecturally-legal behavior, since then code compiled for Apple hardware wouldn't work on Grace. Or worse, not trap for architecturally-illegal behavior, since then code compiled for Grace might not work for anyone else at all!
- adrian_b 10d ago
  TFA contains a reference to the Linux kernel, where there is a workaround for a quirk in the Apple CPUs, where in hypervisor mode they diverge from the official Aarch64 specification. So by "vendors" it was indeed meant "some vendors" who can afford to not care much about compatibility with the specification.
  - achierius 10d ago
    Unfortunately I can't comment much on Apple's situation since I work there :) Regardless what I mean to convey is that ARM would prefer such deviations to be rare, and especially for them to not be visible from userspace. Deviations will always exist if only due to hardware bugs, so contracts can only do so much.
  - my123 10d ago
    It's an old comment. iirc it's a documented feature now - FEAT_E2H0, https://support.arm.com/documentation/109697/2025_12/Feature-descriptions/The-Armv8-1-architecture-extension?lang=en https://support.arm.com/documentation/109697/2025_12/Feature... And it was retroactively defined to be allowed starting from Armv8.0. Apple designs pre-date the ID register bit for it being a thing so it takes a quirk there however.
    - 9d ago
repiret 10d ago
"Speculative instruction fetch to device memory crashes device" is in my list of favorite bugs ever found. I had ran into it on a Cortex-M4 without an MPU, so I couldn't even fix the memory attributes, the only solution was to gerrymander the compiled code to prevent the speculative fetch. It's crazy that Armv8/9-A permits speculative instruction fetches to device memory. Crazy enough that I had to look it up to believe it: "Hardware does not prevent speculative instruction fetches from a memory location with any of the Device memory attributes unless the memory location is also marked as execute-never for all Exception levels." - ARM DDI 0487K.a § B2.15.2 The Armv7-M spec is less clear. It does say: "The architecture does not permit speculative accesses to memory marked as Device," in contrast to Armv8/9-A which qualifies a similar statement with "data accesses". But then it later says "To ensure correctness, read-sensitive locations must be marked as non-executable". (This is all from ARM DDI 0403E.e § A3.5.7) I don't have v7-A older handy to compare what they say.
yuxinking 9d ago
[dead]
anyfoo 9d ago
Nowadays, it's considered bad form to map anything at 0... you now know one of the reasons why! In the case that I know that has a 1:1 identity mapping of the address space, the physical address space doesn't actually have anything at 0 either, so it still doesn't need to be mapped.
- sleirsgoevy 9d ago
  Post author here. I wanted the code to be "as generic as possible", so I had to accept the possibility of some useful thing being at address 0.
  - ValdikSS 8d ago
    I wrote an 'unlocking exploit' as a kernel module some years ago, and obfuscated it with a bit of self-modifying code. It could not make it work reliable. No matter which barries I set, I could not understand why is it not reliable, and had to remove the modifying code in the end. I guess I hit the issue you've described, and now I know. Thanks!

106 points by torutofu 12d ago

I really wish I understood this, it hits a bunch of topics that I've heard of and are/sound interesting, but I don't know enough to follow it. I don't get the link between the NX bit (which I get) and speculative access.

zephen 10d ago
In an attempt to go fast and beat benchmarks and other computers, CPUs attempt to speculatively execute code, and then later undo the results of the speculation if it turns out it was wrong. This causes all sorts of security issues (spectre, meltdown, and friends et al.) even when it's done relatively competently. When it's done incompetently as on this ARM implementation, then you can't even run perfectly good and correct code, because the CPU will attempt speculative execution on a location that you never asked it to execute code at, and then bork itself when it realizes that can't possibly work. Naturally, this is the sort of problem that requires tedious dissection of what exactly happened, and copious amounts of alcohol.
- MBCook 10d ago
  So in this specific case, if I understood correctly, here’s what should happen: Interrupt(?) fires to trigger hypervisor, hypervisor figures out what it needs to do, jumps to that code, does its job, returns. The “figured out what it needs to do” is the issue right? So what was actually happening was: Same start… CPU predicts what hypervisor will do, speculatively loads instructions from mispredicted branch target, that wrong instruction reads memory(?) against the “no data prefetch” settings for that part of memory, CPU blows up/halts/whatever. The fix is to mark the area the branch was mispredicted to in such a way that the CPU won’t prefetch instructions. Thus that won’t be run and prefetch data, thus no violation. CPU execution continues taking the correct branch and everything is fine.
  - sleirsgoevy 9d ago
    No, that instruction does not read memory. That instruction is itself IN the inaccessible memory. It does not really matter how execution ended up in the HV in the first place. The misprediction happens due to having a branch-to-register instruction.
    - MBCook 9d ago
      Ah, thanks. So instruction loads also count as data loads?
      - zephen 9d ago
        Well, that was the whole issue. After marking the memory as not accessible via a data load, the CPU was still executing there and borking itself. He had to also mark the memory as inaccessible for code loads. Which, honestly is kinda stupid. Because nobody asked the processor to start executing there. It just took it upon itself to try to start executing there, later decided that was a bad thing, and then borked itself. People talk about how terrible x86 is, but honestly, one of the reasons that x86 won for decades was because of making things that programmers did that might be suboptimal still work, even if a bit slowly (misaligned data accesses, for example). ARM does that now for that specific case, but didn't before 2002. So there's an implementation tradeoff for whether you decide to spend transistors to reduce the number of sharp edges on the tool. Obviously ARM just doesn't give a shit about this particular sharp edge.
- repiret 10d ago
  Speculative instruction fetches fetch code from "a location that you never asked it to execute code at" by design. If it already knew you asked it to execute code there, it wouldn't be speculative. The Armv8/9-A architecture reference manual is clear that speculative instruction fetches are permitted in Device memory unless that memory is also marked NX. So if your hardware has side-effects from a certain address, but it maps it as Device non-NX memory, then your code is not "perfectly good and correct". Assigning correct memory attributes is one of the many things needed for correct code.
  - zephen 9d ago
    > Speculative instruction fetches fetch code from "a location that you never asked it to execute code at" by design. If it already knew you asked it to execute code there, it wouldn't be speculative. Sure, but (a) the speculation is supposed to be transparent; and (b) ARM's response to a failure in speculative execution is arguably broken. > The Armv8/9-A architecture reference manual Sure, but before then marking memory as not readable would make it non-executable, and also mostly before then there was no or minimal speculation. > then your code is not "perfectly good and correct". Certainly it won't work on that machine. It might have worked perfectly well on prior machines, and we could argue all day about how reasonable ARM's implementation decisions were, but I will merely say that a documented flaw is, in fact, still a flaw.
RiverCrochet 10d ago
Basically, the NX bit prevents CPU behavior (speculative fetches) that had a hand in Spectre-type vulnerabilities. That's surprising because that's not its purpose. This is for ARM CPUs.
- jnwatson 10d ago
  No, NX precedes Spectre by a long shot. It was originally intended so an attacker couldn't use a buffer overflow to change the PC and execute directly out of the attacker-controlled buffer.
  - adrian_b 10d ago
    That is exactly what the poster to whom you replied said. So Arm did not add another means to disable this kind of speculative execution, after Spectre was discovered, but they just reused the existing NX flag, expanding its functionality.
    - samus 9d ago
      That poster wrote about speculative vulnerabilities. But buffer overflows have nothing to do with those.
Nail2680 10d ago
NX means not executable, so some bytes are excutable, some are non excutable. so some are instructions for the processor and others are data. Sometimes those are mixed and the cpu pukes out a bunch and restarts interpretation. most of the time those are normal. keep it normal and go fast.

Nail2680 10d ago

Hot take: NX bit is shit W^X is shit. proper JIT is having objects written as needed, and cache line flushing is full bullshit, we need self modifying code as a first class citizen and with modern techiques we can have it work and not be crazy slow, it is currently cuz shits fucked, but we can do better.

RiverCrochet 10d ago
L take. RAM is too slow for self-modifying code to be anywhere but F tier. This isn't 6502 land.
- Nail2680 10d ago
  But it could be, there are bits about doing computation in RAM, self modifying code could work.
  - RiverCrochet 9d ago
    If DRAM gets the ability to modify itself (computations), it doesn't eliminate the cache layer between the CPU and DRAM. For the CPU to see updated DRAM values it has to bring in the DRAM to cache. Now, if that's a large amount of data, like 1MByte of computations, it's worth it, but for a couple of source/destination addresses in code, probably not. There's also the fact instruction and data caches are separate. Now, if the RAM in the CPU cache gets computational ability as well, that all changes, but not sure really that would be better than SIMD/SEE/AVX stuff or expanding what can be done with the new tile registers Intel's rolling out.
Nail2680 10d ago
Well it was a hot take.
- eqvinox 10d ago
  Are you unaware that you can write code to RW memory, remap it to RX and then run it? That's how all JIT works these days. (Or did you confuse cache flushing with TLB flushing? The remap does the latter, not the former.)

crazy1_ 10d ago

this is so amazing

asveikau 10d ago

On this theme of it not being just about security: if you have a bug like a use after free and it happens to cover a function pointer, the nx bit can ensure that when you follow that pointer through a call, you get a clean trap as close to the failure point as possible. If it blindly executed stale bytes as code, maybe the crash and stack trace doesn't look as nice. But then, a lot of correctness bugs like that are also security problems.

sleirsgoevy 9d ago
I don't even have a real heap there, only a primitive 1-page allocator for pagetables.

mubbicles 10d ago

I appreciated this article. I've asked our CSP guy the difference, but this helps me better understand device vs ns. I also appreciate that this doesn't appear AI written.

eqvinox 10d ago

Honestly feels like a misdesign in ARM. Where does it ever make sense for Device memory to not be data prefetchable, but allow instruction prefetch? It should IMHO disable all prefetch…

achierius 10d ago
(Total guess) this feels like an attempt at restricting what parts of the hardware pipeline need to know what; if prefetches need to key off of both the device bit and the nx bit, then both of those need to be piped into the frontend, whereas if device is only relevant for data prefetches then only the nx bit needs to be available there (while device would be piped into the backend where the data prefetcher lives).
- adrian_b 10d ago
  Not really. To the front end, one needs to pipe only appropriate logical combinations of the flags that describe the memory properties, not the flags as they are stored in some control register. So a control register should contain flags that are meaningful for the programmer, while the kind of flags that hardware happens to need can be generated with a few logic gates from them and routed through hardware wherever they are needed. It makes more sense to classify the memory in a few types, which must be specified by the programmer, including a "device memory" a.k.a. "memory-mapped peripherals" type, instead of having to specify for each memory area a long set of attributes about each kind of access that may be allowed, or not. This is how it is done in x86-64.
  - sleirsgoevy 9d ago
    x86_64 seems not to care much. I've had a UART mapped as normal memory, and it somehow still worked.
    - adrian_b 9d ago
      Did you really map it as normal memory? Standard UARTs are accessed in the x86 I/O space, which is uncacheable and strongly ordered, not in the normal memory space. Non-standard UARTs that are on PCIe add-on cards might be mapped into memory, but when the computer boots, the BIOS already maps the PCIe memory as uncacheable, with the Memory Type Range Registers. So if you do nothing, you get uncacheable memory for your UART, as you should. To map the UART in normal memory, i.e. write-back cacheable, you must do this explicitly in the UART device driver, either by allocating a dedicated MTRR for it, or more likely, by locking a memory page for it in the virtual address translation tables and using the PAT bits to set the memory type (Page Attribute Table). If you really mapped the UART as normal memory, i.e. write-back cacheable, it can work correctly only if you are incredibly lucky, because the writes to the UART control registers will not happen when you do them in your program, so I do not believe that you did that. With normal memory, not only you cannot predict when the UART registers will be written, but if you do multiple writes to the same register, all but the last will be omitted, so there is no way for the UART to work correctly. On x86-64, any memory-mapped peripheral must be mapped into uncacheable memory, except for memory banks that are located on PCIe cards, like the GPU memories, which should be mapped as write-combining memory.

dmitrygr 10d ago

This is doubly weird because actually purposefully executing from device memory is not allowed: “Trying to execute code from a region marked as Device is UNPREDICTABLE.” So: can’t reliably execute from there but can speculatively instruction fetch from there. Funsies! https://support.arm.com/documentation/100941/0101/Memory-types https://support.arm.com/documentation/100941/0101/Memory-typ...

achierius 10d ago

> while ARM does provide a reference implementation of the architecture, vendors are free to customize it at will, or even roll their own implementations A nitpick, but this is only true for some vendors, depending on their license, and is very much company-by-company. Many vendors, even big names like Meta, don't have the ability to roll their own. And even for the ones who do, 'customize at will' is a bit strong, as ARM very much does want to maintain uniformity across userspace implementations. E.g. Nvidia shouldn't add new traps for architecturally-legal behavior, since then code compiled for Apple hardware wouldn't work on Grace. Or worse, not trap for architecturally-illegal behavior, since then code compiled for Grace might not work for anyone else at all!

adrian_b 10d ago
TFA contains a reference to the Linux kernel, where there is a workaround for a quirk in the Apple CPUs, where in hypervisor mode they diverge from the official Aarch64 specification. So by "vendors" it was indeed meant "some vendors" who can afford to not care much about compatibility with the specification.
- achierius 10d ago
  Unfortunately I can't comment much on Apple's situation since I work there :) Regardless what I mean to convey is that ARM would prefer such deviations to be rare, and especially for them to not be visible from userspace. Deviations will always exist if only due to hardware bugs, so contracts can only do so much.
- my123 10d ago
  It's an old comment. iirc it's a documented feature now - FEAT_E2H0, https://support.arm.com/documentation/109697/2025_12/Feature-descriptions/The-Armv8-1-architecture-extension?lang=en https://support.arm.com/documentation/109697/2025_12/Feature... And it was retroactively defined to be allowed starting from Armv8.0. Apple designs pre-date the ID register bit for it being a thing so it takes a quirk there however.
  - 9d ago

repiret 10d ago

"Speculative instruction fetch to device memory crashes device" is in my list of favorite bugs ever found. I had ran into it on a Cortex-M4 without an MPU, so I couldn't even fix the memory attributes, the only solution was to gerrymander the compiled code to prevent the speculative fetch. It's crazy that Armv8/9-A permits speculative instruction fetches to device memory. Crazy enough that I had to look it up to believe it: "Hardware does not prevent speculative instruction fetches from a memory location with any of the Device memory attributes unless the memory location is also marked as execute-never for all Exception levels." - ARM DDI 0487K.a § B2.15.2 The Armv7-M spec is less clear. It does say: "The architecture does not permit speculative accesses to memory marked as Device," in contrast to Armv8/9-A which qualifies a similar statement with "data accesses". But then it later says "To ensure correctness, read-sensitive locations must be marked as non-executable". (This is all from ARM DDI 0403E.e § A3.5.7) I don't have v7-A older handy to compare what they say.

yuxinking 9d ago

[dead]

anyfoo 9d ago

Nowadays, it's considered bad form to map anything at 0... you now know one of the reasons why! In the case that I know that has a 1:1 identity mapping of the address space, the physical address space doesn't actually have anything at 0 either, so it still doesn't need to be mapped.

sleirsgoevy 9d ago
Post author here. I wanted the code to be "as generic as possible", so I had to accept the possibility of some useful thing being at address 0.
- ValdikSS 8d ago
  I wrote an 'unlocking exploit' as a kernel module some years ago, and obfuscated it with a bit of self-modifying code. It could not make it work reliable. No matter which barries I set, I could not understand why is it not reliable, and had to remove the modifying code in the end. I guess I hit the issue you've described, and now I know. Thanks!