From: "Alex Bennée" <alex.bennee@linaro.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: wilde@sha-bang.de, emacs-devel@gnu.org, akrl@sdf.org
Subject: Re: Getting ready to land native-compilation on master
Date: Thu, 15 Apr 2021 12:15:21 +0100 [thread overview]
Message-ID: <87eefblrml.fsf@linaro.org> (raw)
In-Reply-To: <83a6q0zrv7.fsf@gnu.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
next prev parent reply other threads:[~2021-04-15 11:15 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-09 14:02 Getting ready to land native-compilation on master Eli Zaretskii
2021-04-09 14:27 ` tomas
2021-04-09 14:33 ` Stefan Kangas
2021-04-09 14:39 ` T.V Raman
2021-04-09 16:17 ` Pip Cet
2021-04-09 16:35 ` Thierry Volpiatto
2021-04-09 18:57 ` Eli Zaretskii
2021-04-10 5:39 ` Thierry Volpiatto
2021-04-09 17:12 ` Jens C. Jensen
2021-04-09 18:53 ` Stefan Monnier
2021-04-09 18:59 ` Jens C. Jensen
2021-04-09 22:43 ` Stefan Monnier
2021-04-10 8:45 ` Jens C. Jensen
2021-04-10 13:10 ` Stefan Monnier
2021-04-09 19:08 ` Andrea Corallo via Emacs development discussions.
2021-04-09 19:14 ` Eli Zaretskii
2021-04-10 0:07 ` Andy Moreton
2021-04-10 7:23 ` Eli Zaretskii
2021-04-10 11:40 ` Andy Moreton
2021-04-09 18:09 ` Sujith Manoharan
2021-04-09 18:50 ` Eli Zaretskii
2021-04-09 18:27 ` Alex Bennée
2021-04-09 18:48 ` Andrea Corallo via Emacs development discussions.
2021-04-14 4:39 ` Pankaj Jangid
2021-04-14 6:31 ` Eli Zaretskii
2021-04-14 9:45 ` Philip Kaludercic
2021-04-14 10:14 ` Andrea Corallo via Emacs development discussions.
2021-04-14 10:35 ` Philip Kaludercic
2021-04-14 10:45 ` Eli Zaretskii
2021-04-14 10:49 ` Eli Zaretskii
2021-04-14 12:57 ` Philip Kaludercic
2021-04-14 13:10 ` Eli Zaretskii
2021-04-14 14:00 ` Philip Kaludercic
2021-04-14 14:35 ` Stefan Kangas
2021-04-14 14:42 ` Philip Kaludercic
2021-04-14 14:50 ` Stefan Monnier
2021-04-14 15:02 ` Eli Zaretskii
2021-04-14 14:37 ` Eli Zaretskii
2021-04-14 14:48 ` Dmitry Gutov
2021-04-14 17:10 ` Eli Zaretskii
2021-04-14 10:48 ` Andrea Corallo via Emacs development discussions.
2021-04-14 15:53 ` wilde
2021-04-14 17:02 ` Eli Zaretskii
2021-04-14 17:28 ` Alex Bennée
2021-04-14 17:41 ` Eli Zaretskii
2021-04-15 11:15 ` Alex Bennée [this message]
2021-04-14 18:07 ` Andrea Corallo via Emacs development discussions.
2021-04-14 20:23 ` Stefan Kangas
2021-04-14 22:01 ` Andrea Corallo via Emacs development discussions.
2021-04-15 9:25 ` wilde
2021-04-15 11:19 ` wilde
2021-04-15 16:23 ` Andrea Corallo via Emacs development discussions.
2021-04-27 16:25 ` wilde
2021-04-28 3:06 ` Corwin Brust
2021-04-28 17:52 ` Jose E. Marchesi
2021-04-29 8:20 ` Arthur Miller
2021-04-22 10:09 ` wilde
2021-04-22 11:14 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87eefblrml.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=akrl@sdf.org \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=wilde@sha-bang.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.