Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752042AbdGEQGF (ORCPT ); Wed, 5 Jul 2017 12:06:05 -0400 Received: from mail-oi0-f48.google.com ([209.85.218.48]:36802 "EHLO mail-oi0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751444AbdGEQGD (ORCPT ); Wed, 5 Jul 2017 12:06:03 -0400 MIME-Version: 1.0 In-Reply-To: <1499257314.2707.36.camel@decadent.org.uk> 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> <1499257314.2707.36.camel@decadent.org.uk> From: Linus Torvalds Date: Wed, 5 Jul 2017 09:06:01 -0700 X-Google-Sender-Auth: -d0eh7_yMYdHwIRgVNy_N1gYvn8 Message-ID: Subject: Re: [PATCH] mm: larger stack guard gap, between vmas To: Ben Hutchings Cc: Willy Tarreau , Michal Hocko , 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" , Qualys Security Advisory , LKML , Ximin Luo Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 889 Lines: 23 On Wed, Jul 5, 2017 at 5:21 AM, Ben Hutchings wrote: > > How about, instead of looking at permissions, we remember whether vmas > were allocated with MAP_FIXED and ignore those when evaluating the gap? No, I think that's a bad idea. There's tons of good reasons to use MAP_FIXED, and real programs do it all the time. I'd much rather just do something special for the Java case, either recognizing that particular pattern, or (and this is likely what we'll have to do) just have a per-process stack limit that (a) will be reset by suid transitions etc security boundaries (b) you can just set back to 4kB for the specific Java case. because I'd rather make this be a very conscious thing rather than a random hack. The PROT_NONE thing made tons of conceptual sense ("let people do their own guard mappings"). The MAP_FIXED thing does not. Linus