From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Two issues with stack overflow protection Date: Wed, 29 Jul 2015 06:18:17 -0700 Organization: UCLA Computer Science Department Message-ID: <55B8D299.9010704@cs.ucla.edu> References: <838ua0xkln.fsf@gnu.org> <55B85E43.6050306@cs.ucla.edu> <55B86E65.6030000@dancol.org> <55B87B84.4000105@cs.ucla.edu> <55B8B899.8020508@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1438175963 14381 80.91.229.3 (29 Jul 2015 13:19:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Jul 2015 13:19:23 +0000 (UTC) To: Daniel Colascione , Eli Zaretskii , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 29 15:19:14 2015 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 1ZKRGK-0006ry-0p for ged-emacs-devel@m.gmane.org; Wed, 29 Jul 2015 15:19:12 +0200 Original-Received: from localhost ([::1]:35156 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKRGJ-0004FY-Ab for ged-emacs-devel@m.gmane.org; Wed, 29 Jul 2015 09:19:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58398) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKRFf-0003iE-Oq for emacs-devel@gnu.org; Wed, 29 Jul 2015 09:18:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZKRFb-0004Fu-Ua for emacs-devel@gnu.org; Wed, 29 Jul 2015 09:18:31 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:42966) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKRFX-0004E6-Jn; Wed, 29 Jul 2015 09:18:23 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id CDE27160728; Wed, 29 Jul 2015 06:18:22 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id XXoAAJQ_tUBv; Wed, 29 Jul 2015 06:18:22 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 21B3E160CB7; Wed, 29 Jul 2015 06:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GzAe0ImgMZu6; Wed, 29 Jul 2015 06:18:22 -0700 (PDT) Original-Received: from [192.168.1.9] (pool-100-32-155-148.lsanca.fios.verizon.net [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 03316160728; Wed, 29 Jul 2015 06:18:22 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 In-Reply-To: <55B8B899.8020508@dancol.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 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:188163 Archived-At: Daniel Colascione wrote: >>> What's wrong with just mprotecting a guard page at the end of the stack, >>> >>and on overflow, giving that region normal protection, unwinding as >>> >>normal, then, at top level, restoring the guard page? >> > >> >Unwinding can grow the stack. > Sure. That's why you open up more stack to do the unwinding. Having done > that, if you still overflow, just abort. Yes, that was my point. Emacs already does the business about the guard page, and opening up more stack, and so forth. The tricky part is the "if you still overflow, just abort", something that's easy enough to describe at the high level but perhaps not so easy to actually write the code. Part of the issue is that the guard page business is done under the covers by the OS, not by Emacs directly -- in general Emacs doesn't know where the guard page(s) are. I'm sure there are other issues that won't get discovered until someone actually writes and tests something. For example, here's something I just thought of: the conservative marking phase of the Emacs garbage collector may need to be taught about the split stack (currently it assumes the C stack is contiguous).