> This may be a bit of a silly question. There is talk about an upcoming > Common Criteria requirement that no memory may be executable and > writable at the same time.
That comes a little late (meaning lots of software was written to require this, over the last decades), but also a little early (lots of software has been fixed... but not everything). Firefox only became capable of running without WX pages a few months ago. Meaning, any operating system which ENFORCED W^X would be unable to run it. Therefore, W^X has always been a policy for software to follow. Meaning, the libraries won't ask for WX, ld.so won't ask for WX, nothing will. If something wants to shoot itself in the foot, we could not stop it, because well.. firefox was asking for it until a few months ago... I believe chrome / v8 still requires WX memory. > OpenBSD is said to meet this requirement. That requirement is a nice idea, but there is software in the ports ecosystem which still requires it. > However, I installed the amd64 variant of OpenBSD 5.9, and ran short > test program which allocates a W|X page using: > > void *addr = mmap (NULL, page_size, > PROT_READ | PROT_WRITE | PROT_EXEC, > MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); > > mmap succeeds, and the page is writable and executable. (The test case > even writes it, executes, writes it again with different contents, and > executes it again.) > > Is there a knob to enable W^X enforcement? No, we don't have such a knob, because the greater ecosystem isn't clean enough yet to mandate it. I'd like for us to get there. I generally reject the addition of security knobs, and push towards making the security choice mandatory, as early as possible. We are not quite in the position of making this choice. (Maybe a ports developer can list some programs that require WX memory today) I hope no new software is being written to depend on WX allocations working... > Or does W^X just mean that you won't get W|X memory unless you ask > for it explicitly? Yes, in effect if you ask for it explicitly (either with mmap, or with mprotect), we have to provide it. I hate it, but the ecosystem is still stuck there, until some investment happens to push a few pieces of software into W^X mode, mostly on the JIT side. We all know better now: JITs that follow W^X are not substantially slower, and they are substantially more secure. > (I know that historically, if you asked for W|R memory, say using > malloc, you got W|R|X on i386 because there was no separate per-page > flag for read and exec, and the segment size limit kludge wasn't > invented yet.) Oh it was worse than that! Around 20 years ago, the heap was executable, and there even was a small time when mmap-based malloc's allocated PROT_READ | PROT_WRITE | PROT_EXEC memory. > I understand that we (the larger ecosystem) still need to change some > applications not to perform PROT_WRITE | PROT_EXEC (or the equivalent > alias mapping kludge). Well, alias mappings are generally an unsafe practice; in a ROP attack environment it is likely that variables -- pointing towards the aliased space -- will be found in registers... or at least registers pointing at some object ... which points at some object ... which knows where the alias space is..
