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 1FFF2D20682 for ; Thu, 4 Dec 2025 13:01:52 +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=LS+EuiHslT/L78YAItlfxu1O4qSNFKEHjW0KbNj81tk=; b=kTZ6cEtEjPX9Kdkksfh+DHr+g6 jkrMGP7kgK3LkDhnI+bV0Zcuz+cR9mBlpT+iolgaax3VdAz1Suq+pwPf6VFWDPv7HgaEEDo2HBkF2 Oxc/7jIMxOIv+jY4P8ta8XJdWXs7LARH2PpKlVv4MPTuiCW6+2cFKpCkWn767gRrSFavpPVCc7a+j JE71UUTNYSXjHscynac0Wko8/FVK9NPwatYcpmcVTVjHa/5W6gIH+kjy234ipo7bebOhx0mENlTPY TUDRp3D+cagGCuwFgk1gPGglxlfuuvJJOJkoE047Y3hDt4qqMqxrcedeI4IOppuAp/TlXdao/W6M4 3IVgHLpA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vR8xt-0000000815u-34mo; Thu, 04 Dec 2025 13:01:45 +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 1vR8xt-0000000815m-0GzW for linux-arm-kernel@lists.infradead.org; Thu, 04 Dec 2025 13:01:45 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 0C0F5601E7; Thu, 4 Dec 2025 13:01:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ADD33C4CEFB; Thu, 4 Dec 2025 13:01:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764853303; bh=y8Dpxq/qac2yfhGme+RbqjKcFBbu3jxAWjEWDiTog8I=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Q5FfdSKvDj+KHCLkDd+HBIGhhv+z8ttkvqzxPm5TJQMqguHwvlGI3lndWXSFKnc9X Zhx4BTsYRKWgI+lW3LdgWUmIIn1ZMLj/FO9l/icI2DKYTO92LkmDXYU3GerC7cQQMF /i6RA+QlFVyn8Z/lBEzuBFkbTOlDutRvw4jIT15kdeL7iHqdiiKAfqI7dJMWpdJwN6 mND5pWkZfIAlN5/Vpan/QiAePMeCiO4NtDqL+UlebuxWKX/rk1mmUl32PSIn8HYBJF 4aqp2TrCOINjVFL+6nq9mEiQsBh+uod8LI3qTG7F5+jJOO2rJ3/R5FP8nMpMfQMmxK PlVQSrG8F+pqA== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-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 1vR8xp-0000000AS1y-1ZLD; Thu, 04 Dec 2025 13:01:41 +0000 Date: Thu, 04 Dec 2025 13:01:40 +0000 Message-ID: <868qfipfij.wl-maz@kernel.org> From: Marc Zyngier To: Pavan Kondeti Cc: Catalin Marinas , Will Deacon , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org Subject: Re: Alternative to arm64.nopauth cmdline for disabling Pointer Authentication In-Reply-To: References: <3fcf6614-ee83-4a06-9024-83573b2e642e@quicinc.com> <86ecpappzi.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: 185.219.108.64 X-SA-Exim-Rcpt-To: pavan.kondeti@oss.qualcomm.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-msm@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 [dropping Ricardo, as his address bounces] On Thu, 04 Dec 2025 10:36:12 +0000, Pavan Kondeti wrote: > > Hi Marc, > > On Thu, Dec 04, 2025 at 09:15:29AM +0000, Marc Zyngier wrote: > > On Thu, 04 Dec 2025 04:07:15 +0000, > > Pavan Kondeti wrote: > > > > > > Hi > > > > > > The pointer authentication feature (PAuth) is only supported on > > > 0-3 CPUs but it is not supported on 4-7 CPUS on QCS8300. > > > > On what grounds? Hardware incompatibility? I seriously doubt it, since > > nobody glues pre-8.3 CPUs to anything more modern. Or, as I expect it, > > a firmware implemented with little understanding of what is required? > > I don't know the answer to this question. I will talk to folks who may > know answer to this question and get back. > > Can you please elaborate on the firmware part you are talking here? I > see that Linux runs at EL2 and AA64ISAR1 register values on CPU#0 (A78) > indicates that PAuth is supported but not for CPU#4 (A55). I am told, there > are no other controls outside EL2 (trap) to manipulate this feature. So, > I am assuming that this is indeed reflecting the HW. Neither A78 nor A55 have PAuth. They are both firmly ARMv8.2 CPUs, and predate this functionality. So I guess that there are only two possible outcomes: - either the FW is indeed not at fault, but that you have a *third* type of CPU that is at least 8.3 in the mix - or that you misidentified the CPUs that are on your system, they have PAuth, and the firmware is borked Which one is it? > > > > > > The ARM64 cpufeature discovery code expects late CPUs to have > > > this feature if boot CPU feature has it since PAuth is enabled > > > early. When a conflict like this is detected, the late CPUs are > > > not allowed to boot. It is expected that system will continue > > > to be functional with CPUs with Pauth feature supported and enabled. > > > This is not a desired behavior in production. > > > > What is even less desirable is to produce this sort of contraption. > > > > > We started seeing this problem when Linux is booted in EL2. When Linux > > > is running under Gunyah (Type-1 hypervisor), Pointer Authentication > > > feature is hidden from EL1 via HCR_EL2.TID3. > > > > > > arm64.nopauth can be passed on kernel cmdline to disable the feature > > > in kernel so that all all CPUs can boot on QCS8300. I am told > > > maintaining a custom kernel commandline per SoC in a Generic OS > > > distribution is not recommended and asked to discuss the problem with > > > the comunity [1] > > > > Well, you get to own the problem you have created for yourself. You > > build hardware/firmware that cannot run generic SW, and yet you want > > generic SW to run seamlessly on it. Spot the issue? > > > > > This patch [2] from Catalin adds a devicetree property under memory {} > > > to disable MTE. I believe this work predates the id-reg override > > > mechanism. However, this made me think if workarounds like this can be > > > detected via devicetree, for example a property under cpu { } node. > > > > Not only it predates it, but it also doesn't work in general. For a > > start, it is DT specific. How are you going to make that work for > > ACPI? I know you don't care, but I do. > > Point taken. I understand that this does not fall under errata but is > there a possiblity to introduce an Errata targeting CPU#0 MIDR and > disabling the Pointer authentication? I understand that if there is > another Qualcomm SoC that exists with all CPUs supporting pointer > authentication with same MIDR, we may be disabling the feature but this > is something I can check internally. > > > > > > Given that what we put in `chosen { bootargs="" }` kernel under > > > respective SoC devicetree can be overridden by bootloader, should we > > > have a **sticky** cmdline to specify critical workarounds like this? > > > This would be more generic than introducing any new parameters. > > > > You already have a way to have a sticky command-line, by building it > > into the kernel. Yes, I understand that this isn't what you want, but: > > > > (1) a user should be allowed to pass the kernel command-line *they* > > want, not what someone has decided for them > > Agreed. This is what made me to ask the question. Should kernel have a > sticky command line which may have critical workarounds like this? Absolutely *not*. You are not in charge of defining what is good for the user. If the user themselves want that, they have plenty of ways to achieve that particular goal already. Put it in the bootargs string, in the kernel build, in a grub config file, as a u-boot hack... There is an infinite number of choices already, and we don't need an extra one to hide how ugly their HW is. > > (2) the generic mechanism exists, doesn't rely on additional firmware > > specifications, and is used for a whole lot of other QC platforms > > suffering from the same issue of broken firmware. What are you > > going to do for these? > > The generic mechanism, you mean bootloader passing the kernel cmdline > with `arm64.nopauth`? or something else. Exactly that. This is the mechanism by which we instruct the kernel not to use a particular feature if it can avoid it. It is easy to add, doesn't depend on new esoteric firmware interfaces, and is a constant reminder that you are dealing with stuff that isn't fit for purpose. > > (3) what if you, by miracle, happened to *fix* the firmware? > > As I have asked above, the firmware part is not clear. Well, your description of the root cause of the problem isn't clear either, so we're even! ;-) M. -- Without deviation from the norm, progress is not possible.