From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: `exec shield' test in configure too strict? Date: Thu, 7 Oct 2004 20:16:33 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <05038177-188D-11D9-821D-000D93505B76@swipnet.se> References: <20041004212031.GB2219@fencepost> <01c4ab96$Blat.v2.2.2$19340460@zahav.net.il> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1097173100 1220 80.91.229.6 (7 Oct 2004 18:18:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 7 Oct 2004 18:18:20 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 07 20:18:13 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CFcqD-0003mw-00 for ; Thu, 07 Oct 2004 20:18:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CFcww-0002bo-W3 for ged-emacs-devel@m.gmane.org; Thu, 07 Oct 2004 14:25:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CFcwg-0002bF-A8 for emacs-devel@gnu.org; Thu, 07 Oct 2004 14:24:54 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CFcwe-0002a5-32 for emacs-devel@gnu.org; Thu, 07 Oct 2004 14:24:52 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CFcwd-0002Zf-V7 for emacs-devel@gnu.org; Thu, 07 Oct 2004 14:24:51 -0400 Original-Received: from [195.54.107.73] (helo=mxfep02.bredband.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CFcor-0000td-Ay; Thu, 07 Oct 2004 14:16:49 -0400 Original-Received: from coolsville.localdomain ([213.115.28.241] [213.115.28.241]) by mxfep02.bredband.com with ESMTP id <20041007181647.YHRP27821.mxfep02.bredband.com@coolsville.localdomain>; Thu, 7 Oct 2004 20:16:47 +0200 In-Reply-To: Original-To: rms@gnu.org X-Mailer: Apple Mail (2.619) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 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 Xref: main.gmane.org gmane.emacs.devel:28052 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:28052 > Doesn't this harm cross-building Emacs? I always thought that > running > a test program at configure time should be avoided, and that tests > that only compile or link programs should be peferred. > > Yes, that is true. But maybe there is no way to test this > based on the compilation environment. As far as I know there isn't, the kernel controls this. If the personality of the process is PER_LINUX at startup and exec-shield is enabled, the randomizing of the heap start address is done by the kernel. > > When cross compiling the test obviously can not be run, so > configure > assumes > that the heap start address is not random. Come to think of it, > the old > test (checking /proc/sys/kernel/exec-shield) was worse, as it did > not > handle > cross compiling. > > That will be right most of the time today, but that may not be > true in the future. > > Can we modify unexec to handle this case correctly? What exactly is > it that we now do in the case where we see that exec shield is > enabled? How does that avoid the problem? We can modify unexec I think. Currently it memcpy:s the area from data start to sbrk(0) (heap end) into the new data area. But since there is a hole between BSS and heap start, an invalid memory range is accessed and we get a core dump: temacs Emacs ---------------------- ------------------ | Data | | | ---------------------- | | | BSS | | | ---------------------- =====> | Data | | 128-192 Mbyte hole | | | ---------------------- | | | Heap | | | ---------------------- ------------------ We could either just skip the hole and seek over it in the new data area, but then the Emacs binary would be large, as the 128-192 Mbyte is added to the Emacs binary size, but it has no purpose. Another possibility is to make a new data ELF section that contains the copied heap, and has the correct address. If this is feasible I don't really know, but I think it is (I am not an ELF expert). I previously thought that malloc needed modification, but apparently it can handle the new hole between Emacs data and the new random heap start address (Emacs has a zero sized BSS). Currently we run temacs like this % setarch i386 ./temacs ... setarch changes personality to PER_LINUX32 and then runs temacs. temacs inherits the changed personality, so the kernel does not randomize the heap start address. Jan D.