Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752685AbdGEMWX (ORCPT ); Wed, 5 Jul 2017 08:22:23 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:56624 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750909AbdGEMWW (ORCPT ); Wed, 5 Jul 2017 08:22:22 -0400 Message-ID: <1499257314.2707.36.camel@decadent.org.uk> Subject: Re: [PATCH] mm: larger stack guard gap, between vmas From: Ben Hutchings To: Willy Tarreau , Michal Hocko Cc: Linus Torvalds , Hugh Dickins , Oleg Nesterov , "Jason A. Donenfeld" , Rik van Riel , Larry Woodman , "Kirill A. Shutemov" , Tony Luck , "James E.J. Bottomley" , Helge Diller , James Hogan , Laura Abbott , Greg KH , "security@kernel.org" , linux-distros@vs.openwall.org, Qualys Security Advisory , LKML , Ximin Luo Date: Wed, 05 Jul 2017 13:21:54 +0100 In-Reply-To: <20170705081443.GA23453@1wt.eu> References: <1499126133.2707.20.camel@decadent.org.uk> <20170704084122.GC14722@dhcp22.suse.cz> <20170704093538.GF14722@dhcp22.suse.cz> <20170704094728.GB22013@1wt.eu> <20170704104211.GG14722@dhcp22.suse.cz> <20170704113611.GA4732@decadent.org.uk> <1499209315.2707.29.camel@decadent.org.uk> <20170705063645.GA10354@dhcp22.suse.cz> <20170705081443.GA23453@1wt.eu> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-Rozx0xXYGSRobsiRGj5j" X-Mailer: Evolution 3.22.6-1 Mime-Version: 1.0 X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2280 Lines: 54 --=-Rozx0xXYGSRobsiRGj5j Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2017-07-05 at 10:14 +0200, Willy Tarreau wrote: > On Wed, Jul 05, 2017 at 08:36:46AM +0200, Michal Hocko wrote: > > PROT_NONE would explicitly fault but we would simply > > run over this mapping too easily and who knows what might end up below > > it. So to me the guard gap does its job here. >=20 > I tend to think that applications that implement their own stack guard > using PROT_NONE also assume that they will never perfom unchecked stack > allocations larger than their own guard, thus the condition above should > never happen. Otherwise they're bogus and/or vulnerable by design and it > is their responsibility to fix it. >=20 > Thus maybe if that helps we could even relax some of the stack guard > checks as soon as we meet a PROT_NONE area, allowing VMAs to be tightly > packed if the application knows what it's doing. That wouldn't solve > the libreoffice issue though, given the lower page is RWX. How about, instead of looking at permissions, we remember whether vmas were allocated with MAP_FIXED and ignore those when evaluating the gap? Ben. --=20 Ben Hutchings Anthony's Law of Force: Don't force it, get a larger hammer. --=-Rozx0xXYGSRobsiRGj5j Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAllc2eIACgkQ57/I7JWG EQlUkg//X0LqH9EZzEGvYx9GUbZtr6BVuyTZDDIIZZX4o/j7KRjOOiCVIDSO5rTG NzpjdkSVDx9Sg1t7qtMcpGDNMD8IdGCmdz8xsfM4LIx3OvuAqJWau+3hQmrQJuNn S5o8Rr1WkXxNWGyhRHe3uuwXiWwNfiSg4NHyGPyalVfsKY87NGuuffZL7KoKKTrI l15AGlRazjYI4GpwyX0hth3baK0AA6Mj476FE7KvcWjkYhGWPGtcsRs2KXgTsg1q 9+86Fn9Sm0pmxs/BjwFyPYizjx6egxneazOvjqJThlpJZ8aYX5l0k6+37JomuwO6 rSgarW/ZxHifHDvEEfefKf7PfqMPGHsq0TdnAxRDZIJWky0GrMzzIvZH9j8q3ZF1 8m+7pnGraAxYDLKKz7DDgXT3IxQWbZ6SuIxftgHNhbdTDu6uQJJL3DzREzFzAe0d nCbxqp8Zd+Z/57tvongITR0X0WAxIgRGI3harF1ntIcRjXERLlcs7Tvuw8ajUNqA ogdE8HK/Q+USyGJpvD1LIpzkz5+DN10PccyW2a1mFiToR1LTDcKFHIFz4LCz2aV1 SrF3zVyHT7DbFO7zdUMr4roTFHHAm0ov2KvcTucElLt2XSo8OPIaYHP5ARGCI0RC RwKbEESUthO4GCCVks3nMV1zNvAXs80eVvnR1rygsSQ07w+MSms= =cPkP -----END PGP SIGNATURE----- --=-Rozx0xXYGSRobsiRGj5j--