I understand that each instruction should be read into CPU for execution, which probably is the reason why code pages should be "r-x".

But my observation is that the behavior of reading code into CPU for execution is normal, while reading code into another memory space (e.g., copying the code into a generic-purpose register) is quite suspicious. One example is it benefits "Just-in-time code reuse for bypassing ASLR" (http://www.ieee-security.org/TC/SP2013/papers/4977a574.pdf), and I believe it can be used by attackers in many other ways.

So my question is that why do not remove the "r" permission from the code pages, that is, why not design the CPU in a way that the code can only be read into the CPU for execution?

  • 1
    I suppose the main difficulty is that code is only read by the CPU. Even if you're copying it to another memory space, it still has to go through the CPU.
    – r3mainer
    Nov 30, 2016 at 20:44

1 Answer 1


We're dealing with the consequences of Von Neumann architecture - the shared memory space for data and code. It has advantages, but as you point out, it has security problems as well, including that attack methodology.

If we were starting from scratch, I think there's no reason such a CPU couldn't be built - but many programs, from anti-virus to DRM to video games doing weird optimizations to debuggers to who-knows-what-else would not work with such restrictions. It would be hard to bring that CPU into today's market which expects backwards compatibility - some people still want DOS programs to run on today's computers. These sort of things make major architectural changes difficult.

  • 1
    Even the Harvard architecture requires a defined way to load instructions into the executable memory space, otherwise it would no longer be be a general purpose computer. It would make malware harder, but never underestimate the cleverness of determined hackers. Nov 30, 2016 at 20:47
  • @JohnDeters The behavior of reading the code from disk to page cache && updating the page table to associate page table entires with page cache is conducted by the kernel. So unless you first subvert the kernel, what you described is irrelevant. Beside, copy-on-write for code sharing is similar. I agree with the point about "determined hackers", though.
    – Infinite
    Nov 30, 2016 at 20:56
  • @Infinite , what I was picturing was a Trojan horse. Convince the machine owner that software X is worth installing, and X comes with a little surprise bonus. Or maybe it could be attacked with a technique like ROP, where you trick the instruction pointer into executing fragments of code instead of executing whole modules for their intended purpose. This is all speculation, of course, but I've learned that pronouncing anything "secure" is always an embarrassingly premature statement. Nov 30, 2016 at 21:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.