From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alex =?utf-8?Q?Benn=C3=A9e?= Newsgroups: gmane.emacs.devel Subject: Re: Getting ready to land native-compilation on master Date: Thu, 15 Apr 2021 12:15:21 +0100 Message-ID: <87eefblrml.fsf@linaro.org> References: <83v98v7dzs.fsf@gnu.org> <87v98ox3pe.fsf@tammy.lan.sha-bang.de> <83czuwzto3.fsf@gnu.org> <87lf9klqmn.fsf@linaro.org> <83a6q0zrv7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17137"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.5.11; emacs 28.0.50 Cc: wilde@sha-bang.de, emacs-devel@gnu.org, akrl@sdf.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 15 13:23:34 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lX05u-0004LQ-Ec for ged-emacs-devel@m.gmane-mx.org; Thu, 15 Apr 2021 13:23:34 +0200 Original-Received: from localhost ([::1]:35882 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lX05t-00062Y-Fb for ged-emacs-devel@m.gmane-mx.org; Thu, 15 Apr 2021 07:23:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58162) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lX04f-00059V-94 for emacs-devel@gnu.org; Thu, 15 Apr 2021 07:22:17 -0400 Original-Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]:42911) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lX04d-0008FK-A0 for emacs-devel@gnu.org; Thu, 15 Apr 2021 07:22:16 -0400 Original-Received: by mail-wr1-x42e.google.com with SMTP id p6so16225005wrn.9 for ; Thu, 15 Apr 2021 04:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version:content-transfer-encoding; bh=Spzi/N10t1wh/Mbw6BMh/EtQJFNywebwu377r+hpXM0=; b=BcEaNa1wldScHlE/nqsk8j3Af1oBv/ejmhxn2Z9DAJdUtLVSWymdEBVzDFyD5SSGg9 s7AAiZ0Ef5xY46rOGFRXo556fXitP7sJm5IZpoKArd5LqU/3kD5kmuQE7xDQwSmrZQmT 7BFXCdC+t2o83NSj8tfKW0hodv6jL7UlvzdJaHFPD6TG3NX8Sjz7cU5p6U2qyVPRMbx+ HfOsqGTcvIVCYUf9s9xwn+LyRv+RQxApxrTdHCeh0lpuOdC5PCzO5EiGWMhtRzZTZhDN ldTgFEfZ/8eA7GCdkzFXFmesSal/7L2oaPlQAtm8kWIhouahVqyjzKP8plbAkcdNDI84 cQcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version:content-transfer-encoding; bh=Spzi/N10t1wh/Mbw6BMh/EtQJFNywebwu377r+hpXM0=; b=TJX0doU9iV2EdN0sIpMwfQxzqdKRRepukAX0JVZUKZSg2fkKaZkMHt3XFG6KsKhOXx +MSyMWRGCqCrGDpcUJrC2ASwbyeCVV4WqYg4cFMmm67FzwVkYdWaY3tJyLqy4fbWyLxc cnKl8dAClZS0Nj1224IszVqbKOcZWQLGew5vVbdHjrqRBgM/Y/uDu9I24FpFzZl812xT T6oU2HGYitq+ld7kHJHetS7uRov7fxmXGCOFg7YhrCvS4lHCSQbsL7x8qqb3Vh9DdLE3 JS9/UJu/FO8UzV1rl9uX22H6lr1t0iWpG1mW4IiVJka9KRwMfNxxqrkSKGnG7XRrm3/f WGcA== X-Gm-Message-State: AOAM530cqdwnCzWYQzApXkJzU0fClbohXmdShM+Pbdh7TIwkNSWDZiFr UbV4tB/vyWGJwW1Wfhlw9NRojA== X-Google-Smtp-Source: ABdhPJzG6W8zcGSqyDKOKJUFFY+mRGuC0a4VmYxvhFG/sk267gaWuF30CUvJbkjAOhafyGNcfUFmug== X-Received: by 2002:adf:e8cf:: with SMTP id k15mr2963944wrn.112.1618485732946; Thu, 15 Apr 2021 04:22:12 -0700 (PDT) Original-Received: from zen.linaroharston ([51.148.130.216]) by smtp.gmail.com with ESMTPSA id f8sm2145161wmc.8.2021.04.15.04.22.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Apr 2021 04:22:11 -0700 (PDT) Original-Received: from zen (localhost [127.0.0.1]) by zen.linaroharston (Postfix) with ESMTP id EC91B1FF7E; Thu, 15 Apr 2021 12:22:10 +0100 (BST) In-reply-to: <83a6q0zrv7.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::42e; envelope-from=alex.bennee@linaro.org; helo=mail-wr1-x42e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:268084 Archived-At: Eli Zaretskii writes: >> From: Alex Benn=C3=A9e >> Cc: wilde@sha-bang.de, akrl@sdf.org, emacs-devel@gnu.org >> Date: Wed, 14 Apr 2021 18:28:49 +0100 >>=20 >> >> sysctl -w security.pax.mprotect.global=3D0 >> >> sysctl -w security.pax.mprotect.enabled=3D0 >> >> 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. >>=20 >> 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 compl= e- ment non-executable mappings. The purpose is to prevent situations wh= ere 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=3D1 PaX MPROTECT affects the following three uses: =C2=B7 Processes that utilize code generation (such as the JVM= ) might need to have MPROTECT disabled. =C2=B7 Miscompiled programs that have text relocations, will n= ow core dump instead of having their relocations corrected. You will need to fix those programs (recompile them properly). =C2=B7 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. --=20 Alex Benn=C3=A9e