From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Two issues with stack overflow protection Date: Tue, 28 Jul 2015 23:10:45 -0700 Message-ID: <55B86E65.6030000@dancol.org> References: <838ua0xkln.fsf@gnu.org> <55B85E43.6050306@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pi9xNMgtMUvgmrj4N7qumsK4cPVJWrsn5" X-Trace: ger.gmane.org 1438150270 21875 80.91.229.3 (29 Jul 2015 06:11:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Jul 2015 06:11:10 +0000 (UTC) To: Paul Eggert , Eli Zaretskii , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 29 08:11:04 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 1ZKKZz-0006RH-To for ged-emacs-devel@m.gmane.org; Wed, 29 Jul 2015 08:11:04 +0200 Original-Received: from localhost ([::1]:33507 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKKZz-0003vV-20 for ged-emacs-devel@m.gmane.org; Wed, 29 Jul 2015 02:11:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41099) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKKZv-0003vE-6k for emacs-devel@gnu.org; Wed, 29 Jul 2015 02:11:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZKKZu-0000t0-55 for emacs-devel@gnu.org; Wed, 29 Jul 2015 02:10:59 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:43641) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKKZt-0000rt-Rb for emacs-devel@gnu.org; Wed, 29 Jul 2015 02:10:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=nwNTz/PDSqTELdFMeNr5VEJ7OZElbc7DqZkzQ6Ib/xE=; b=Sf8ufMkyyo4zvekd8Pl9QA/R59q0nioWmvNrQsHHt2vkAzD5ma/phh7d0PRd0OmjuqxGQ79FHQlqBXbdt0yR5oOTDHM2OcmW4J7CcGxe054a5/Xy7uEHeWd6bxvX5Ut4DRP9dAriEyNyZPkjsrdbS0BNMFjRBb1ns6hemjGkauwpKznc86kejkEY/EqYC1aoFrzkiqL84VS10x1kknI23K9v66Lrb5wWJXe9ZFVZYY7lKSJtTSyzLRj+zAhdQTXnR6nvgXNfwPbNjzs+E5nOAjRYPxvkLRaR+JXFuj6ljmROFmKBveKJWTDdo1655MYFuW2kbFpy4Lbl33ZZkY0CPw==; Original-Received: from [2620:10d:c081:1101:2ab2:bdff:fe1c:db58] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1ZKKZn-0003C7-LN; Tue, 28 Jul 2015 23:10:51 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 In-Reply-To: <55B85E43.6050306@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:188159 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pi9xNMgtMUvgmrj4N7qumsK4cPVJWrsn5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/28/2015 10:01 PM, Paul Eggert wrote: > Eli Zaretskii wrote: >> The implementation of stack_overflow on sysdep.c was recently changed >> so as not to use sys/resource.h and getrlimit, but configure.ac still >> insists on these two features in order to include the recovery code, >> which I think should be fixed. >=20 > Thanks, fixed with the attached patch. >=20 >> More importantly, the recovery simply longjmps to command_loop, >> whereas similar features like Fthrow and Fsignal do much more in >> unwind_to_catch. Shouldn't stack overflow recovery do that as well? >> Otherwise, the specpdl stack, byte_stack_list, lisp_eval_depth >> etc. all stay at their values they had at stack overflow time, no? >=20 > No, they are cleared back to top-level values, because when > command_loop's call to sigsetjmp returns nonzero, it then calls > init_eval and this resets them. >=20 > There is a problem that the speclpdl stack's unwind-protect and > dynamic-let-bindings are unceremoniously discarded on stack overflow. = I > suppose that should get fixed, though it may be a bit tricky to avoid > looping. 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? --pi9xNMgtMUvgmrj4N7qumsK4cPVJWrsn5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVuG5lAAoJEN4WImmbpWBl3H0P/A3YTVsJ4RiTHs448V4T3IIq yxEtYcFds3f6BpRCJplpDEbJvfWfdR61Kv7BshyFUG4hKuJ+KFZnQpMNeSnUVWfp 6iitzv6stWiiu17OoIhBO7MtDmi2opXa4ZsjwA2/lOc26rs/xBgdDQJhnEQFxsTx 9qb3KX2wXNv1wLFaBbUtgRrzOmLb5t1JkIHXD4S3Hzz0lhaTdkN0xoWAZYddAlLZ LOeBmT7sBRlMX2d/uMM1YepO9pmKgkuka9McOuS5WMLJ/l2nI4qSBvFjbzLREtZE KuRelL4lBMgGWjtPiK5/CrE0SM/7I1ZnYz2yGlF6W14uYdlE+5sKGcJ2G2v/UlgX tVvhJ6v1iXPk2woWgO1dV3JYE+2POXc/3gH+bliJ3Gs59EM+S13G+3h7dvkoEgX/ g6uWb4DwZxokKQcBfs32yEnsOFxm2W+mTmLRD/zg0PCN9SgEuqC9PQ4wVsUExL9w Vm2qZ8xDSNvGNYVW+OZ6cs3mUYzFpLx/4MwLLKUIMgCYUOv9XYKRDj6HnHvPlkWi 2DH+b6zDApTE7YmXYq5hC0KLxHty03fFyrglTy5YfS1PdmYT+cOm7hIO/RC5Mq0a ndSvPZrrCVzqAKHWIK+5ezQ9QsiPCRbROpgmGQBslzt6gC/y4PcBcyXo2wbkNg+c 2FdyFnVwoq2WkFCcWm5a =SP8w -----END PGP SIGNATURE----- --pi9xNMgtMUvgmrj4N7qumsK4cPVJWrsn5--