From: Huacai Chen <chenhuacai@kernel.org>
To: WANG Xuerui <i.swmail@xen0n.name>
Cc: Andreas Schwab <schwab@suse.de>, Xi Ruoyao <xry111@xry111.site>,
maskray@google.com, caiyinyu@loongson.cn,
Xu Chenghua <xuchenghua@loongson.cn>,
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:18:55 +0800 [thread overview]
Message-ID: <CAAhV-H6NJPT2oSc7UaMmEYDVUQpYSGCjbENOpgBV3+5wEGxTvw@mail.gmail.com> (raw)
In-Reply-To: <32a2cb15-adf7-7f31-8682-f47728c83953@xen0n.name>
Hi, all,
On Mon, Jul 25, 2022 at 5:17 PM WANG Xuerui <i.swmail@xen0n.name> wrote:
>
> 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.
Thank you very much, I will fix this in kernel side.
Huacai
>
next prev parent reply other threads:[~2022-07-25 9:19 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
2022-07-25 9:18 ` Huacai Chen [this message]
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=CAAhV-H6NJPT2oSc7UaMmEYDVUQpYSGCjbENOpgBV3+5wEGxTvw@mail.gmail.com \
--to=chenhuacai@kernel.org \
--cc=binutils@sourceware.org \
--cc=caiyinyu@loongson.cn \
--cc=chenglulu@loongson.cn \
--cc=i.swmail@xen0n.name \
--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).