w^x write xor execute

It is a security feature. The default is more secure, setting it to 1 may make certain binaries work. I don't think you can create such binaries with the default binutils, though.
 
I understand that on the 8-bit machines of the 1980s, this capability (self-modifying code) was the norm. The skill required to take advantage of it must have been immense. It also strikes me that by disallowing this, modern OSs are eliminating a whole branch of artistic expression in programming.
 
You can still do this today, JIT compilers can profit from this. You can also create these binaries with current toolchains. BUT, as always, being able to do something does not mean you should do it. The OS is perfectly allowed to forbid anyone to modify executable memory. That makes it harder for evil code to take over things. And it really needs a large amount of skill to do this self modifying code correctly, claiming to be able and actually being able are two things.
 
I understand that on the 8-bit machines of the 1980s, this capability (self-modifying code) was the norm. The skill required to take advantage of it must have been immense. It also strikes me that by disallowing this, modern OSs are eliminating a whole branch of artistic expression in programming.

Setting this to off doesn't prevent self-modifying code as such. Just the loading of regular ELF binaries with it. A system like SBCL manages its own heap where pages are marked write and executable at will (and code moves around since it is subject to garbage collection).

This is different from current macOS on Apple Silicon where such mappings are actually partially forbidden (the details escape me right now, SBCL still works).

A JIT will typically write to some pages and then change those pages to -w +x.
 
Crivens yes im aware that most people who are interested in writing self-modifying code probably aren't intending to do it out of the kindness of their hearts. :D It's nevertheless interesting artistically.
@cracauer that's interesting - I always assumed Lisp was writing some kind of byte code, I had no idea it writes actual target machine instructions.
 
@cracauer that's interesting - I always assumed Lisp was writing some kind of byte code, I had no idea it writes actual target machine instructions.

Common Lisp has all kinds. SBCL is a native compiler with its own assembler and linker. Clasp compiles Common Lisp to LLVM bytecode, which is then given to LLVM, the system linker and sometimes the LLVM JIT. Both have optional bytecode machines in case you want fast loading of code.

None of these would be affected by this sysctl because the mappings in question don't come from ELF loading. So they can freely set write and execute on pages.
 
Back
Top