From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#23529: Request for fixing randomize_va_space build issues Date: Mon, 12 Sep 2016 20:04:39 +0300 Message-ID: <83bmzt9hi0.fsf@gnu.org> References: <83twdsalbk.fsf@gnu.org> <83r38vaiyh.fsf@gnu.org> <83eg4vab5o.fsf@gnu.org> <831t0va8br.fsf@gnu.org> <478e7c97-9339-5072-f9c1-ec67a45113aa@cs.ucla.edu> <83h99p8wbh.fsf@gnu.org> <0f0bb7ef-a588-93c3-5d27-c7329c667ed8@cs.ucla.edu> <83d1kd8qb7.fsf@gnu.org> <838tv18mnj.fsf@gnu.org> <83eg4sap3t.fsf@gnu.org> <3fe2aff8-d34e-afa3-a2bf-6e42394d7be6@cs.ucla.edu> <83wpik8f18.fsf@gnu.org> <34fb7c59-cf4a-fddf-98e7-fd4c25c3f395@cs.ucla.edu> <83k2ek83b7.fsf@gnu.org> <24612cc1-cb72-511f-7d52-bb62101906ae@cs.ucla.edu> <83fup6bguo.fsf@gnu.org> <83poo9alyc.fsf@gnu.org> <8db7f4c1-8b81-605f-8480-c740d524ccae@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1473699940 1699 195.159.176.226 (12 Sep 2016 17:05:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 12 Sep 2016 17:05:40 +0000 (UTC) Cc: 23529@debbugs.gnu.org, clement.pit@gmail.com To: Philipp Stephani Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Sep 12 19:05:32 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjUfU-0006fR-L1 for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 Sep 2016 19:05:16 +0200 Original-Received: from localhost ([::1]:44228 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjUfS-0004Cj-Pu for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 Sep 2016 13:05:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45403) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjUfJ-0004AG-Oo for bug-gnu-emacs@gnu.org; Mon, 12 Sep 2016 13:05:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bjUfG-00016s-HL for bug-gnu-emacs@gnu.org; Mon, 12 Sep 2016 13:05:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60157) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjUfG-00016o-EE for bug-gnu-emacs@gnu.org; Mon, 12 Sep 2016 13:05:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bjUfG-00076h-95 for bug-gnu-emacs@gnu.org; Mon, 12 Sep 2016 13:05:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Sep 2016 17:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23529 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.147369988927294 (code B ref 23529); Mon, 12 Sep 2016 17:05:02 +0000 Original-Received: (at 23529) by debbugs.gnu.org; 12 Sep 2016 17:04:49 +0000 Original-Received: from localhost ([127.0.0.1]:57869 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjUf2-00076A-UF for submit@debbugs.gnu.org; Mon, 12 Sep 2016 13:04:49 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54336) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjUf2-00075v-27 for 23529@debbugs.gnu.org; Mon, 12 Sep 2016 13:04:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bjUet-00010J-6C for 23529@debbugs.gnu.org; Mon, 12 Sep 2016 13:04:42 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39775) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjUet-0000zv-2u; Mon, 12 Sep 2016 13:04:39 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1880 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bjUer-0006UT-25; Mon, 12 Sep 2016 13:04:37 -0400 In-reply-to: (message from Philipp Stephani on Mon, 12 Sep 2016 06:09:10 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:123225 Archived-At: > From: Philipp Stephani > Date: Mon, 12 Sep 2016 06:09:10 +0000 > > > Isn't it the other way around: the first priority is to enable > > randomization and all the other modern techniques for running the > > dumped Emacs? > > I think we want to be able to build the full Emacs in a container; that is without needing, at any point in the process, to disable randomization. If I understand correctly, this means that even the process of dumping Emacs cannot involve disabling randomization. > > Yes, that's correct. No step in the build process should have to disable randomization. Got it, thanks. However, on second thought, I don't see why this would be an issue. I've mentioned gmalloc as a candidate for an malloc implementation during the temacs run (i.e. during dumping), because gmalloc can be told to use our own sbrk, and that sbrk could allocate memory off an array we define; this might make the job of finding the memory to dump easier. Paul said that gmalloc doesn't work well when ASLR is enabled, but I now think this is not relevant, because we will be allocating from a single contiguous array, which AFAIU is unaffected by ASLR, and also makes those gmalloc problems a non-issue as a side effect. Moreover, if for some reason using gmalloc is not an option, or doesn't really help with this job, that would just make the job of collecting the memory to dump harder, but not too hard. Again, ASLR adds nothing to this picture, as the job of collecting the memory to dump will be based on known pointers to known data structures, and the values of the addresses where these pointers point to are of no importance.