W^X non-compliance

I noticed in a list maintained by a PaX developer that Racket doesn't yet conform to W^X. This means that Racket maps memory pages that at some point simultaneously have write and execute permissions at the hardware level. These permissions are determined by the options passed to mmap(2), and by any subsequent calls to mprotect(2).

WX pages make heap-based exploits easier, so they're being phased out. I'm not aware of a reasonable use case for them, either. Relatively few projects still use WX pages (most include as-of-yet untamed JIT compilers), and in the not-so-distant future operating systems will probably enforce W^X.

I don't have Racket development experience and don't have time to start at the moment. I thought I'd mention this to start the conversation, though.

A few examples:

• racket/src/racket/src/salloc.c:941
• racket/src/racket/src/salloc.c:947
• racket/src/racket/sgc/sgc.c:975
• racket/src/racket/gc/os_dep.c:1940

Thanks for your time,
Mike

Start by inspecting the mmap(2) and mprotect(2) call sites in racket/src/racket/src/salloc.c, racket/src/racket/sgc/sgc.c, and racket/src/racket/gc/os_dep.c. Trace why those mappings require simultaneous write and execute permissions and determine whether the runtime's allocation or garbage-collection paths can avoid them. Done means Racket no longer creates hardware-level WX pages, with relevant behavior verified across the affected paths.