| Message ID | a40565807874c9ca82d60c118225ee65fe668fcd.1697614386.git.andrea.porta@suse.com |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org>
Delivered-To: ouuuleilei@gmail.com
Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id
ib8csp4713083vqb;
Wed, 18 Oct 2023 04:14:08 -0700 (PDT)
X-Google-Smtp-Source:
AGHT+IHOt9ynsoVwXZuuwIFHXW9d0MdbZXy07rAJjqzfHW7fULRQo75h55QNbU3rRIPEsrLu2TuV
X-Received: by 2002:a05:6e02:2145:b0:357:4253:c822 with SMTP id
d5-20020a056e02214500b003574253c822mr6317455ilv.3.1697627648634;
Wed, 18 Oct 2023 04:14:08 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1697627648; cv=none;
d=google.com; s=arc-20160816;
b=Uqb/+Xr4nFdI3DRR2rijKqsPfdaC6BokidjyvNVtEJZ6baMtHk657hfJUuDNK5NHcV
vx+77BElA3bbWS99iqxRxi3dA3sAHFAyvRljB3lJRbndzFd57e758XZQvN/Jn432A7eX
Rt6cnMuWUOxOR7p2Q7ROUYSp6MTEo8VokGwNK+s1OvoGTM/2W2c27uNPZ7SBF+lbgwZH
gWPhUQsRAN/GItXqEP+rytt7G5KDNW/i1j7T+HiDUPYEyHdPVjkF+4k5LSlwmY8vBRhF
8gYlXwSHoyOSI86UgQkKKPqJYRdpDJd1GB+hc+a/bxerCKOAD6OkIg2qZsiTTwvnOkCS
cGkA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
s=arc-20160816;
h=list-id:precedence:content-transfer-encoding:mime-version
:references:in-reply-to:message-id:date:subject:cc:to:from
:dkim-signature;
bh=AxqPCsVu93zMNlESL0N42GEheOSU7BHbH8/1jpPYl4o=;
fh=Fmfa0t6QgnUIyzgsSgnN1cYWfnFwLN+1Ba+VDm5h09M=;
b=XOYhuI2AmM34niy31fKhBYoxFkt3j5DqijYTMjnSUDS+FUsdM+KQiz0DCtqQLyLW6K
07jeT8HIyU//kFGxLVKwVqRjZzqPjxBk1oZiRSVwdTByf9XFyZ8lTfh5pD4vmi3p+dvM
S5nIsW5Y5s0ISzKPecCwCbjlVxWlHyDJB2uULUtAZJsV+QNiF9nknaW7+i5YOpEn9Rnq
hT1u91w3b7RT0KUCVDZxu40MyMpCjOaq4Gsrc7iflaT/0tY/lpj0uqUaYtzlYkijGTra
tt+QLczQxLYj6UqMjeJ95ND5esltIBHTBqpsNCasOtJXG9kob63W6gZ0dJ+GFUmPmtES
7ewA==
ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass header.i=@suse.com header.s=susede1 header.b=HDYzBKju;
spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 23.128.96.31 as permitted sender)
smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com
Received: from morse.vger.email (morse.vger.email. [23.128.96.31])
by mx.google.com with ESMTPS id
bw18-20020a056a02049200b005a019d60ffbsi2141115pgb.78.2023.10.18.04.14.08
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 18 Oct 2023 04:14:08 -0700 (PDT)
Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31;
Authentication-Results: mx.google.com;
dkim=pass header.i=@suse.com header.s=susede1 header.b=HDYzBKju;
spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 23.128.96.31 as permitted sender)
smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com
Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0])
by morse.vger.email (Postfix) with ESMTP id DA43980C6517;
Wed, 18 Oct 2023 04:14:06 -0700 (PDT)
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.103.10 at morse.vger.email
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S230246AbjJRLNh (ORCPT <rfc822;lkml4gm@gmail.com> + 24 others);
Wed, 18 Oct 2023 07:13:37 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57070 "EHLO
lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S229993AbjJRLNb (ORCPT
<rfc822;linux-kernel@vger.kernel.org>);
Wed, 18 Oct 2023 07:13:31 -0400
Received: from smtp-out2.suse.de (smtp-out2.suse.de
[IPv6:2001:67c:2178:6::1d])
by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 76A89114
for <linux-kernel@vger.kernel.org>;
Wed, 18 Oct 2023 04:13:29 -0700 (PDT)
Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de
[192.168.254.74])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature ECDSA (P-521) server-digest
SHA512)
(No client certificate requested)
by smtp-out2.suse.de (Postfix) with ESMTPS id 047A81FD71;
Wed, 18 Oct 2023 11:13:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
t=1697627608;
h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
mime-version:mime-version:
content-transfer-encoding:content-transfer-encoding:
in-reply-to:in-reply-to:references:references;
bh=AxqPCsVu93zMNlESL0N42GEheOSU7BHbH8/1jpPYl4o=;
b=HDYzBKjuHW1BbT8KulHbZ4NzqLYCB12U4vKthmGMAi/oYagpeOPykJjM21yUVbm8QFrv4R
QTlsQmwbDDHJ4lXe7v3VUW0Xgoxb4CBrOa2Z8oMVldrMMvot59pJmdk4+UK/zV8gNPL+Z+
h8E+CO8OZg9hG9Fr0ZwZ2ORJ8yxcO1E=
Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de
[192.168.254.74])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature ECDSA (P-521) server-digest
SHA512)
(No client certificate requested)
by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id DD3BD13915;
Wed, 18 Oct 2023 11:13:27 +0000 (UTC)
Received: from dovecot-director2.suse.de ([192.168.254.65])
by imap2.suse-dmz.suse.de with ESMTPSA
id HnMLNNe9L2VLZwAAMHmgww
(envelope-from <aporta@suse.de>); Wed, 18 Oct 2023 11:13:27 +0000
From: Andrea della Porta <andrea.porta@suse.com>
To: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Cc: nik.borisov@suse.com, Andrea della Porta <andrea.porta@suse.com>
Subject: [PATCH 2/4] arm64/process: Make loading of 32bit processes depend on
aarch32_enabled()
Date: Wed, 18 Oct 2023 13:13:20 +0200
Message-ID:
<a40565807874c9ca82d60c118225ee65fe668fcd.1697614386.git.andrea.porta@suse.com>
X-Mailer: git-send-email 2.41.0
In-Reply-To: <cover.1697614386.git.andrea.porta@suse.com>
References: <cover.1697614386.git.andrea.porta@suse.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Authentication-Results: smtp-out2.suse.de;
none
X-Spam-Level:
X-Spam-Score: -4.17
X-Spamd-Result: default: False [-4.17 / 50.00];
ARC_NA(0.00)[];
RCVD_VIA_SMTP_AUTH(0.00)[];
BAYES_HAM(-1.47)[91.46%];
FROM_HAS_DN(0.00)[];
TO_DN_SOME(0.00)[];
TO_MATCH_ENVRCPT_ALL(0.00)[];
R_MISSING_CHARSET(2.50)[];
MIME_GOOD(-0.10)[text/plain];
REPLY(-4.00)[];
BROKEN_CONTENT_TYPE(1.50)[];
RCPT_COUNT_FIVE(0.00)[6];
NEURAL_HAM_LONG(-3.00)[-1.000];
DKIM_SIGNED(0.00)[suse.com:s=susede1];
NEURAL_HAM_SHORT(-1.00)[-1.000];
MID_CONTAINS_FROM(1.00)[];
FORGED_SENDER(0.30)[andrea.porta@suse.com,aporta@suse.de];
MIME_TRACE(0.00)[0:+];
RCVD_COUNT_TWO(0.00)[2];
FROM_NEQ_ENVFROM(0.10)[andrea.porta@suse.com,aporta@suse.de];
RCVD_TLS_ALL(0.00)[]
X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no
version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test,
not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]);
Wed, 18 Oct 2023 04:14:06 -0700 (PDT)
X-getmail-retrieved-from-mailbox: INBOX
X-GMAIL-THRID: 1780091609426062570
X-GMAIL-MSGID: 1780091609426062570
|
| Series |
arm64: Make Aarch32 compatibility enablement optional at boot
|
|
Commit Message
Andrea della Porta
Oct. 18, 2023, 11:13 a.m. UTC
Major aspect of Aarch32 emulation is the ability to load 32bit
processes.
That's currently decided (among others) by compat_elf_check_arch().
Make the macro use aarch32_enabled() to decide if Aarch32 compat is
enabled before loading a 32bit process.
Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
---
arch/arm64/kernel/process.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Wed, Oct 18, 2023 at 01:13:20PM +0200, Andrea della Porta wrote: > Major aspect of Aarch32 emulation is the ability to load 32bit > processes. > That's currently decided (among others) by compat_elf_check_arch(). > > Make the macro use aarch32_enabled() to decide if Aarch32 compat is > enabled before loading a 32bit process. > > Signed-off-by: Andrea della Porta <andrea.porta@suse.com> Why can't you make system_supports_32bit_el0() take the option into account instead? Mark. > --- > arch/arm64/kernel/process.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c > index 657ea273c0f9..96832f1ec3ee 100644 > --- a/arch/arm64/kernel/process.c > +++ b/arch/arm64/kernel/process.c > @@ -601,7 +601,7 @@ unsigned long arch_align_stack(unsigned long sp) > #ifdef CONFIG_COMPAT > int compat_elf_check_arch(const struct elf32_hdr *hdr) > { > - if (!system_supports_32bit_el0()) > + if (!system_supports_32bit_el0() || !aarch32_enabled()) > return false; > > if ((hdr)->e_machine != EM_ARM) > -- > 2.35.3 >
On 13:52 Wed 18 Oct , Mark Rutland wrote: > On Wed, Oct 18, 2023 at 01:13:20PM +0200, Andrea della Porta wrote: > > Major aspect of Aarch32 emulation is the ability to load 32bit > > processes. > > That's currently decided (among others) by compat_elf_check_arch(). > > > > Make the macro use aarch32_enabled() to decide if Aarch32 compat is > > enabled before loading a 32bit process. > > > > Signed-off-by: Andrea della Porta <andrea.porta@suse.com> > > Why can't you make system_supports_32bit_el0() take the option into account > instead? > I may be wrong here, but it seems to me that system_supports_32bit_el0() answers teh question "can this system supports compat execution?" rather than "do I want this system to run any compat execution?". That's the point of aarch32_enabled(), to state whether we want teh system to run A32 code or not, regardless of the system supporting it (of course, if the system does not support A32 in EL0, this is a no-no, but that's another story). Andrea
On Thu, Oct 19, 2023 at 02:38:32PM +0200, Andrea della Porta wrote: > On 13:52 Wed 18 Oct , Mark Rutland wrote: > > On Wed, Oct 18, 2023 at 01:13:20PM +0200, Andrea della Porta wrote: > > > Major aspect of Aarch32 emulation is the ability to load 32bit > > > processes. > > > That's currently decided (among others) by compat_elf_check_arch(). > > > > > > Make the macro use aarch32_enabled() to decide if Aarch32 compat is > > > enabled before loading a 32bit process. > > > > > > Signed-off-by: Andrea della Porta <andrea.porta@suse.com> > > > > Why can't you make system_supports_32bit_el0() take the option into account > > instead? > > > > I may be wrong here, but it seems to me that system_supports_32bit_el0() > answers teh question "can this system supports compat execution?" rather than > "do I want this system to run any compat execution?". That's the point of > aarch32_enabled(), to state whether we want teh system to run A32 code or not, > regardless of the system supporting it (of course, if the system does not > support A32 in EL0, this is a no-no, but that's another story). That's what the implementation does today, but we're really using it as a "do we intend for 32-bit EL0 to work?" predicate, and generally the system_supports_${FEATURE}() helpers are affected by the combination of actual HW support, kernel config options, *and* kernel command line options. For example, system_supports_sve() is affected by both CONFIG_ARM64_SVE and the "arm64.nosve" command line option. Thanks, Mark.
On 15:27 Thu 19 Oct , Mark Rutland wrote: > On Thu, Oct 19, 2023 at 02:38:32PM +0200, Andrea della Porta wrote: > > On 13:52 Wed 18 Oct , Mark Rutland wrote: > > > On Wed, Oct 18, 2023 at 01:13:20PM +0200, Andrea della Porta wrote: > > > > Major aspect of Aarch32 emulation is the ability to load 32bit > > > > processes. > > > > That's currently decided (among others) by compat_elf_check_arch(). > > > > > > > > Make the macro use aarch32_enabled() to decide if Aarch32 compat is > > > > enabled before loading a 32bit process. > > > > > > > > Signed-off-by: Andrea della Porta <andrea.porta@suse.com> > > > > > > Why can't you make system_supports_32bit_el0() take the option into account > > > instead? > > > > > > > I may be wrong here, but it seems to me that system_supports_32bit_el0() > > answers teh question "can this system supports compat execution?" rather than > > "do I want this system to run any compat execution?". That's the point of > > aarch32_enabled(), to state whether we want teh system to run A32 code or not, > > regardless of the system supporting it (of course, if the system does not > > support A32 in EL0, this is a no-no, but that's another story). > > That's what the implementation does today, but we're really using it as a "do > we intend for 32-bit EL0 to work?" predicate, and generally the > system_supports_${FEATURE}() helpers are affected by the combination of actual > HW support, kernel config options, *and* kernel command line options. For > example, system_supports_sve() is affected by both CONFIG_ARM64_SVE and the > "arm64.nosve" command line option. > > Thanks, > Mark. Many thanks for the explanation, then inserting aach32_enabled() in system_supports_32bit_el0() is the way to go. Andrea
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c index 657ea273c0f9..96832f1ec3ee 100644 --- a/arch/arm64/kernel/process.c +++ b/arch/arm64/kernel/process.c @@ -601,7 +601,7 @@ unsigned long arch_align_stack(unsigned long sp) #ifdef CONFIG_COMPAT int compat_elf_check_arch(const struct elf32_hdr *hdr) { - if (!system_supports_32bit_el0()) + if (!system_supports_32bit_el0() || !aarch32_enabled()) return false; if ((hdr)->e_machine != EM_ARM)