From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 25565C19F2A for ; Thu, 4 Aug 2022 16:18:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235164AbiHDQSE (ORCPT ); Thu, 4 Aug 2022 12:18:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36998 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232087AbiHDQSD (ORCPT ); Thu, 4 Aug 2022 12:18:03 -0400 Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6466533E2A for ; Thu, 4 Aug 2022 09:18:02 -0700 (PDT) Received: by mail-pj1-x1036.google.com with SMTP id b4so187987pji.4 for ; Thu, 04 Aug 2022 09:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=CoYaedw+lAJX94EUMIqZNcixB4zlifv7m7f02NP8udU=; b=1tdGe1QZsuD/5c0Y+OIBaog3p5SfDXhzqTMQxQoywmPz3bnf0v1P5rqBIy34GVYh8q rWQEoPYreFCRtSzdD6ZKFJ8Sw1r99OuhPrQM9z96rcSCQWQoZ8+WTB3ST4nQmGiHngNW +djSylA7HAlqkakgXyNz25AWEYiyP1LnAT7OjHSHG8Rd++oiWfkrPY77MUsrstsX/1l2 7Y0yVJrseVjp/qbL5Iq2ip7Pg3oVMOf5yPVBaCtGU8YG9t7E5MinPz2HCkbLmWNlXkXK 6/nxr1FD9Me2V0BAT67x1k1k/4teJ5iVinjZ2Ci6eSYDqd2DChJ6jpaLquuHLT5LtoEt T6yg== 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:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=CoYaedw+lAJX94EUMIqZNcixB4zlifv7m7f02NP8udU=; b=eJ8FC+hcNn7R6h7ViCDjRrhkQooGKBUjmP2u/51CUtPrXIShLbc5soBceYhxHL1Qmq riG4j0JKaFkRwL4IPT07u+WBwAA5MhMNITDS+c+D/ErrLAPf/Z6ekVXvCUCC4ALqrlQY 9uhm1AyyLd+fKohERMHRleE7VpZEC5FFX+yNE3x1rq+N6fYCdL1gJ8r6L4KyHjlTaOUq wnAD198chKVDohOwqLcimGcIqUZmub/AsHntZm8hKvpJOm8JBTLr8JgoXiAfV5NC1eBl 9oDc6sXpTjnbrmUlbf5MK5wJ9PZ+EYq8DzUgiCvETwQMoU823YIuLc4xvc/zgUHUK5AX +b4g== X-Gm-Message-State: ACgBeo3PZ2cceHLPzVTTBX7PNTm1TnX7Sf7E0sSclUR/B6TG4+RW9JJR Vf0NZiTLRz7viQWay0BpJq3YVQ== X-Google-Smtp-Source: AA6agR6xKDJ05PHUxroFDJ0Ib0IZ+CY0dZu6jmD/5zExLoSQ5H5+qY8ciJNvg1AjV1dip5s7gwZjdg== X-Received: by 2002:a17:90a:d783:b0:1f4:e30b:ece with SMTP id z3-20020a17090ad78300b001f4e30b0ecemr2918019pju.165.1659629881743; Thu, 04 Aug 2022 09:18:01 -0700 (PDT) Received: from [192.168.1.100] ([198.8.77.157]) by smtp.gmail.com with ESMTPSA id d138-20020a621d90000000b0052d82ce65a9sm1194474pfd.143.2022.08.04.09.18.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Aug 2022 09:18:01 -0700 (PDT) Message-ID: <69b3bb50-e07f-cd7d-ff10-01856dd50053@kernel.dk> Date: Thu, 4 Aug 2022 10:17:59 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [GIT PULL] Block driver changes for 5.20-rc1 Content-Language: en-US To: Nick Desaulniers Cc: Linus Torvalds , Mark Rutland , Josh Poimboeuf , Peter Zijlstra , Jiri Slaby , Keith Busch , Christoph Hellwig , Sagi Grimberg , Hannes Reinecke , "linux-block@vger.kernel.org" , linux-toolchains , Nick Clifton References: <87f60512-9242-49d1-eae1-394eb7a34760@kernel.dk> <7d663c1a-67a2-159e-3f93-28ec18f3bd9d@kernel.dk> <38164718-0f09-76e5-a21d-2122613cdf73@kernel.dk> <2ae97675-383b-c2c7-9bed-6a9a55ce64f1@kernel.dk> <3af4127a-f453-4cf7-f133-a181cce06f73@kernel.dk> <552201a1-2248-b16e-1118-54373531a158@kernel.dk> <65d2a122-ef68-a6bc-44e8-bb21ad7b9255@kernel.dk> From: Jens Axboe In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On 8/3/22 12:06 PM, Nick Desaulniers wrote: >> ld: warning: arch/x86/boot/compressed/efi_thunk_64.o: missing .note.GNU-stack section implies executable stack >> ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker > > Right, arch/x86/boot/compressed (and arch/x86/boot/) discard/reset > KBUILD_AFLAGS (via the := assignment operator). > > So arch/x86/boot/Makefile and arch/x86/boot/compressed/Makefile also > will need changes similar to the one you did below. > > Finally, if those parts of the code actually expect the stack to be > executable (probably depends on some inline asm), I suspect we might > get some kind of fault at runtime (though I don't know how the kernel > handles segment permissions or even uses ELF segments). Point being > that -Wa,--noexecstack is somewhat a promise that we wont try to > execute data on the stack as if it were code. -Wa,--execstack is > useful if we need to be able to do so, but we should be careful to > limit that to individual translation units if they really truly need > that. The linker warning is more so about the current ambiguity since > if the implicit default changes in the future, that could break code. > Better for us to be explicit here, and disable executable stack unless > strictly necessary and only as necessary IMO. Personally, I think the > current implicit default is wrong, but pragmatically I recognize that > people have been used to the status quo for years, and changing it > could break existing codebases. > > If you send the below diff with the two other additions I suggest to > the x86 ML, the x86 maintainers might be able to comment if they're > familiar with any possible cases where the stack is expected to be > executable. I'd be happy for you to take this over, I'm really just the reporter here... -- Jens Axboe