Re: Getting ready to land native-compilation on master

["Alex Bennée" <alex.bennee@linaro.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alex Bennée <alex.bennee@linaro.org>
>> Cc: wilde@sha-bang.de, akrl@sdf.org, emacs-devel@gnu.org
>> Date: Wed, 14 Apr 2021 18:28:49 +0100
>> 
>> >>     sysctl -w security.pax.mprotect.global=0
>> >>     sysctl -w security.pax.mprotect.enabled=0
>> >>   This is not a Emacs specific problem but a problem with libgccjit
>> >>   itself.  (The basic gcc jit "Hello World" example also fails with
>> >>   memory protection in place).
>> >
>> > I'm not sure I understand why this happens, but I think this issue
>> > should be reported to the GCC Bugzilla.
>> 
>> I suspect this is a change similar to the recent MacOS one where
>> eXecutable pages cannot be mapped as Writable. The QEMU project recently
>> had to implement split mappings for it's JIT to workaround this although
>> I dare say there is probably a JIT interface that should be used to give
>> suitable access to pages but that is something for the BSD experts to
>> chime in on.
>
> Are you sure this is relevant?

Not entirely - it was an educated guess but the write up in the BSD
pages seems to indicate this behaviour:

   PaX MPROTECT
     PaX MPROTECT implements memory protection restrictions, meant to comple-
     ment non-executable mappings.  The purpose is to prevent situations where
     malicious code attempts to mark writable memory regions as executable,
     often by trashing arguments to an mprotect(2) call.

     While it can be enabled globally, NetBSD provides a tool, paxctl(8), to
     enable PaX MPROTECT on a per-program basis.

     Example usage:

           # paxctl +M /usr/sbin/sshd

     Enabling PaX MPROTECT globally:

           # sysctl -w security.pax.mprotect.global=1

     PaX MPROTECT affects the following three uses:

           ·   Processes that utilize code generation (such as the JVM) might
               need to have MPROTECT disabled.

           ·   Miscompiled programs that have text relocations, will now core
               dump instead of having their relocations corrected.  You will
               need to fix those programs (recompile them properly).

           ·   Debugger breakpoints: gdb(1) needs to be able to write to the
               text segment in order to insert and delete breakpoints.  This
               will not work unless MPROTECT is disabled on the executable.

> libgccjit, contrary to its name, is not JIT code production, at least
> in Emacs. It produces a file, a shared library which is later loaded.
> Why does this have to need executable memory pages?

Well any page with code needs to executable. The question is how does
libgccjit handle it? Does it write a stream of bytes to a file that is
then mapped in r-x to be executed or does it map a file -w- to write the
instruction stream and then just remap it afterwards r-x when it's
"loaded". If it's ultimately the same page changes permissions I can
expect the above would complain.

I'm not familiar enough with how libgccjit generates and loads the code.

-- 
Alex Bennée