Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752297AbdGDShS (ORCPT ); Tue, 4 Jul 2017 14:37:18 -0400 Received: from mail-oi0-f53.google.com ([209.85.218.53]:35443 "EHLO mail-oi0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752200AbdGDShR (ORCPT ); Tue, 4 Jul 2017 14:37:17 -0400 MIME-Version: 1.0 In-Reply-To: <20170704172247.GA6178@dhcp22.suse.cz> References: <20170621092419.GA22051@dhcp22.suse.cz> <1498042057.2655.8.camel@decadent.org.uk> <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> <20170704155140.GC22013@1wt.eu> <20170704172247.GA6178@dhcp22.suse.cz> From: Linus Torvalds Date: Tue, 4 Jul 2017 11:37:15 -0700 X-Google-Sender-Auth: a_Ip6dHoCQeklUMXDBe6n0hR7s0 Message-ID: Subject: Re: [PATCH] mm: larger stack guard gap, between vmas To: Michal Hocko Cc: Willy Tarreau , 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 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: 1079 Lines: 24 On Tue, Jul 4, 2017 at 10:22 AM, Michal Hocko wrote: > > Well, I've been thinking about this some more and the more I think about > it the less I am convinced we should try to be clever here. Why? Because > as soon as somebody tries to manage stacks explicitly you cannot simply > assume anything about the previous mapping. Say some interpret uses > [ mngmnt data][red zone] <--[- MAP_GROWSDOWN ] > > Now if we consider the red zone's (PROT_NONE) prev mapping we would fail > the expansion even though we haven't hit the red zone and that is > essentially what the Java and rust bugs are about. So we just risk yet > another regression. Ack. Let's make the initial version at least only check the first vma. The long-term fix for this is to have the binaries do proper stack expansion probing anyway, and it's quite possible that people who do their own stack redzoning by adding a PROT_NONE thing already do that proper fix (eg the Java stack may simply not *have* those big crazy structures on it in the first place). Linus