Re: PAX mprotect and JIT

> Date: Mon, 27 Feb 2017 03:17:15 + (UTC) > From: chris...@astron.com (Christos Zoulas) > > In article <20170226213704.ded7260...@jupiter.mumble.net>, > Taylor R Campbell wrote: > > > >The idiom I imagine is something like: > > > > void *buf =

Re: PAX mprotect and JIT

In article <20170226213704.ded7260...@jupiter.mumble.net>, Taylor R Campbell wrote: > >The idiom I imagine is something like: > > void *buf = mmap(NULL, len, PROT_READ|PROT_WRITE|PROT_EXEC, > MAP_ANON|MAP_REMAPDUP, -1, 0); This is never

Re: PAX mprotect and JIT

> Aside: Do we need any additional memory barriers to synchronize > writing to code with executing the code in memory? On some CPU architectures you do (eg, the Super-H used by the Dreamcast, at least when the D$ is configured write-back, and probably even if it's configured WT if you don't flush

Re: PAX mprotect and JIT

> Date: Sun, 26 Feb 2017 16:38:04 +0100 > From: Joerg Sonnenberger > > On Sun, Feb 26, 2017 at 03:20:17PM +, Taylor R Campbell wrote: > > Can we make this opt-in at mmap time -- that is, require you to have > > specified MAP_REMAPDUP to mmap on a region in order to use it for >

Re: PAX mprotect and JIT

On Sun, Feb 26, 2017 at 02:09:08PM +0100, Joerg Sonnenberger wrote: > The mremap() dance is only desirable for multi-threaded JIT. If you > compile a module at a time before making it visible, just a plain > mprotect is enough. I would prefer to not allow toggling back and forth via mprotect() at

Re: PAX mprotect and JIT

In article <20170226153519.ga28...@britannica.bec.de>, Joerg Sonnenberger wrote: >On Sun, Feb 26, 2017 at 03:20:46PM +, Christos Zoulas wrote: >> Any type of foreign API we introduce (MREMAP_DUP or whatever) we'll have to >> maintain separate patches for (which is not that

Re: PAX mprotect and JIT

On Sun, Feb 26, 2017 at 03:27:05PM +0100, Kamil Rytarowski wrote: > On 26.02.2017 15:05, co...@sdf.org wrote: > > On Sun, Feb 26, 2017 at 02:52:39PM +0100, Kamil Rytarowski wrote: > >> Can we have something like MAP_NOMPROTECT? Something like it would be > >> used to mmap(2) RWX region: > >> > >>

Re: PAX mprotect and JIT

On Sat, Feb 25, 2017 at 10:35:27PM +0100, Joerg Sonnenberger wrote: > the answer can't be > "disable PAX mprotect on bin/python*" We could theoretically have python-wx-2.7, infra-wise it's not too hard, just terrible.

Re: PAX mprotect and JIT

On Sun, Feb 26, 2017 at 03:20:17PM +, Taylor R Campbell wrote: > > Date: Sat, 25 Feb 2017 22:35:27 +0100 > > From: Joerg Sonnenberger > > > > (1) Implement a new flag for mremap to allow duplicating a mapping > > (M_REMAPDUP). This patch is functional by itself. > > Can we

Re: PAX mprotect and JIT

On Sun, Feb 26, 2017 at 03:20:46PM +, Christos Zoulas wrote: > Any type of foreign API we introduce (MREMAP_DUP or whatever) we'll have to > maintain separate patches for (which is not that bad), instead of teaching > libffi (and friends) that we are like SE/Linux and we need to write > files

Re: PAX mprotect and JIT

In article , Kamil Rytarowski wrote: >-=-=-=-=-=- >-=-=-=-=-=- > >On 26.02.2017 15:05, co...@sdf.org wrote: >> On Sun, Feb 26, 2017 at 02:52:39PM +0100, Kamil Rytarowski wrote: >>> Can we have something like MAP_NOMPROTECT? Something

Re: PAX mprotect and JIT

> Date: Sat, 25 Feb 2017 22:35:27 +0100 > From: Joerg Sonnenberger > > (1) Implement a new flag for mremap to allow duplicating a mapping > (M_REMAPDUP). This patch is functional by itself. Can we make this opt-in at mmap time -- that is, require you to have specified MAP_REMAPDUP

Re: PAX mprotect and JIT

On 26.02.2017 16:03, Joerg Sonnenberger wrote: > On Sun, Feb 26, 2017 at 02:52:39PM +0100, Kamil Rytarowski wrote: >> It looks difficult to understand on the first sight, the need to >> "reinvent" malloc(3) with this approach. > > The point here is to have strict segration between code and

Re: PAX mprotect and JIT

On Sun, Feb 26, 2017 at 03:27:05PM +0100, Kamil Rytarowski wrote: > Is there a room to add this nomprotect allocator in libutil(3) to make > it convenient to reuse out of libffi? Most libraries doing JIT already know how to deal with segration like this and have their own memory management for

Re: PAX mprotect and JIT

On Sun, Feb 26, 2017 at 02:52:39PM +0100, Kamil Rytarowski wrote: > It looks difficult to understand on the first sight, the need to > "reinvent" malloc(3) with this approach. The point here is to have strict segration between code and non-code. It doesn't work perfectly due to the additional

Re: PAX mprotect and JIT

On 26.02.2017 15:05, co...@sdf.org wrote: > On Sun, Feb 26, 2017 at 02:52:39PM +0100, Kamil Rytarowski wrote: >> Can we have something like MAP_NOMPROTECT? Something like it would be >> used to mmap(2) RWX region: >> >> void *mapping = mmap(NULL, rounded_size, PROT_READ | PROT_WRITE | >>

Re: PAX mprotect and JIT

On Sun, Feb 26, 2017 at 02:52:39PM +0100, Kamil Rytarowski wrote: > Can we have something like MAP_NOMPROTECT? Something like it would be > used to mmap(2) RWX region: > > void *mapping = mmap(NULL, rounded_size, PROT_READ | PROT_WRITE | > PROT_EXEC, MAP_ANON | MAP_PRIVATE | MAP_NOMPROTECT, -1,

Re: PAX mprotect and JIT

On 25.02.2017 22:35, Joerg Sonnenberger wrote: > Hi all, > at the moment, PAX mprotect makes it very expensive to implement any > form of JIT. It is not possible to switch a page from writeable to > executable. It is not possible to use anonymous memory for JIT in > multi-threaded applications as

Re: PAX mprotect and JIT

On Sun, Feb 26, 2017 at 10:30:05AM +0100, Martin Husemann wrote: > > (2) A hack for allow mprotect to switch between W and X, but still > > honoring W^X. This is a hack and needs to be carefully rethought, > > since I believe the way pax is currently implemented is wrong. Consider > > it a PoC. >