From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 3D3983857343 for ; Thu, 21 Apr 2022 14:44:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3D3983857343 Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-53-5XKFk6ntN0q8Trs-syP8Kg-1; Thu, 21 Apr 2022 10:44:23 -0400 X-MC-Unique: 5XKFk6ntN0q8Trs-syP8Kg-1 Received: by mail-wr1-f71.google.com with SMTP id h61-20020adf9043000000b002079bbaa5d3so1216758wrh.16 for ; Thu, 21 Apr 2022 07:44:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:subject:in-reply-to :content-transfer-encoding; bh=Sz84hk1YOn2x+6CG7UQmsQZsEaNy2w+M8OJq6MH8zAg=; b=Za6mGcoruq3nETH0Zc9tq0Q2Tykh2/qyneg7DqEl5KCLdt30EqMrxIbkW52LRqCOr3 gAwEoRNuVr5mME+c5P5QzN8Ot8o0stF5vP9qHi9Cq0ReV35nXoRf3mWob8B7FwaygIIf h5ej70lZ8w6JEkBjoiwAHnenBmgM2ai1Mg6hsiLPHAnMn/G8APdLLf237PV3PUv27vPV ZT4+rDZI7Bub2K/eYGM/sqhGT+4GlLRDm8YXbzCfupwpJW9StyHOYYP16rVgpUg8ZThz oVBomrkptkuR5ue41eMpS3aErZcfIuCrZXtRNXAEc/PN6L/NqHQU4Bv6Rx7YFHUf4/E6 NiXg== X-Gm-Message-State: AOAM533z+MLjj8RFaYio7VxdJyllylhDKDBxkKjdxst2IK+lB4+3J75y YnsSe30eCd9fZbXbD5/e/ZruJXWXKz1jomg0Xo1oSfbsZheKGKtj37b5XmolxFC+D85SRdsuOLK 674L2BJXKOTgH5ZWbxA== X-Received: by 2002:adf:d1e1:0:b0:20a:c41e:98b7 with SMTP id g1-20020adfd1e1000000b0020ac41e98b7mr35969wrd.465.1650552261909; Thu, 21 Apr 2022 07:44:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx5gPfche4n5J9HvvGf+f+SCRCwfHbxLmtdY25KQ+g6HD41QfbmMR5fKy/JEbekC45ToBudpg== X-Received: by 2002:adf:d1e1:0:b0:20a:c41e:98b7 with SMTP id g1-20020adfd1e1000000b0020ac41e98b7mr35959wrd.465.1650552261667; Thu, 21 Apr 2022 07:44:21 -0700 (PDT) Received: from [192.168.1.6] (adsl-2-solo-173-39.claranet.co.uk. [80.168.173.39]) by smtp.gmail.com with ESMTPSA id n7-20020a5d5987000000b0020aaba99b4asm3344040wri.72.2022.04.21.07.44.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Apr 2022 07:44:21 -0700 (PDT) Message-ID: Date: Thu, 21 Apr 2022 15:44:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 To: Jan Beulich Cc: Binutils References: <51664b3e-9dbd-65e2-00b3-7f7842f76ed4@redhat.com> <3233e8f4-4baa-9cb7-c86e-a60e8f7116f4@suse.com> From: Nick Clifton Subject: Re: RFC: Should we have all targets default to only creating an executable stack when explicitly requested ? In-Reply-To: <3233e8f4-4baa-9cb7-c86e-a60e8f7116f4@suse.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2022 14:44:26 -0000 Hi Jan, >> A proposal has been made that all targets should ignore missing >> .note.GNU-stack sections, and the linker should only ever create an >> executable stack if explicitly requested by one of the two methods >> described in the second paragraph. > > I know of such an application right away. It being used merely for testing > purposes, I believe it's okay-ish to have an executable stack. Does the application link with "-z execstack" ? If not, why not ? Just curious really. I want to know if there are likely to be other apps out there that use executable stacks, but do not explicitly request the feature from the linker. > Hence I'd like to suggest that for > at least one (better two or three) major releases there be merely a warning > that the behavior will change, giving people time to silence the warning > while being able to continue to do their immediate work. Yeah - after thinking about this a bit more, I agree with you. I think that the best thing to do for now would be to extend the new warning message about automatically created execstacks so that it also says that the feature is going to be deprecated and then make the change in a couple of releases time. Cheers Nick