https://bugs.exim.org/show_bug.cgi?id=1749
--- Comment #17 from Petr Pisar <ppisar@???> ---
Despite all this I think your approach still has security benefits since it
creates a one-way transition to PROT_EXEC only memory without possibility to
modify once compiled code. I appreciate you devoted your time to this issue. I
hope (not only) NetBSD people will be happier.
I have a parallel discussion with Red Hat security team and it actually looks
like the temporary file approach is more a loop-hole in SELinux implementation
than a security feature that could provide better security than the mprotect()
approach. I will keep you informed.
By the way sljit produces position independent code so it could execute the
jitted code even from a different mapping, or would the temporary file approach
need also changing the jumps it the code if the SLJIT_ENABLE_EXEC() replaced
addresses to the second mapping?
--
You are receiving this mail because:
You are on the CC list for the bug.
