[PATCH 0/3] arm64: cpufeature: Add filter function to control

[Marc Zyngier]

On 2021-01-14 07:15, Srinivas Ramana wrote:
> Hi Marc,
> 
> On 1/11/2021 5:40 AM, Marc Zyngier wrote:
>> Hi Srinivas,
>> 
>> On 2021-01-09 00:29, Srinivas Ramana wrote:
>>> This patchset adds a control function for cpufeature framework
>>> so that the feature can be controlled at runtime.
>>> 
>>> Defer PAC on boot core and use the filter function added to disable
>>> PAC from command line. This will help toggling the feature on systems
>>> that do not support PAC or where PAC needs to be disabled at runtime,
>>> without modifying the core kernel.
>>> 
>>> The idea of adding the filter function for cpufeature is taken from
>>> https://lore.kernel.org/linux-arm-kernel/20200515171612.1020-25-catalin.marinas@arm.com/ 
>>> https://lore.kernel.org/linux-arm-kernel/20200515171612.1020-24-catalin.marinas@arm.com/ 
>>> Srinivas Ramana (3):
>>>   arm64: Defer enabling pointer authentication on boot core
>>>   arm64: cpufeature: Add a filter function to cpufeature
>>>   arm64: Enable control of pointer authentication using early param
>>> 
>>>  Documentation/admin-guide/kernel-parameters.txt |  6 +++
>>>  arch/arm64/include/asm/cpufeature.h             |  8 +++-
>>>  arch/arm64/include/asm/pointer_auth.h           | 10 +++++
>>>  arch/arm64/include/asm/stackprotector.h         |  1 +
>>>  arch/arm64/kernel/cpufeature.c                  | 53 
>>> +++++++++++++++++++------
>>>  arch/arm64/kernel/head.S                        |  4 --
>>>  6 files changed, 64 insertions(+), 18 deletions(-)
>> 
>> I've been working for some time on a similar series to allow a feature
>> set to be disabled during the early boot phase, initially to prevent
>> booting a kernel with VHE, but the mechanism is generic enough to
>> deal with most architectural features.
>> 
>> I took the liberty to lift your first patch and to add it to my 
>> series[1],
>> further allowing PAuth to be disabled at boot time on top of BTI and 
>> VHE.
>> 
>> I'd appreciate your comments on this.
> Thanks for sending this series. It seems to be more flexible compared
> you what we did.
> Following your discussion on allowing EXACT ftr_reg values.
> 
> 
> Btw, do you have plan to add MTE in similar lines to control the 
> feature?
> We may be needing this on some systems.

I don't have any need for this at the moment, as my initial goal was
to enable a different boot flow for VHE. The BTI "support" was added
as a way to demonstrate the use of __read_sysreg_by_encoding(), and
your patches were a good opportunity to converge on a single solution.

But if you write the patches that do that, I can add them to the series,
and Catalin/Will can decide whether they want to take them.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...