From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philippe Vaucher Newsgroups: gmane.emacs.bugs Subject: bug#23529: Request for fixing randomize_va_space build issues Date: Wed, 18 May 2016 10:44:37 +0200 Message-ID: References: <573C2601.3030308@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1463561191 18562 80.91.229.3 (18 May 2016 08:46:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 May 2016 08:46:31 +0000 (UTC) Cc: 23529@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed May 18 10:46:20 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1b2x7T-0005xX-CN for geb-bug-gnu-emacs@m.gmane.org; Wed, 18 May 2016 10:46:19 +0200 Original-Received: from localhost ([::1]:43709 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2x7M-0005sc-W0 for geb-bug-gnu-emacs@m.gmane.org; Wed, 18 May 2016 04:46:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44451) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2x7F-0005sP-Sc for bug-gnu-emacs@gnu.org; Wed, 18 May 2016 04:46:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b2x7C-0006Gy-PE for bug-gnu-emacs@gnu.org; Wed, 18 May 2016 04:46:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44188) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2x7C-0006Gr-LD for bug-gnu-emacs@gnu.org; Wed, 18 May 2016 04:46:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1b2x7C-0000B0-BQ for bug-gnu-emacs@gnu.org; Wed, 18 May 2016 04:46:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philippe Vaucher Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 18 May 2016 08:46: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: moreinfo Original-Received: via spool by 23529-submit@debbugs.gnu.org id=B23529.1463561115617 (code B ref 23529); Wed, 18 May 2016 08:46:02 +0000 Original-Received: (at 23529) by debbugs.gnu.org; 18 May 2016 08:45:15 +0000 Original-Received: from localhost ([127.0.0.1]:56525 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b2x6R-00009s-D5 for submit@debbugs.gnu.org; Wed, 18 May 2016 04:45:15 -0400 Original-Received: from mail-vk0-f67.google.com ([209.85.213.67]:35820) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b2x6P-00009e-F7 for 23529@debbugs.gnu.org; Wed, 18 May 2016 04:45:13 -0400 Original-Received: by mail-vk0-f67.google.com with SMTP id e126so5993253vkb.2 for <23529@debbugs.gnu.org>; Wed, 18 May 2016 01:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Nz+xWn9A3144UyFRoaxKCIzE3cxJXl1Wp3bdi0ibxvw=; b=ONQY9fvnuO/76j5obAjDVQwbvXcYD0ni5+iiI8xJEFYk5Sqsf/h+YoRP1fsNj3xNR3 0YS8Td/VqECtUtQSAQbvj0d+BkmTrDaGkDAs2jg2R5X1P4bjdu0z1GN1q3soIZZbsVV7 uzajt8Q+epKRC5Ew35UITVLkWUUV9FSBGVQA3KcABWti9Dr2TJRSrWvZMXV8KlLsSZCU ES/EyO02uMijiM7LwCzuPfVPY+aJGef5CEPbEhLXJxTG4gj+aGkFNQBTX/uUuM5guLnd eVY/w/wSXGNnqlxrKEruU8Bm9PJGjvChnSTHjazb5xYQkbpCgRmCy92dJKf6mCKWbb3N KYyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Nz+xWn9A3144UyFRoaxKCIzE3cxJXl1Wp3bdi0ibxvw=; b=jIJpkAXTxe2ywSlrtbbBMFgVO/Tw5mUVrCeuSD1R0ImBlbCju6CHoG+bi8D8xiJnTA iRBPYgvs6C7g+HBG2Xw+m2vxh1/SXB687AwXiQirNObVQuBk86f5iza/S0dIz6VPpAuw ATaDvTdtxm6GjJQA4KS9B5ueYdOC+yh4Ew25jLPLgqFHuw8UsXZsUSDUnjgEYA0h/sIb VIBXVYswJU3NHt5ZuCB9qIU9ldRDglD4I7fwanYEAq9LUqksX1yVcmoliwJbs1Q9lZ7Y JbWTMCP1HqArCBKAF369QpeZaBbDacDOWZqeXVCdmFo5Ln31rpwTt/y/OnqSmSeZIBi6 aIqg== X-Gm-Message-State: AOPr4FUUu/k2cmnMbhtORdRFZYLvI1OtR/MqZkT0C9StBagY0o8gRA/g3ytuYcR/YwnH1OpOHyuIT1UPd9624Q== X-Received: by 10.159.38.72 with SMTP id 66mr2399594uag.126.1463561107331; Wed, 18 May 2016 01:45:07 -0700 (PDT) Original-Received: by 10.103.28.133 with HTTP; Wed, 18 May 2016 01:44:37 -0700 (PDT) In-Reply-To: <573C2601.3030308@cs.ucla.edu> 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:118382 Archived-At: > Some background: Emacs has an 'undump' function that saves the Emacs state as an > executable: when you run the executable, you get an Emacs with the same (or > nearly the same) state. This makes Emacs startup considerably faster. Objects in > the restored state must be in the same location as when they were saved, so the > executable cannot be subject to ASLR. Alright, that makes sense now. > I don't know all the ins and outs of why it is necessary for Emacs to invoke > 'personality'. As I understand it, the build procedure should invoke the shell > command 'setfattr -n user.pax.flags -v er temacs' immediately after building > temacs, and I don't know why this doesn't make the 'personality' call > unnecessary. Perhaps you can consult a seccomp expert who can tell you what's > going on, as seccomp is not well-documented. If there is some way to disable > ASLR without calling 'personality', that should fix your problem. I'll try to debug the `setfattr` part to see what it does. I seems that `setarch -R` and `personality` both "works" return-status wise but in practice inside docker they don't change anything (and thus don't disable ASLR). It looks like eventually the problem will be fixed on the docker side... but maybe the debug session will yield some emacs patch. > Regardless, the advice in etc/PROBLEMS is clearly obsolete here, so I installed > the attached patch to try to make things clearer. We're not going to greatly > alter the dumping procedure before Emacs 25 comes out (it's too late in the > release process) but we should do better in the future. For now we should at > least document the issues better. Ah, good patch! About the dumping procedure, do you mean there *is* a plan to alter it after Emacs 25 comes out? The building behavior on this issue about ASLR between 24.5 and 25.0.93 seems very similar from my experience. >> I tried to run "./temacs --batch --load loadup bootstrap" inside GDB >> to get more insights about why it segfaults there, but somehow gdb >> fails to catch it. Maybe because of spawned processes? > > Yes, the code you highlighted does an execvp. You might try fiddling with GDB's > follow-exec-mode variable; see > . I'll play with it. Thanks! Philippe