From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DB22CCDB465 for ; Thu, 19 Oct 2023 11:42:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Subject:Cc:To:From:Date:References: In-Reply-To:Message-Id:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=/cx8waYSp05f9YVKglbquMummlLJaT5f/rJ0lRNqhlw=; b=FOhHxefD/WxHnG WLbA1qM4jfl8sUvuSpQxpBkBoqG0eu+61pPs8dmf8iydrhAwJaDCLeR+BeHqk+xryPWOHoHE4q0lK VJ7CTUwNV72dyD6SNNQr456KNTA0A6jODEj6MADod2zA51S8yCJV23dufRpFOjA/P91D2a+rpsYb3 hTm9PEN3eI+qHWtV6Vdi3l9Bxzb7pcyuKN86cKFNW3OYA7wq3KoXE23w48RJcYOBnsJyQAr0SHD54 ubEpOA2s4f/zTKPX1w9MDCDw9GXld+nvJw2QUkQoUYjPbG2sIF5001DZjMNd2cT1UUuL0hhiOQn9y ArkfKLtnoKh9MUllh1FQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qtRQ4-00HCdr-0v; Thu, 19 Oct 2023 11:42:28 +0000 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qtRQ0-00HCcQ-12 for linux-arm-kernel@lists.infradead.org; Thu, 19 Oct 2023 11:42:26 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 9FFE53200976; Thu, 19 Oct 2023 07:42:20 -0400 (EDT) Received: from imap51 ([10.202.2.101]) by compute5.internal (MEProxy); Thu, 19 Oct 2023 07:42:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm2; t=1697715740; x=1697802140; bh=U2 gqYc9zqSX1Su7Bd7S3GZCjJ4GSS8Kq+u+LYXmTYRQ=; b=S9G5LX4fYsVuWGKoii mBG0HcarkUtMhdoal9QD1/AfKxCwoltpxDFNrn7mrHuEmd0E0SWDeXFoVfdsogVP p3MI1gej+pJ5un05zPJ3dXlBlpoVJrwjtJN37qpV3y/tnPmJeqlRjQueasGchLr1 1bTWz5ZWmHB8zPZA9YjvoSfS48PV8ypwbBonhHL/7Herfy/aocZSsJc3GatUrnNl Qe2zP8m7t0eXIi4GLWrIP8NXsYV6ZuZedz0nPULxBt/37dgyYc7SP83B03p2wdU5 ifruX6vfR8V9iT5NRI3wrhWD8Aif5s0LZOD/mCqZnFKxlXem15RGA8MQPOJlp4V6 jUJQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1697715740; x=1697802140; bh=U2gqYc9zqSX1S u7Bd7S3GZCjJ4GSS8Kq+u+LYXmTYRQ=; b=CDBLOJycnB+uz4LLx5DvS/P01SjEA FAiRALNSsNQDpnRt39pgvZ/KlDtAo+caE+fOfTWTf2jSqU6tamHAK7VnWW0AUEMk t+I730RNrpZSgf0jF938D09y8N1+Jzu9svYkIy56++pQBOOuRcuX87Ux0RJ0XgfJ VURj3FjgIvhjTlZGaEgVVHslgkuz5auIgyIX50ABOi/j27abzxNp4ZmsYCVzW9KH EazCH8TnDTWpOJGqe7ltZEZKGRUfGNvouguWCPzggbmPVAuiPUTkupGF3uAx0Ak9 Qb82rt0dSNlIuO99wX5X0vpVCoIKKaY3puq2XMGXslNrANLY/nZPaB+4g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrjeeigdegfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdetrhhn ugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusgdruggvqeenucggtffrrghtth gvrhhnpeevhfffledtgeehfeffhfdtgedvheejtdfgkeeuvefgudffteettdekkeeufeeh udenucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomheprghrnhgusegrrhhnuggsrdguvg X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id A6D0BB60089; Thu, 19 Oct 2023 07:42:19 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-1019-ged83ad8595-fm-20231002.001-ged83ad85 MIME-Version: 1.0 Message-Id: <6d3d4e4d-a2f6-493e-972c-a695efa37947@app.fastmail.com> In-Reply-To: References: <20231018122729.GA18556@willie-the-truck> Date: Thu, 19 Oct 2023 13:41:59 +0200 From: "Arnd Bergmann" To: "Andrea della Porta" Cc: "Will Deacon" , "Andrea della Porta" , "Catalin Marinas" , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, nik.borisov@suse.com, "Kees Cook" Subject: Re: [PATCH 0/4] arm64: Make Aarch32 compatibility enablement optional at boot X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231019_044224_796673_1FE786CF X-CRM114-Status: GOOD ( 27.54 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Oct 19, 2023, at 12:52, Andrea della Porta wrote: > On 14:44 Wed 18 Oct , Arnd Bergmann wrote: >> On Wed, Oct 18, 2023, at 14:27, Will Deacon wrote: >> >> Right, I was going to reply along the same lines here: x86 is >> a bit of a special case that needs this, but I believe all the >> other architectures already guard the compat syscall execution >> on test_thread_flag(TIF_32BIT) that is only set by the compat >> binfmt loader. > > Are you referring to the fact that x86 can switch at will between 32- and 64- > bit code? No. > Regarding the TIF_32BIT flag, thanks for the head-up. I still believe though > that this mechanism can somehow break down in the future, since prohibiting > 32 bit executable loading *and* blocking 32 bit compat syscall are two > separate path of execution, held together by the architecture prohibiting > to switch to A32 instructions by design. Breaking the first rule and embedding > wisely crafted A32 instruction in an executable is easy, while the difficult > part is finding some 'reentrancy' to be able to do the execution state switch, > as pinted out in https://lore.kernel.org/lkml/ZTD0DAes-J-YQ2eu@apocalypse/. > I agree it's highly speculative and not something to be concerned right > now, it's just a head up, should the need arise in the future. There are (at least) five separate aspects to compat mode that are easy to mix up: 1. Instruction decoding -- switching between the modes supported by the CPU (A64/A32/T32) 2. Word size -- what happens to the upper 32 bits of a register in an arithmetic operation 3. Personality -- Which architecture string gets returned by the uname syscall (aarch64 vs armv8) as well as the format of /proc/cpuinfo 4. system call entry points -- how a process calls into native or compat syscalls, or possibly foreign OS emulation 5. Binary format -- elf32 vs elf64 executables On most architectures with compat mode, 4. and 5. are fundamentally tied together today: a compat task can only call compat syscalls and a native task can only call native syscalls. x86 is the exception here, as it uses different instructions (int80, syscall, sysenter) and picks the syscall table based on that instruction. I think 1. and 2. are also always tied to 5 on arm, but this is not necessarily true for other architectures. 3. used to be tied to 5 on some architectures in the past, but should be independent now. >> Doing the reverse is something that has however come up in the >> past several times and that could be interesting: In order to >> run userspace emulation (qemu-user, fex, ...) we may want to >> allow calling syscalls and ioctls for foreign ABIs in a native >> task, and at that point having a mechanism to control this >> capability globally or per task would be useful as well. >> >> The compat mode (arm32 on arm64) is the easiest case here, but the >> same thing could be done for emulating the very subtle architecture >> differences (x86-64 on arm64, arm64 on x86_64, arm32 on x86-compat, >> or any of the above on riscv or loongarch). > > Really interesting, Since it's more related to emulation needs (my patch > has another focus due to the fact that A64 can execute A32 natively), > I'll take a look at this separately. A64 mode (unlike some other architectures, notably mips64) cannot execute A32 or T32 instructions without a mode switch, the three are entirely incompatible on the binary level. Many ARMv8-CPUs support both Aarch64 mode and Aarch32 (A32/T32), but a lot of the newer ones (e.g. Apple M1/M2, Cortex-R82 or Cortex-A715) only do Aarch64 and need user-space emulation to run 32-bit binaries. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel