From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailbox.box.xen0n.name (mail.xen0n.name [115.28.160.31]) by sourceware.org (Postfix) with ESMTPS id B06FF3858403 for ; Mon, 25 Jul 2022 09:44:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B06FF3858403 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=xen0n.name Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xen0n.name DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xen0n.name; s=mail; t=1658742256; bh=Y6qrDsUCF/9rSiU6BIcShN1hx4M0O6uDLw8ucjQQWJw=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Sl6xG/JF0dy4l/Owu0Lx2moLdI+PThI874fmv/onwFDj1rdSwAYOvmKjLZorm2Pxi Gy1IXF20JU5u9ojhgwXOI1yF0H7Bzd8CA921V6FVYTE2ld8RmlgYgSQX4IQJsRtglo 6f4mC5+MBnyMsywwSzM8pG2agvrQPi3uqmQCI0Qo= Received: from [100.100.35.250] (unknown [58.34.185.106]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mailbox.box.xen0n.name (Postfix) with ESMTPSA id 72AB760104; Mon, 25 Jul 2022 17:44:16 +0800 (CST) Message-ID: Date: Mon, 25 Jul 2022 17:44:16 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:104.0) Gecko/20100101 Thunderbird/104.0a1 Subject: Re: [PATCH] LoongArch: Set defaults to exec stack 0. Content-Language: en-US To: Xi Ruoyao , Huacai Chen , WANG Xuerui Cc: Andreas Schwab , maskray@google.com, caiyinyu@loongson.cn, Xu Chenghua , liuzhensong , binutils@sourceware.org, chenglulu@loongson.cn References: <20220725022227.16266-1-liuzhensong@loongson.cn> <4a264fe57282c1a191204775ffe033512240d2eb.camel@xry111.site> <32a2cb15-adf7-7f31-8682-f47728c83953@xen0n.name> <6aad5dbfde855d450977ac9574de760d346b5c43.camel@xry111.site> From: WANG Xuerui In-Reply-To: <6aad5dbfde855d450977ac9574de760d346b5c43.camel@xry111.site> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2022 09:44:22 -0000 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 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.