From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) by sourceware.org (Postfix) with ESMTPS id EEED838930DF for ; Mon, 24 May 2021 19:11:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EEED838930DF Received: by mail-qk1-x734.google.com with SMTP id i5so20816809qkf.12 for ; Mon, 24 May 2021 12:11:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=LxEBgqa6dlB+ImsRm0oIouPY81QKZN5REmbOyQYzboY=; b=bSVnYGZ9kO0/aV2wVBAS83YO+/XWPyrRmulFKZ1WUaVs72f3d1rIOwX0uqI764Vtqr gwAac75QkmrSZifggqOPhBbqiga4WTqAATccf3PTL0mYILpZmfW02t2amFgdg2riEIgn 8qPyRdPS6iwAnPPSrx2JO6xsS20QbsZfhhHbFtgp3kRKgmmEDUwmgKy5ehZZPVHjzB4K 00oozBI+uvZTnSPcywJUlxou90KjoiCf2lORUd67G1VtkXica0+z/l++1HuQd18QOvAw r5Iew1SifhL6gVSR0RthdL/PA4wXTuCRDVujteenbBwLy7TyfLDfrojmjhl+XbLRtQ5C hEYw== X-Gm-Message-State: AOAM530YuV0uRsVnGqNyFB1Zyurqag7Ac4yOu1QmUm2EZLQkuDAQpGQi JuWhqGEmqqI/JbVwfjf0TXH05yDE53eqJA== X-Google-Smtp-Source: ABdhPJyf9zmf0YdpFmFhMAY23yuu5+5GEZ/72a12CQZJduV4OgG2vXIT8sQUNPmHN0B0Fg8dGkf1Hw== X-Received: by 2002:a37:a454:: with SMTP id n81mr30114341qke.302.1621883467284; Mon, 24 May 2021 12:11:07 -0700 (PDT) Received: from [192.168.1.4] ([177.194.37.86]) by smtp.gmail.com with ESMTPSA id x28sm11244713qtm.71.2021.05.24.12.11.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 24 May 2021 12:11:07 -0700 (PDT) Subject: Re: [PATCH 3/3] Misc: Add and the cstack_* family of functions To: Bruno Haible , Florian Weimer , libc-alpha@sourceware.org References: <73724441.XAIsEQcG03@omega> From: Adhemerval Zanella Message-ID: <146fa4f0-ea19-fdc4-a05c-74008bb4ab5f@linaro.org> Date: Mon, 24 May 2021 16:11:04 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <73724441.XAIsEQcG03@omega> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2021 19:11:11 -0000 On 24/05/2021 11:58, Bruno Haible wrote: > In reply to : > >> These functions are expected to be used with sigaltstack and >> coroutines. > > What is the added value of these functions, compared to what existing > programs already do? > > I did a small survey of how a couple of single-threaded programs allocate > their alternate stack: > - The majority allocate it statically. > - Some use malloc(). > - Some use mmap(). > - Some use alloca(), i.e. a portion of the already-allocated stack in > the program's main() function. > The size that these programs use are: > - some use SIGSTKSZ, > - some use 16 KiB, > - some use 64 KiB. > > We know that 16 KiB is too small on some platforms, and that a static > allocation of SIGSTKSZ bytes leads to a compilation error now. > > Therefore the implemented added value is: > > * The ability to use SIGSTKSZ without a compilation error. > > Other added value that would be useful in some cases are: > > * The ability to have a guard page at the stack top. > This is half implemented. IMO an mprotect (.., top_guard_size, PROT_NONE) > is missing after the __mmap call. > > * The ability to have a guard page at the stack bottom. > This too is half implemented. IMO an mprotect (.., bottom_guard_size, PROT_NONE) > is missing after the __mmap call. I think both point are resolved in the v2 [1] > > * A verification that the allocated size is not larger than > getrlimit(RLIMIT_STACK). If the system or the user has set a maximum > stack size of, say, 8 MB, should the program be able to allocate a > stack of 1 GB size, in this way? My vier is this is similar to users provides pthread_attr_setstack. The RLIMIT_STACK is useful to define *default* values, I don't see much gain in enforcing it on this API that does not correlate directly with it. > > * Support for GCC nested functions, when they need an executable stack. > GCC, binutils, and glibc/nptl/allocatestack.c go to great lengths to > support this, even from dynamically loaded shared libraries. (See the > attached test cases.) It is poor if this facility does not support it. This is explicit stated on the documentation Florian has added on the v2 of this patchset: | Allocated stacks are not explicitly allocated with executable memory | even if the current process image uses an executable stack. The | stacks can still be executable for other reasons, e.g., lack of | hardware support for non-executable stacks. I think we should make non-executable stack as default, the nested function requirement is a security can of worms and if user really want they can mprotect the required stack explicit. If this is really a requirement, I think the best options would be to add an extra flag to opt-in. > > * Automatic deallocation when the current thread exits. > In those cases where a thread allocated a cstack_t for its own use, > it is welcome if it can say "clean it up automatically when the thread > exits". Otherwise some programmers will still prefer the "use alloca()" > approach, which has this automatic cleanup property. The cstack_t is basically another heap object and I think it should be handled as such. And I think pthread_attr_setstacksize fits what your are describing, minus the guard page for *both* ends. > It would be useful to have this feature on the thread stacks, in the > first place. That is, add some pthread_attr_setbottomguard() function > to that allows the application to enable this for the > thread stacks. We might need another API to set the bottom guard size as well, and maybe depending of the architecture enabled it by default (for 64-bit as least). It might occur in some extra overhead, specially on aarch64 witch sets the ARCH_MIN_GUARD_SIZE as 64k. > > Bruno > [1] https://patchwork.sourceware.org/project/glibc/list/?series=2208