Instead we do the opposite today, we mark the data pages with the "No Execute" bit, which is a far better way to ensure malicious code doesn't execute.
I'm by no means an expert in this domain but my understanding is that that's normally not happening on x86/x64, not even on Linux or OS X. Otherwise, how could just-in-time compilers like Java, .NET or V8 work? Please correct me however if I'm wrong.
Modern x86 does have the NX bit (and other major archs like ARM have equivalents), which allows areas of memory to be marked executable or not, and most modern operating systems do use it. JIT VMs will explicitly set it on produced code.
This is part of the reason that JIT is not allowed, and will not even _work_, on iOS (with the exception of Mobile Safari's Javascript engine, which has special privileges). Applications aren't allowed set the ARM NX equivalent.
JIT compilers allocate executable memory by using mmap() (not malloc(), since malloc()-allocated memory is not guaranteed (or even likely) to be executable). When you map memory with mmap(), you can decide the protection bits (PROT_READ, PROT_WRITE, PROT_EXEC, and they can be OR'd together in any combination).
malloc()ed memory is executable if you mprotect() it to be so. malloc()ing memory and blindly executing it is definitely a bug OTOH. malloc() is mmap() based a lot of systems nowadays anyway, so malloc() vs mmap() is just a choice of convenience of API.
> malloc()ed memory is executable if you mprotect() it to be so.
True, but since mprotect() can only operate on full pages your mprotect() calls will most likely affect memory beyond what malloc gave you. For example if remove write or execute permissions your program will probably crash, and it's best to avoid having pages that are both writable and executable.
Comments
Whatever happened to the old idea of separating program and data spaces and write-protecting the program space?
Instead we do the opposite today, we mark the data pages with the "No Execute" bit, which is a far better way to ensure malicious code doesn't execute.
I'm by no means an expert in this domain but my understanding is that that's normally not happening on x86/x64, not even on Linux or OS X. Otherwise, how could just-in-time compilers like Java, .NET or V8 work? Please correct me however if I'm wrong.
Modern x86 does have the NX bit (and other major archs like ARM have equivalents), which allows areas of memory to be marked executable or not, and most modern operating systems do use it. JIT VMs will explicitly set it on produced code.
This is part of the reason that JIT is not allowed, and will not even _work_, on iOS (with the exception of Mobile Safari's Javascript engine, which has special privileges). Applications aren't allowed set the ARM NX equivalent.
JIT compilers allocate executable memory by using mmap() (not malloc(), since malloc()-allocated memory is not guaranteed (or even likely) to be executable). When you map memory with mmap(), you can decide the protection bits (PROT_READ, PROT_WRITE, PROT_EXEC, and they can be OR'd together in any combination).
For example, from the V8 sources: http://www.google.com/codesearch#W9JxUuHYyMg/trunk/src/platf...
malloc()ed memory is executable if you mprotect() it to be so. malloc()ing memory and blindly executing it is definitely a bug OTOH. malloc() is mmap() based a lot of systems nowadays anyway, so malloc() vs mmap() is just a choice of convenience of API.
> malloc()ed memory is executable if you mprotect() it to be so.
True, but since mprotect() can only operate on full pages your mprotect() calls will most likely affect memory beyond what malloc gave you. For example if remove write or execute permissions your program will probably crash, and it's best to avoid having pages that are both writable and executable.
These are von neumann machines, not harvard, at all levels of abstraction save for some newer security measures.