On Fri, Jun 09, 2023 at 05:21:46PM +0100, Marc Zyngier wrote:
> diff --git a/arch/arm64/kernel/idreg-override.c b/arch/arm64/kernel/idreg-override.c
> index 370ab84fd06e..8c93b6198bf5 100644
> --- a/arch/arm64/kernel/idreg-override.c
> +++ b/arch/arm64/kernel/idreg-override.c
> @@ -138,15 +138,11 @@ static const struct ftr_set_desc smfr0 __initconst = {
> },
> };
>
> -extern struct arm64_ftr_override kaslr_feature_override;
> -
> -static const struct ftr_set_desc kaslr __initconst = {
> - .name = "kaslr",
> -#ifdef CONFIG_RANDOMIZE_BASE
> - .override = &kaslr_feature_override,
> -#endif
> +static const struct ftr_set_desc sw_features __initconst = {
> + .name = "arm64_sw",
> + .override = &arm64_sw_feature_override,
> .fields = {
> - FIELD("disabled", 0, NULL),
> + FIELD("nokaslr", ARM64_SW_FEATURE_OVERRIDE_NOKASLR, NULL),
> {}
> },
> };
> @@ -158,7 +154,7 @@ static const struct ftr_set_desc * const regs[] __initconst = {
> &isar1,
> &isar2,
> &smfr0,
> - &kaslr,
> + &sw_features,
> };
>
> static const struct {
> @@ -175,7 +171,7 @@ static const struct {
> "id_aa64isar1.api=0 id_aa64isar1.apa=0 "
> "id_aa64isar2.gpa3=0 id_aa64isar2.apa3=0" },
> { "arm64.nomte", "id_aa64pfr1.mte=0" },
> - { "nokaslr", "kaslr.disabled=1" },
> + { "nokaslr", "arm64_sw.nokaslr=1" },
> };
I think structuring it as a sw feature makes more sense and I don't
think it breaks anything (as long as people only used "nokaslr").
Reviewed-by: Catalin Marinas <catalin.marinas@xxxxxxx>
As a side note, I was wondering if we should add a SW_FIELD macro to
define width of 1 for such fields (and probably the field extraction
functions need some tweaking) so that we define
ARM64_SW_FEATURE_OVERRIDE_* in increments of 1 rather than 4. Anyway,
that's something to worry if we get too many such software features.
--
Catalin
