From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) by sourceware.org (Postfix) with ESMTPS id F084B3938C26 for ; Tue, 25 May 2021 12:25:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F084B3938C26 Received: by mail-qv1-xf31.google.com with SMTP id a7so11536640qvf.11 for ; Tue, 25 May 2021 05:25:09 -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:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=eFQfqMZ4VLfCQwELa4n8sRrXe6GF3kZKgS7X04wvze0=; b=XE8jm8IJ/YumGDSVjzHo4mofxxtjR2oznlXjScnQx1jYowQi2nlzo20w33mlh78vfe JG0+2d/RFZaFns6TO3eMSgCc+kdBa/PiLHQ7786fYCRSx2So03AGaUdVof6jmuZGdpUb IhKXZIXyDppAqm4EmKOwTzIMacb30jZ7uXA85tx/sadqfM+swfjQW4dI5EozNluQQZLi UHosj3CQUPeXHoEbJ1IcvEfo6KYOEDziiHVj6UyXOecFAFD/dn22cAq6kiAeiGc+h/l1 Jnu8iJy30sNjyUnAEJsxYCPKOKZkfg67BtXyyTA/bBpzrwsp4ofOjUY+EyfjGDBIjD6w e6Ow== X-Gm-Message-State: AOAM532a+Jar8fiztYPWbiNQ040Cu6nrho2z4qGhqIJMBQgFS43vMjKP gPjayV/WUv3E37+fmBoK19sBnA== X-Google-Smtp-Source: ABdhPJyridCE+DFwi0UbYdf9ah4ce2Zsq2ErxPkm8i1JmlvLRA2j/o+PjOVP2CZE1YaF9soagSuaAA== X-Received: by 2002:a05:6214:18d:: with SMTP id q13mr36233626qvr.60.1621945509560; Tue, 25 May 2021 05:25:09 -0700 (PDT) Received: from [192.168.1.4] ([177.194.37.86]) by smtp.gmail.com with ESMTPSA id j9sm12452344qtl.15.2021.05.25.05.25.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 May 2021 05:25:09 -0700 (PDT) Subject: Re: [PATCH 3/3] Misc: Add and the cstack_* family of functions To: Florian Weimer Cc: Paul Eggert , libc-alpha@sourceware.org, Bruno Haible References: <73724441.XAIsEQcG03@omega> <146fa4f0-ea19-fdc4-a05c-74008bb4ab5f@linaro.org> <87tumr1csv.fsf@oldenburg.str.redhat.com> <04c9457b-6d48-ca15-788c-da6de5d4abfc@linaro.org> <8735ub0zq1.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Message-ID: <4cf86a2e-39d2-7d21-a79f-b757e2aa1793@linaro.org> Date: Tue, 25 May 2021 09:25:06 -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: <8735ub0zq1.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 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: Tue, 25 May 2021 12:25:11 -0000 On 25/05/2021 09:23, Florian Weimer wrote: > * Adhemerval Zanella: > >> On 25/05/2021 04:40, Florian Weimer wrote: >>> * Paul Eggert: >>> >>>> On 5/24/21 12:11 PM, Adhemerval Zanella via Libc-alpha wrote: >>>> >>>>> If this is really a requirement, I think the best options would be to add >>>>> an extra flag to opt-in. >>>> >>>> Opt-in works for me. Although the GNU apps I help maintain typically >>>> don't have nested functions, nested functions are a longstanding GNU C >>>> feature and are a good thing to have when you need them. >>> >>> Since the requirement for non-executable stacks does not encapsulate >>> well, I'd rather make this automatic if you think executable stack >>> support is required. (The code allocating the stack might not know >>> about the trampolines.) >> >> Although honoring PT_GNU_STACK seems the most straightforward I still >> think we should make it a opt-in, executable stacks has strong security >> implications and I think it is better the caller knows it is enabling. > > The caller may not know whether signal handlers need executable stacks, > though. That's what I meant with the lack of encapsulation. Yes I understood it, that's why I state is the most straightforward. However this is a newer API, we don't really need to keep compatibility to old binaries as the drive here. We can move away from bad API decisions.