Message-ID: <86ecpappzi.wl-maz@kernel.org>
Date: Thu, 04 Dec 2025 09:15:29 +0000
From: Marc Zyngier <maz@...nel.org>
To: Pavan Kondeti <pavan.kondeti@....qualcomm.com>
Cc: Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>,
	linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	linux-arm-msm@...r.kernel.org,
	rsalveti@....qualcomm.com
Subject: Re: Alternative to arm64.nopauth cmdline for disabling Pointer Authentication

On Thu, 04 Dec 2025 04:07:15 +0000,
Pavan Kondeti <pavan.kondeti@....qualcomm.com> 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?

> 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.

> 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

(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?

(3) what if you, by miracle, happened to *fix* the firmware?

To sum it up, the kernel is not in the business of papering over these
issues. You have a tool to work around the problem you have created,
use it. Alternatively, you can always boot on a non-PAC CPU, and be
done with it.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

Powered by blists - more mailing lists