tags + moreinfo
quit
Hi,
Instead, it is possible to enable a different allocator that uses
separate mappings for the same allocation, one with read/write and one
with read/executable mappings, the placement of which is randomized in
the process's virtual address space, making abuse much harder.
Thanks for bringing this up. I'm not immediately sure how safe and
sensible this would be to deploy.
It's noted as experimental in configure.ac:
# Handle --enable-jit-sealloc (disabled by default and only experimental)
And, if I've followed the code through the build flags, it has the
effect of setting SLJIT_PROT_EXECUTABLE_ALLOCATOR to 1; which is
commented thus:
/* When SLJIT_PROT_EXECUTABLE_ALLOCATOR is enabled SLJIT uses
an allocator which does not set writable and executable
permission flags at the same time.
Instead, it creates a shared memory segment (usually backed by a file)
and maps it twice, with different permissions, depending on the use
case.
The trade-off is increased use of virtual memory, incompatibility with
fork(), and some possible additional security risks by the use of
publicly accessible files for the generated code. */
[it also talks about SELinux in the docs, so I'm not immediately clear
how this relates to that and/or systems where SELinux isn't in use]
...so my feeling is this may not be an obviously good change to make
distribution-wide...
Regards,
Matthew
