Messages in this thread | | | Date | Thu, 14 Jan 2021 08:20:52 +0000 | From | Marc Zyngier <> | Subject | Re: [PATCH 0/3] arm64: cpufeature: Add filter function to control |
| |
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...
| |