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 B3951CCD1A5 for ; Fri, 24 Oct 2025 09:28:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=QQFQRJvEiH06gWesK5n+Kt8/iZJeKmlgrzvqirZz5Dc=; b=SQkLVYLx9obEeQd0Lm4OYOJuCj O0Rfg/JPWjwwlZRfuJSv44i/Pi8iIkcVRvLbNQofcwo0ZKL0tyKWJnG+TSpgtcoAtW255hoqdGUUo 0gu6jPeeoyJlLdQPA5hMx/gIhXtGNK/wY3PI78GFKGD3mGsOvocDsZ7E0nPhnb5IVNIyDAkBIqzP8 WCfW5eQhKJEk3KVvvC/LDG88qKzs+HAruylyyC3wUAcbV6NKYf2GTn9OsJokphyzMzqAF0i6+8OqU xwQMKpGIMioHBwt+MC1OwV2OLSP9j2mmkec7pPoPKgUoHBhtCakP9bm1WFnfPoqX9Qrq4EAEsKbnM S3GwNW1g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vCE5U-00000008sT0-2dGb; Fri, 24 Oct 2025 09:27:56 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vCE5S-00000008sSC-2Xes for linux-arm-kernel@lists.infradead.org; Fri, 24 Oct 2025 09:27:54 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id A81466031A; Fri, 24 Oct 2025 09:27:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4F7B8C4CEF1; Fri, 24 Oct 2025 09:27:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1761298073; bh=JtAgQYabJoYpbAKikJiDKcmhcEvLDKqLOeVG9wlYeU8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=lEV6Vnqlk63vvYBY5YiNwCxLV2t046WuVTH0bJu7v0NPJTvyR5bdMD+46tN94eZs7 E9i6wVfS/wnke+C7L5ar3jT+19O+7l60IXYUQLIi+AAMHINtBAatKW1sXvCCeiVJjq JcJ8uu+/YM9j8WmVMNTGQGl1Pk9sR8bLRHY1XoQEvedObLFXLnWTVkFv6aH7nKuwJ5 TqS4v10GhIDA5tJoQ3vA1s2WyW+mENZwQw0Yqvfv3wjVXSblIPlZI3ddacF/OqYoLa GAVYXGOUtOnadjlx9UKQvvNNfvHkP+jBJ26GBkUxZM53y53ddjS2wJ63VMQvr9TV3p fXEr7mt+9mLQg== Received: from 91-165-189-16.subs.proxad.net ([91.165.189.16] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vCE5O-0000000GnSj-3WVw; Fri, 24 Oct 2025 09:27:51 +0000 Date: Fri, 24 Oct 2025 10:27:50 +0100 Message-ID: <87sef83azt.wl-maz@kernel.org> From: Marc Zyngier To: Marek Vasut Cc: linux-arm-kernel@lists.infradead.org, Anshuman Khandual , Catalin Marinas , Geert Uytterhoeven , Ryan Roberts , Will Deacon , Yicong Yang , linux-renesas-soc@vger.kernel.org Subject: Re: [PATCH] arm64: guard AMU register access with ARM64_HAS_AMU_EXTN In-Reply-To: References: <20251022133621.178546-1-marek.vasut+renesas@mailbox.org> <86347bvx0f.wl-maz@kernel.org> <07391913-aab6-4d92-b75f-278506f51397@mailbox.org> <861pmvvv2g.wl-maz@kernel.org> <24c8da41-37db-4e69-b9aa-e33b2154acb0@mailbox.org> <87y0p13dlh.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 91.165.189.16 X-SA-Exim-Rcpt-To: marek.vasut@mailbox.org, linux-arm-kernel@lists.infradead.org, anshuman.khandual@arm.com, catalin.marinas@arm.com, geert+renesas@glider.be, ryan.roberts@arm.com, will@kernel.org, yangyicong@hisilicon.com, linux-renesas-soc@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 23 Oct 2025 16:58:49 +0100, Marek Vasut wrote: > > On 10/23/25 4:19 PM, Marc Zyngier wrote: > > Hello Marc, > > >> Except right now, I still trigger the AMU faults even with > >> ARM64_HAS_AMU_EXTN=n , which I think should not happen ? > > > > ARM64_HAS_AMU_EXTN is a *capability*, not a configuration. > > CONFIG_ARM64_AMU_EXTN is the configuration. I have the feeling you're > > mixing the two. > > > > Irrespective of the configuration, we access the AMU registers > > depending on the what is advertised, because we *must* make these > > registers inaccessible from EL0, no matter what. > > Ahhh, I was missing this part, thank you for clarifying. > > >> I would much rather be able to disable ARM64_HAS_AMU_EXTN in kernel > >> config for the old devices with old firmware, without triggering the > >> faults ... and say that everything which is going to be upstream will > >> always use new firmware that has proper working AMU support. > > > > No, that's the wrong approach. If you leave the AMU accessible to EL0, > > you're leaking data to userspace, and that's pretty wrong, no matter > > how you look at it. > > > > I also think your hack works by pure luck, because at the point where > > your CPUs are booting, the alternatives are yet not in place (the > > kernel patching happens much later). In short, this breaks > > *everything*. > > > > As I indicated before, you have two options: > > > > - either you update your firmware and leave the kernel alone > > > > - or you implement the workaround as ID register override so that you > > *must* pass something on the kernel command line to boot, and by > > then accept that you will leak critical timing information to > > userspace. > > > > Any other option, including guarding the macro with a config option is > > *not* acceptable. > > Since I am getting an exception when I access the AMU register, would > it be possible to trap that exception, and report something to the > user instead of outright crashing with no output ? The trap exists, and the exception is being routed to EL3. There is nothing you can do about that if running at EL2, and if at EL1, you'd need to take the trap to EL2 to handle it. And if you can do that, what do you do? Not doing anything is wrong, and doing something will nuke your machine. > Similar to what Linux already does on the various speculative > execution bugs on x86, something like this? > > " > MDS CPU bug present and SMT on, data leak possible. See > https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html > for more details. > " You're completely off base. The problem at hand has nothing to do with speculation, and everything to do with access permission to counter registers. I also wouldn't be surprised if you could take your whole machine down from userspace just by ticking some of the AM*_EL0 registers (the pseudocode clearly shows that there is a route to EL3 in this case). Honestly, I think you should stop trying to papering over this issue behind the user's back. If you want this addressed, do it so that the user knows their machine is fsck'd, and that they are OK with that. Do it by implementing an ID register override that requires a kernel command-line argument. Do I sound like a stuck record? Probably. But that's IMO the only acceptable solution for what you have. I'm looking forward to reviewing a patch implementing that suggestion, but I'll stop even thinking of how to paper over this in the way you suggest. Thanks, M. -- Jazz isn't dead. It just smells funny.