From: Jens Axboe <axboe@kernel.dk>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Mark Rutland <mark.rutland@arm.com>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Jiri Slaby <jirislaby@kernel.org>,
Keith Busch <kbusch@kernel.org>, Christoph Hellwig <hch@lst.de>,
Sagi Grimberg <sagi@grimberg.me>, Hannes Reinecke <hare@suse.de>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
linux-toolchains <linux-toolchains@vger.kernel.org>,
Nick Clifton <nickc@redhat.com>
Subject: Re: [GIT PULL] Block driver changes for 5.20-rc1
Date: Thu, 4 Aug 2022 10:17:59 -0600 [thread overview]
Message-ID: <69b3bb50-e07f-cd7d-ff10-01856dd50053@kernel.dk> (raw)
In-Reply-To: <CAKwvOdmD10yK0r1H-M2PcnZgy3M0aA9gdkY0BErDOQ+KpBRxVQ@mail.gmail.com>
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
next prev parent reply other threads:[~2022-08-04 16:18 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-31 15:03 [GIT PULL] Block driver changes for 5.20-rc1 Jens Axboe
2022-08-02 21:18 ` Linus Torvalds
2022-08-02 21:33 ` Keith Busch
2022-08-02 21:35 ` Jens Axboe
2022-08-02 21:50 ` Linus Torvalds
2022-08-02 22:24 ` Jens Axboe
2022-08-02 22:26 ` Jens Axboe
2022-08-02 22:27 ` Linus Torvalds
2022-08-02 22:33 ` Jens Axboe
2022-08-02 22:48 ` Linus Torvalds
2022-08-02 22:59 ` Jens Axboe
2022-08-02 23:03 ` Linus Torvalds
2022-08-02 23:08 ` Jens Axboe
2022-08-03 15:16 ` Jens Axboe
2022-08-03 16:26 ` Linus Torvalds
2022-08-03 16:51 ` Nick Desaulniers
2022-08-03 16:53 ` Jens Axboe
2022-08-03 17:00 ` Linus Torvalds
2022-08-03 17:38 ` Nick Desaulniers
2022-08-03 17:45 ` Jens Axboe
2022-08-03 18:06 ` Nick Desaulniers
2022-08-04 16:17 ` Jens Axboe [this message]
2022-08-03 16:56 ` Linus Torvalds
2022-08-03 17:30 ` Christoph Hellwig
2022-08-03 17:42 ` Linus Torvalds
2022-08-03 17:49 ` Christoph Hellwig
2022-08-03 17:54 ` Linus Torvalds
2022-08-06 7:44 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=69b3bb50-e07f-cd7d-ff10-01856dd50053@kernel.dk \
--to=axboe@kernel.dk \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=jirislaby@kernel.org \
--cc=jpoimboe@redhat.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-toolchains@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=ndesaulniers@google.com \
--cc=nickc@redhat.com \
--cc=peterz@infradead.org \
--cc=sagi@grimberg.me \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.