From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117749 invoked by alias); 29 Nov 2017 20:33:29 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 117723 invoked by uid 89); 29 Nov 2017 20:33:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=BAYES_00,KB_WAM_FROM_NAME_SINGLEWORD,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=held, site, documents X-HELO: mx1.redhat.com Subject: Re: [RFC] nptl: change default stack guard size of threads To: Rich Felker , Carlos O'Donell Cc: Szabolcs Nagy , GNU C Library , nd@arm.com, Jeff Law , Richard Earnshaw , Wilco Dijkstra , James Greenhalgh References: <5A1ECB40.9080801@arm.com> <76c38ecf-6497-c96c-5c8c-95cceed100a5@redhat.com> <20171129182909.GE1627@brightrain.aerifal.cx> From: Florian Weimer Message-ID: Date: Wed, 29 Nov 2017 20:33:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171129182909.GE1627@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2017-11/txt/msg01014.txt.bz2 On 11/29/2017 07:29 PM, Rich Felker wrote: > On Wed, Nov 29, 2017 at 10:16:54AM -0800, Carlos O'Donell wrote: >> On 11/29/2017 07:18 AM, Florian Weimer wrote: >>> On 11/29/2017 03:59 PM, Szabolcs Nagy wrote: >>>> The change can be made for aarch64 only >>> >>> That doesn't seem to be the case, looking at the patch. >>> >>> So what you intended to do, exactly? >>> >>> A 64 KiB probe interval on legacy 32-bit architectures is really a >>> no-go. It means we have to increase the guard region size to 64 KiB. >>> But we cannot do that: The guard allocation comes out of the overall >>> thread stack size, and existing applications do not expect that 60K >>> of configured stack suddenly becomes unavailable. Adding the guard >>> size on top of the allocation will break setups which are carefully >>> tuned for a maximum number of threads. >> >> We cannot be held to account for carefully tuned applications, such >> applications have to be tuned again for newer glibc. >> >> I think we *could* do this for 64-bit and 32-bit AArch64/ARM, but I >> don't see the value in doing it for 32-bit. > > If 64k guard is mandatory for safety against jumping over the guard > zone, then I don't think it's possible to "re-tune" 32-bit apps for > the new requirement. This imposes a relatively small limit on possible > number of threads the process can create. With the probing implementations I have seen so far, it is feasible technically because a probe will never touch a stack area which could not conceivably be touched by a signal handler, too. But it is still a bad situation when GCC documents that it is only providing full protection with guard size X, and you decide to run with size X/16 to actually get things going. This means that your configuration is out of scope what your vendor will support security-wise, and probably non-compliant with applicable guidelines at the user site. So technically you can run with a smaller guard size, but it's still impractical to do so for most organizations. Thanks, Florian