linux-kernel - Alternative to arm64.nopauth cmdline for disabling Pointer Authentication

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <3fcf6614-ee83-4a06-9024-83573b2e642e@quicinc.com>
Date: Thu, 4 Dec 2025 09:37:15 +0530
From: Pavan Kondeti <pavan.kondeti@....qualcomm.com>
To: Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>,
        Marc Zyngier <maz@...nel.org>
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, rsalveti@....qualcomm.com
Subject: Alternative to arm64.nopauth cmdline for disabling Pointer
 Authentication

Hi

The pointer authentication feature (PAuth) is only supported on
0-3 CPUs but it is not supported on 4-7 CPUS on QCS8300.
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.

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]

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.

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.

Looking for your inputs on this.

Thanks,
Pavan

[1] https://github.com/qualcomm-linux/meta-qcom/issues/1277
[2] https://lore.kernel.org/linux-arm-kernel/20200515171612.1020-24-catalin.marinas@arm.com/