From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.emacs.devel Subject: Re: Dumper problems and a possible solutions Date: Wed, 25 Jun 2014 16:24:03 -0400 Message-ID: <20140625202403.GB179@brightrain.aerifal.cx> References: <20140624171955.GS179@brightrain.aerifal.cx> <53AB0EF8.4090608@yandex.ru> <831tucrguf.fsf@gnu.org> <20140625183241.GW179@brightrain.aerifal.cx> <83wqc4q0xl.fsf@gnu.org> <20140625190333.GZ179@brightrain.aerifal.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1403727881 12307 80.91.229.3 (25 Jun 2014 20:24:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Jun 2014 20:24:41 +0000 (UTC) Cc: Eli Zaretskii , dmantipov@yandex.ru, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 25 22:24:34 2014 Return-path: Envelope-to: ged-emacs-devel@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 1Wztk6-0001gN-U4 for ged-emacs-devel@m.gmane.org; Wed, 25 Jun 2014 22:24:31 +0200 Original-Received: from localhost ([::1]:40876 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wztk6-0004Eb-Cr for ged-emacs-devel@m.gmane.org; Wed, 25 Jun 2014 16:24:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49510) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wztjv-0004Ay-Rh for emacs-devel@gnu.org; Wed, 25 Jun 2014 16:24:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wztjo-0000SV-DK for emacs-devel@gnu.org; Wed, 25 Jun 2014 16:24:19 -0400 Original-Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:44436 helo=brightrain.aerifal.cx) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wztjh-0000RZ-JO; Wed, 25 Jun 2014 16:24:05 -0400 Original-Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1Wztjf-0005BI-00; Wed, 25 Jun 2014 20:24:03 +0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 216.12.86.13 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:172727 Archived-At: On Wed, Jun 25, 2014 at 04:06:33PM -0400, Stefan Monnier wrote: > > Since emacs is processing lots of potentially untrusted data, PIE > > hardening may be beneficial for hardening against vulnerabilities > > IIUC what you mean by PIE, it requires a dumped Emacs where the position > of the (pre-filled) heap can change at every invocation. If so, that > means relocation of all the pointers in the heap, at startup. With the approach of dumping a C array containing references to offsets within itself, this is completely transparent to the application. The linker (ld) produces the right R_${ARCH}_RELATIVE relocation records in the data segment and the dynamic linker applies them at runtime. > I had the impression you didn't want such relocation-at-startup (since > you used it as an argument against XEmacs-style dumping into a separate > heap file). I didn't mean for that to be "an argument against XEmacs-style dumping" since the XEmacs style is still much better than what GNU emacs has now, simply an observation that it's not the ideal system. Rich