public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: WANG Xuerui <i.swmail@xen0n.name>
To: Xi Ruoyao <xry111@xry111.site>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <i.swmail@xen0n.name>
Cc: Andreas Schwab <schwab@suse.de>,
	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:44:16 +0800	[thread overview]
Message-ID: <d97a7186-d450-dd4a-89bc-276191fb6b21@xen0n.name> (raw)
In-Reply-To: <6aad5dbfde855d450977ac9574de760d346b5c43.camel@xry111.site>

On 2022/7/25 17:22, Xi Ruoyao wrote:
> On Mon, 2022-07-25 at 17:18 +0800, Huacai Chen wrote:
>> 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.
> Hmm..  But how about LA32?
>
> "Non-eXecutable bit (NX), 1 bit. This bit is set when a fetch operation
> is not allowed on the address space where this page table entry is
> located. This control bit is only exist in LA64."

Good catch... In which case the predicate could look like "!cpu_has_nx". 
But the kernel is LA64-only at present, the ILP32 ABIs are not fully 
defined yet, and no LA32 cores are produced in large quantities, so just 
unconditionally disabling the predicate should cause no harm either. I 
think we'd go with the former approach then.


  reply	other threads:[~2022-07-25  9:44 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
2022-07-25  9:22           ` Xi Ruoyao
2022-07-25  9:44             ` WANG Xuerui [this message]
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=d97a7186-d450-dd4a-89bc-276191fb6b21@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).