Alternative to arm64.nopauth cmdline for disabling Pointer Authentication

Alternative to arm64.nopauth cmdline for disabling Pointer Authentication

[Pavan Kondeti]

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/

Re: Alternative to arm64.nopauth cmdline for disabling Pointer Authentication

[Marc Zyngier]

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

Re: Alternative to arm64.nopauth cmdline for disabling Pointer Authentication

[Pavan Kondeti]

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 <pavan.kondeti@oss.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?

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.

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

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

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

As I have asked above, the firmware part is not clear. 

Thanks Marc for your time and guidance.

Thanks,
Pavan

Re: Alternative to arm64.nopauth cmdline for disabling Pointer Authentication

[Mark Rutland]

Hi Pavan, Marc,

On Thu, Dec 04, 2025 at 04:06:12PM +0530, Pavan Kondeti wrote:
> On Thu, Dec 04, 2025 at 09:15:29AM +0000, Marc Zyngier wrote:
> > On Thu, 04 Dec 2025 04:07:15 +0000,
> > Pavan Kondeti <pavan.kondeti@oss.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.

Marc, it seems like that's exactly that's happened 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.

Cortex-A78 doesn't have pointer authentication, but Cortex-A78C does, so
maybe you actually have Cortex-A78C?

What are the MIDRs on this SoC? e.g. the output of:

  cat /sys/devices/system/cpu/cpu*/regs/identification/midr_el1 | sort | uniq

If this SoC has both Cortex-A78C and Cortex-A55, that's a rather
unfortunate combination that should have been caught at the SoC design
phase, as Marc alluded to.

[...]

> > > This patch [2] from Catalin adds a devicetree property under memory {}
> > > to disable MTE.

Catalin's patch was a bit different. It described whether the memory
range supported tags (and was actually a property of the memory). That
patch didn't make it into mainline AFAICT.

[...]

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

I strongly suspect we cannot use the MIDR for this. Per:

  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=53a52a0ec7680287b170b36488203b5822e6da2d

... Qualcomm's Kryo {Prime,Gold,Silver} parts seem to identify
themselves as Arm ltd implementations, and those will appear in other
non-Qualcomm SoCs.

Without know *exactly* which MIDRs you have on this part, we cannot say.

Regardless, I strongly suspect that we have to live with the command
line option for these parts.

Mark.

Re: Alternative to arm64.nopauth cmdline for disabling Pointer Authentication

[Pavan Kondeti]

On Thu, Dec 04, 2025 at 12:04:42PM +0000, Mark Rutland wrote:
> Hi Pavan, Marc,
> 
> On Thu, Dec 04, 2025 at 04:06:12PM +0530, Pavan Kondeti wrote:
> > On Thu, Dec 04, 2025 at 09:15:29AM +0000, Marc Zyngier wrote:
> > > On Thu, 04 Dec 2025 04:07:15 +0000,
> > > Pavan Kondeti <pavan.kondeti@oss.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.
> 
> Marc, it seems like that's exactly that's happened 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.
> 
> Cortex-A78 doesn't have pointer authentication, but Cortex-A78C does, so
> maybe you actually have Cortex-A78C?
> 
> What are the MIDRs on this SoC? e.g. the output of:
> 
>   cat /sys/devices/system/cpu/cpu*/regs/identification/midr_el1 | sort | uniq
> 
> If this SoC has both Cortex-A78C and Cortex-A55, that's a rather
> unfortunate combination that should have been caught at the SoC design
> phase, as Marc alluded to.

Yes. The MIDR register indicate the same. A78C + A55

root@v8a-arm64:~# cat /sys/devices/system/cpu/cpu*/regs/identification/midr_el1
0x00000000410fd4b2
0x00000000410fd4b2
0x00000000410fd4b2
0x00000000410fd4b2
0x00000000412fd050
0x00000000412fd050
0x00000000412fd050
0x00000000412fd050

> 
> [...]
> 
> > > > This patch [2] from Catalin adds a devicetree property under memory {}
> > > > to disable MTE.
> 
> Catalin's patch was a bit different. It described whether the memory
> range supported tags (and was actually a property of the memory). That
> patch didn't make it into mainline AFAICT.
> 
> [...]
> 
> > 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.
> 
> I strongly suspect we cannot use the MIDR for this. Per:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=53a52a0ec7680287b170b36488203b5822e6da2d
> 
> ... Qualcomm's Kryo {Prime,Gold,Silver} parts seem to identify
> themselves as Arm ltd implementations, and those will appear in other
> non-Qualcomm SoCs.

Thank you for explaining this. Agree that we can't use MIDR based
workaround here. 
> 
> Without know *exactly* which MIDRs you have on this part, we cannot say.
> 
> Regardless, I strongly suspect that we have to live with the command
> line option for these parts.
> 

Got it. 

Thanks,
Pavan

Re: Alternative to arm64.nopauth cmdline for disabling Pointer Authentication

[Marc Zyngier]

[dropping Ricardo, as his address bounces]

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

Re: Alternative to arm64.nopauth cmdline for disabling Pointer Authentication

[Pavan Kondeti]

On Thu, Dec 04, 2025 at 01:01:40PM +0000, Marc Zyngier wrote:
> [dropping Ricardo, as his address bounces]
> 
> On Thu, 04 Dec 2025 10:36:12 +0000,
> Pavan Kondeti <pavan.kondeti@oss.qualcomm.com> 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 <pavan.kondeti@oss.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?
> > 
> > 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?
> 

As Mark pointed out and MIDR indicates, it is A78C. sorry for the
confusion.

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

Got it. 

Thanks,
Pavan