Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752324AbdGEJQI (ORCPT ); Wed, 5 Jul 2017 05:16:08 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:54074 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750841AbdGEJQH (ORCPT ); Wed, 5 Jul 2017 05:16:07 -0400 Date: Wed, 5 Jul 2017 11:15:31 +0200 From: Willy Tarreau To: Michal Hocko Cc: Linus Torvalds , Ben Hutchings , 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 Subject: Re: [PATCH] mm: larger stack guard gap, between vmas Message-ID: <20170705091531.GA23526@1wt.eu> References: <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> <20170705082441.GC14538@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170705082441.GC14538@dhcp22.suse.cz> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1475 Lines: 31 On Wed, Jul 05, 2017 at 10:24:41AM +0200, Michal Hocko wrote: > > 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. > > Yes, this is what my patch does [1]. Or did I miss your point? Sorry you're right, I got my mind confused when looking at the libreoffice dump and for whatever reason ended up thinking we were just considering that page as part of the gap and not being a marker for the bottom. Never mind. > > That wouldn't solve the libreoffice issue though, given the lower page > > is RWX. > > unfortunatelly yes. We only have limited room to address this issue > though. We could add per task (mm) stack_gap limit (controlled either > via proc or prctl) and revert back to 1 page for the specific program > but I would be really careful to add some more hack into the stack > expansion code. Actually one option could be to have a sysctl causing a warning to be emitted when hitting the stack guard instead of killing the process. We could think for example that once this warning is emitted, the guard is reduced to 64kB (I think it was the size before) and the application can continue to run. That could help problematic applications getting fixed quickly. And in environments with lots of local users it would be dissuasive enough to avoid users trying their luck on setuid binaries. Just my two cents, Willy