From: WANG Xuerui <i.swmail@xen0n.name>
To: Andreas Schwab <schwab@suse.de>, Xi Ruoyao <xry111@xry111.site>
Cc: maskray@google.com, caiyinyu@loongson.cn, xuchenghua@loongson.cn,
Huacai Chen <chenhuacai@kernel.org>,
liuzhensong <liuzhensong@loongson.cn>,
binutils@sourceware.org, chenglulu@loongson.cn
Subject: Re: [PATCH] LoongArch: Set defaults to exec stack 0.
Date: Mon, 25 Jul 2022 17:17:32 +0800 [thread overview]
Message-ID: <32a2cb15-adf7-7f31-8682-f47728c83953@xen0n.name> (raw)
In-Reply-To: <mvmedy9mvya.fsf@suse.de>
On 2022/7/25 16:35, Andreas Schwab via Binutils wrote:
> On Jul 25 2022, Xi Ruoyao wrote:
>
>> The doc of elf_backend_default_execstack says:
>>
>> /* True if an object file lacking a .note.GNU-stack section
>> should be assumed to be requesting exec stack. At least one
>> other file in the link needs to have a .note.GNU-stack section
>> for a PT_GNU_STACK segment to be created. */
>>
>> So I think it only controls the default behavior of bfd library and is
>> not related to the kernel?
> The kernel always controls the ultimate decision.
>
> It also means that if no input file has a GNU-stack note, no
> PT_GNU_STACK segment is created for the output, in which case the kernel
> default (which is PF_X for loongarch) applies.
>
> The value of DEFAULT_STACK_PERMS in glibc must also agree with the
> kernel.
>
Well, actually the kernel behavior seems to be overlooked during the
upstreaming process. No sane architecture in 2022 should have executable
stacks in the beginning.
We'll fix this before Linux 5.19 is released, fortunately there's the
rc8 giving us the chance. Compatibility should not be a problem, as no
modern program should rely on the incorrect behavior, and the new-world
is still not widely adopted (read: <50 installations worldwide) so any
breakage can be chased down and fixed.
Thanks very much for spotting this.
next prev parent reply other threads:[~2022-07-25 9:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-25 2:22 liuzhensong
2022-07-25 2:24 ` WANG Xuerui
2022-07-25 2:44 ` Xi Ruoyao
2022-07-25 7:51 ` Fangrui Song
2022-07-25 8:08 ` Andreas Schwab
2022-07-25 8:14 ` Xi Ruoyao
2022-07-25 8:35 ` Andreas Schwab
2022-07-25 9:17 ` WANG Xuerui [this message]
2022-07-25 9:18 ` Huacai Chen
2022-07-25 9:22 ` Xi Ruoyao
2022-07-25 9:44 ` WANG Xuerui
2022-07-30 19:20 ` WANG Xuerui
2022-08-01 1:10 ` liuzhensong
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=32a2cb15-adf7-7f31-8682-f47728c83953@xen0n.name \
--to=i.swmail@xen0n.name \
--cc=binutils@sourceware.org \
--cc=caiyinyu@loongson.cn \
--cc=chenglulu@loongson.cn \
--cc=chenhuacai@kernel.org \
--cc=liuzhensong@loongson.cn \
--cc=maskray@google.com \
--cc=schwab@suse.de \
--cc=xry111@xry111.site \
--cc=xuchenghua@loongson.cn \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).