From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115221 invoked by alias); 17 Jul 2017 15:31:56 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 115207 invoked by uid 89); 17 Jul 2017 15:31:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:1500, thousands, our X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Jul 2017 15:31:54 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7083AC04B31B; Mon, 17 Jul 2017 15:31:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7083AC04B31B Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jakub@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 7083AC04B31B Received: from tucnak.zalov.cz (ovpn-116-143.ams2.redhat.com [10.36.116.143]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EFD9A5D9C1; Mon, 17 Jul 2017 15:31:52 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id v6HFVo5l000689; Mon, 17 Jul 2017 17:31:50 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id v6HFVm2l000688; Mon, 17 Jul 2017 17:31:48 +0200 Date: Mon, 17 Jul 2017 15:31:00 -0000 From: Jakub Jelinek To: Jeff Law Cc: Wilco Dijkstra , GCC Patches , nd Subject: Re: [PATCH][RFA/RFC] Stack clash mitigation patch 07/08 Message-ID: <20170717153148.GJ2123@tucnak> Reply-To: Jakub Jelinek References: <5eb3783f-7a00-1361-461e-92b99bcb338b@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5eb3783f-7a00-1361-461e-92b99bcb338b@redhat.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes X-SW-Source: 2017-07/txt/msg00983.txt.bz2 On Mon, Jul 17, 2017 at 09:24:27AM -0600, Jeff Law wrote: > >> While I'm not really comfortable with the 2k/2k split in general, I > >> think I can support it from a Red Hat point of view -- largely because > >> we use 64k pages in RHEL. So our guard is actually 64k. Having a > >> hostile call chain push 2k into the guard isn't so bad in that case. > > > > A minimum guard size of 64KB seems reasonable even on systems with > > 4KB pages. However whatever the chosen guard size, you cannot defend > > against hostile code. An OS can of course increase the guard size well > > beyond the minimum required, but that's simply reducing the probability - > > it is never going to block a big unchecked alloca. > That's a kernel issue and I'm not in a position to change that. On > systems with a 64bit address space, I'm keen to see the kernel team > increase the guard size, but it's not something I can unilaterally make > happen. That is actually not true. Kernel issue it is only for the initial thread's stack. For pthread_create created threads it is a matter how big the default guard size is (these days glibc uses a single page by default) and how many apps override that guardsize to something different (smaller including 0 or larger). And, while it might be acceptable to have larger guard size for the initial thread, if you have hundreds of thousands of threads, every extra KB in the guard areas will count significantly. Jakub