On Tue, Nov 15, 2016 at 09:10:52PM +0800, Paul Goyette wrote: > On Tue, 15 Nov 2016, Joerg Sonnenberger wrote: > > > On Tue, Nov 15, 2016 at 01:55:16PM +0100, Thomas Klausner wrote: > > > On Tue, Nov 15, 2016 at 01:42:56PM +0100, Joerg Sonnenberger wrote: > > > > On Tue, Nov 15, 2016 at 12:34:14PM +0100, Thomas Klausner wrote: > > > > > I've filed some upstream bug reports about paxctl issues, some existed > > > > > already. > > > > > > > > > > One developer asks how to fix the issue: > > > > > > > > > > https://bugs.exim.org/show_bug.cgi?id=1749 > > > > > > > > > > Can someone please help out here? > > > > > > > > The only safe and performant way I know is to create a temporary file, > > > > unlink it and mmap it twice via the fd. It's a PITA. > > > > > > So mkstemp() to get a file, unlink() to remove it, write the JIT code > > > to the file. What are the two mmap()s for, what flags do they get? > > > > One is writeable, the other is executable. > > So, you don't write(2) to the file. You store code in memory via the > writeable mmap address range, and then execute via the 2nd mmap range.
Correct. That's the only approach that is both thread-safe and performant. It somewhat defeats part of the purpose of W^X of course, but given the alternatives, that seems like the lesser evil. I've wondered about providing a variant of mremap that keeps the original mapping in place, but allows you to create a second mapping with different flags. That would be the cleaner approach. Joerg
