All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: Marc Zyngier <maz@kernel.org>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>,
	kvmarm <kvmarm@lists.cs.columbia.edu>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	David Brazdil <dbrazdil@google.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Jing Zhang <jingzhangos@google.com>,
	Ajay Patil <pajay@qti.qualcomm.com>,
	Prasad Sodagudi <psodagud@codeaurora.org>,
	Srinivas Ramana <sramana@codeaurora.org>,
	James Morse <james.morse@arm.com>,
	Julien Thierry <julien.thierry.kdev@gmail.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Android Kernel Team <kernel-team@android.com>
Subject: Re: [PATCH v5 18/21] arm64: Move "nokaslr" over to the early cpufeature infrastructure
Date: Mon, 25 Jan 2021 15:19:30 +0100	[thread overview]
Message-ID: <CAMj1kXGTu8AtMnm7NxB8M2xFuXHSKzAx2hjjeaAW2v-usvavVQ@mail.gmail.com> (raw)
In-Reply-To: <3a98ff1db79c90c96038b924eb534643@kernel.org>

On Mon, 25 Jan 2021 at 14:54, Marc Zyngier <maz@kernel.org> wrote:
>
> On 2021-01-25 12:54, Ard Biesheuvel wrote:
> > On Mon, 25 Jan 2021 at 11:53, Marc Zyngier <maz@kernel.org> wrote:
> >>
> >> Given that the early cpufeature infrastructure has borrowed quite
> >> a lot of code from the kaslr implementation, let's reimplement
> >> the matching of the "nokaslr" option with it.
> >>
> >> Signed-off-by: Marc Zyngier <maz@kernel.org>
> >> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> >> Acked-by: David Brazdil <dbrazdil@google.com>
> >> ---
> >>  arch/arm64/kernel/idreg-override.c | 15 +++++++++++++
> >>  arch/arm64/kernel/kaslr.c          | 36
> >> ++----------------------------
> >>  2 files changed, 17 insertions(+), 34 deletions(-)
> >>
> >> diff --git a/arch/arm64/kernel/idreg-override.c
> >> b/arch/arm64/kernel/idreg-override.c
> >> index cbb8eaa48742..3ccf51b84ba4 100644
> >> --- a/arch/arm64/kernel/idreg-override.c
> >> +++ b/arch/arm64/kernel/idreg-override.c
> >> @@ -31,8 +31,22 @@ static const struct ftr_set_desc mmfr1 __initdata =
> >> {
> >>         },
> >>  };
> >>
> >> +extern struct arm64_ftr_override kaslr_feature_override;
> >> +
> >> +static const struct ftr_set_desc kaslr __initdata = {
> >
> > This should be __initconst not __initdata (below too)
> >
> >> +       .name           = "kaslr",
> >> +#ifdef CONFIG_RANDOMIZE_BASE
> >> +       .override       = &kaslr_feature_override,
> >> +#endif
> >> +       .fields         = {
> >> +               { "disabled", 0 },
> >> +               {}
> >> +       },
> >> +};
> >> +
> >>  static const struct ftr_set_desc * const regs[] __initdata = {
> >>         &mmfr1,
> >> +       &kaslr,
> >>  };
> >>
> >>  static const struct {
> >> @@ -41,6 +55,7 @@ static const struct {
> >>  } aliases[] __initdata = {
> >>         { "kvm-arm.mode=nvhe",          "id_aa64mmfr1.vh=0" },
> >>         { "kvm-arm.mode=protected",     "id_aa64mmfr1.vh=0" },
> >> +       { "nokaslr",                    "kaslr.disabled=1" },
> >>  };
> >>
> >
> > This struct now takes up
> > - ~100 bytes for the characters themselves (which btw are not emitted
> > into __initdata or __initconst)
> > - 6x8 bytes for the char pointers
> > - 6x24 bytes for the RELA relocations that annotate these pointers as
> > quantities that need to be relocated at boot (on a kernel built with
> > KASLR)
> >
> > I know it's only a drop in the ocean, but in this case, where the
> > struct is statically declared and defined only once, and in the same
> > place, we could easily turn this into
> >
> > static const struct {
> >    char alias[24];
> >    char param[20];
> > };
> >
> > and get rid of all the overhead. The only slightly annoying thing is
> > that the array sizes need to be kept in sync with the largest instance
> > appearing in the array, but this is easy when the struct type is
> > declared in the same place where its only instance is defined.
>
> Fair enough. I personally find the result butt-ugly, but I agree
> that it certainly saves some memory. Does the following work for
> you? I can even give symbolic names to the various constants (how
> generous of me! ;-).
>

To be honest, I was anticipating more of a discussion, but this looks
reasonable to me. Does 'char    feature[80];' really need 80 bytes
though?

> diff --git a/arch/arm64/kernel/idreg-override.c
> b/arch/arm64/kernel/idreg-override.c
> index d1310438d95c..9e7043bdc808 100644
> --- a/arch/arm64/kernel/idreg-override.c
> +++ b/arch/arm64/kernel/idreg-override.c
> @@ -14,15 +14,15 @@
>   #include <asm/setup.h>
>
>   struct ftr_set_desc {
> -       const char                      *name;
> +       char                            name[20];
>         struct arm64_ftr_override       *override;
>         struct {
> -               const char              *name;
> +               char                    name[20];
>                 u8                      shift;
>         }                               fields[];
>   };
>
> -static const struct ftr_set_desc mmfr1 __initdata = {
> +static const struct ftr_set_desc mmfr1 __initconst = {
>         .name           = "id_aa64mmfr1",
>         .override       = &id_aa64mmfr1_override,
>         .fields         = {
> @@ -31,7 +31,7 @@ static const struct ftr_set_desc mmfr1 __initdata = {
>         },
>   };
>
> -static const struct ftr_set_desc pfr1 __initdata = {
> +static const struct ftr_set_desc pfr1 __initconst = {
>         .name           = "id_aa64pfr1",
>         .override       = &id_aa64pfr1_override,
>         .fields         = {
> @@ -40,7 +40,7 @@ static const struct ftr_set_desc pfr1 __initdata = {
>         },
>   };
>
> -static const struct ftr_set_desc isar1 __initdata = {
> +static const struct ftr_set_desc isar1 __initconst = {
>         .name           = "id_aa64isar1",
>         .override       = &id_aa64isar1_override,
>         .fields         = {
> @@ -54,7 +54,7 @@ static const struct ftr_set_desc isar1 __initdata = {
>
>   extern struct arm64_ftr_override kaslr_feature_override;
>
> -static const struct ftr_set_desc kaslr __initdata = {
> +static const struct ftr_set_desc kaslr __initconst = {
>         .name           = "kaslr",
>   #ifdef CONFIG_RANDOMIZE_BASE
>         .override       = &kaslr_feature_override,
> @@ -65,7 +65,7 @@ static const struct ftr_set_desc kaslr __initdata = {
>         },
>   };
>
> -static const struct ftr_set_desc * const regs[] __initdata = {
> +static const struct ftr_set_desc * const regs[] __initconst = {
>         &mmfr1,
>         &pfr1,
>         &isar1,
> @@ -73,9 +73,9 @@ static const struct ftr_set_desc * const regs[]
> __initdata = {
>   };
>
>   static const struct {
> -       const char      *alias;
> -       const char      *feature;
> -} aliases[] __initdata = {
> +       char    alias[30];
> +       char    feature[80];
> +} aliases[] __initconst = {
>         { "kvm-arm.mode=nvhe",          "id_aa64mmfr1.vh=0" },
>         { "kvm-arm.mode=protected",     "id_aa64mmfr1.vh=0" },
>         { "arm64.nobti",                "id_aa64pfr1.bt=0" },
>
> --
> Jazz is not dead. It just smells funny...

WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ardb@kernel.org>
To: Marc Zyngier <maz@kernel.org>
Cc: Prasad Sodagudi <psodagud@codeaurora.org>,
	Srinivas Ramana <sramana@codeaurora.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ajay Patil <pajay@qti.qualcomm.com>,
	Android Kernel Team <kernel-team@android.com>,
	Will Deacon <will@kernel.org>,
	kvmarm <kvmarm@lists.cs.columbia.edu>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v5 18/21] arm64: Move "nokaslr" over to the early cpufeature infrastructure
Date: Mon, 25 Jan 2021 15:19:30 +0100	[thread overview]
Message-ID: <CAMj1kXGTu8AtMnm7NxB8M2xFuXHSKzAx2hjjeaAW2v-usvavVQ@mail.gmail.com> (raw)
In-Reply-To: <3a98ff1db79c90c96038b924eb534643@kernel.org>

On Mon, 25 Jan 2021 at 14:54, Marc Zyngier <maz@kernel.org> wrote:
>
> On 2021-01-25 12:54, Ard Biesheuvel wrote:
> > On Mon, 25 Jan 2021 at 11:53, Marc Zyngier <maz@kernel.org> wrote:
> >>
> >> Given that the early cpufeature infrastructure has borrowed quite
> >> a lot of code from the kaslr implementation, let's reimplement
> >> the matching of the "nokaslr" option with it.
> >>
> >> Signed-off-by: Marc Zyngier <maz@kernel.org>
> >> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> >> Acked-by: David Brazdil <dbrazdil@google.com>
> >> ---
> >>  arch/arm64/kernel/idreg-override.c | 15 +++++++++++++
> >>  arch/arm64/kernel/kaslr.c          | 36
> >> ++----------------------------
> >>  2 files changed, 17 insertions(+), 34 deletions(-)
> >>
> >> diff --git a/arch/arm64/kernel/idreg-override.c
> >> b/arch/arm64/kernel/idreg-override.c
> >> index cbb8eaa48742..3ccf51b84ba4 100644
> >> --- a/arch/arm64/kernel/idreg-override.c
> >> +++ b/arch/arm64/kernel/idreg-override.c
> >> @@ -31,8 +31,22 @@ static const struct ftr_set_desc mmfr1 __initdata =
> >> {
> >>         },
> >>  };
> >>
> >> +extern struct arm64_ftr_override kaslr_feature_override;
> >> +
> >> +static const struct ftr_set_desc kaslr __initdata = {
> >
> > This should be __initconst not __initdata (below too)
> >
> >> +       .name           = "kaslr",
> >> +#ifdef CONFIG_RANDOMIZE_BASE
> >> +       .override       = &kaslr_feature_override,
> >> +#endif
> >> +       .fields         = {
> >> +               { "disabled", 0 },
> >> +               {}
> >> +       },
> >> +};
> >> +
> >>  static const struct ftr_set_desc * const regs[] __initdata = {
> >>         &mmfr1,
> >> +       &kaslr,
> >>  };
> >>
> >>  static const struct {
> >> @@ -41,6 +55,7 @@ static const struct {
> >>  } aliases[] __initdata = {
> >>         { "kvm-arm.mode=nvhe",          "id_aa64mmfr1.vh=0" },
> >>         { "kvm-arm.mode=protected",     "id_aa64mmfr1.vh=0" },
> >> +       { "nokaslr",                    "kaslr.disabled=1" },
> >>  };
> >>
> >
> > This struct now takes up
> > - ~100 bytes for the characters themselves (which btw are not emitted
> > into __initdata or __initconst)
> > - 6x8 bytes for the char pointers
> > - 6x24 bytes for the RELA relocations that annotate these pointers as
> > quantities that need to be relocated at boot (on a kernel built with
> > KASLR)
> >
> > I know it's only a drop in the ocean, but in this case, where the
> > struct is statically declared and defined only once, and in the same
> > place, we could easily turn this into
> >
> > static const struct {
> >    char alias[24];
> >    char param[20];
> > };
> >
> > and get rid of all the overhead. The only slightly annoying thing is
> > that the array sizes need to be kept in sync with the largest instance
> > appearing in the array, but this is easy when the struct type is
> > declared in the same place where its only instance is defined.
>
> Fair enough. I personally find the result butt-ugly, but I agree
> that it certainly saves some memory. Does the following work for
> you? I can even give symbolic names to the various constants (how
> generous of me! ;-).
>

To be honest, I was anticipating more of a discussion, but this looks
reasonable to me. Does 'char    feature[80];' really need 80 bytes
though?

> diff --git a/arch/arm64/kernel/idreg-override.c
> b/arch/arm64/kernel/idreg-override.c
> index d1310438d95c..9e7043bdc808 100644
> --- a/arch/arm64/kernel/idreg-override.c
> +++ b/arch/arm64/kernel/idreg-override.c
> @@ -14,15 +14,15 @@
>   #include <asm/setup.h>
>
>   struct ftr_set_desc {
> -       const char                      *name;
> +       char                            name[20];
>         struct arm64_ftr_override       *override;
>         struct {
> -               const char              *name;
> +               char                    name[20];
>                 u8                      shift;
>         }                               fields[];
>   };
>
> -static const struct ftr_set_desc mmfr1 __initdata = {
> +static const struct ftr_set_desc mmfr1 __initconst = {
>         .name           = "id_aa64mmfr1",
>         .override       = &id_aa64mmfr1_override,
>         .fields         = {
> @@ -31,7 +31,7 @@ static const struct ftr_set_desc mmfr1 __initdata = {
>         },
>   };
>
> -static const struct ftr_set_desc pfr1 __initdata = {
> +static const struct ftr_set_desc pfr1 __initconst = {
>         .name           = "id_aa64pfr1",
>         .override       = &id_aa64pfr1_override,
>         .fields         = {
> @@ -40,7 +40,7 @@ static const struct ftr_set_desc pfr1 __initdata = {
>         },
>   };
>
> -static const struct ftr_set_desc isar1 __initdata = {
> +static const struct ftr_set_desc isar1 __initconst = {
>         .name           = "id_aa64isar1",
>         .override       = &id_aa64isar1_override,
>         .fields         = {
> @@ -54,7 +54,7 @@ static const struct ftr_set_desc isar1 __initdata = {
>
>   extern struct arm64_ftr_override kaslr_feature_override;
>
> -static const struct ftr_set_desc kaslr __initdata = {
> +static const struct ftr_set_desc kaslr __initconst = {
>         .name           = "kaslr",
>   #ifdef CONFIG_RANDOMIZE_BASE
>         .override       = &kaslr_feature_override,
> @@ -65,7 +65,7 @@ static const struct ftr_set_desc kaslr __initdata = {
>         },
>   };
>
> -static const struct ftr_set_desc * const regs[] __initdata = {
> +static const struct ftr_set_desc * const regs[] __initconst = {
>         &mmfr1,
>         &pfr1,
>         &isar1,
> @@ -73,9 +73,9 @@ static const struct ftr_set_desc * const regs[]
> __initdata = {
>   };
>
>   static const struct {
> -       const char      *alias;
> -       const char      *feature;
> -} aliases[] __initdata = {
> +       char    alias[30];
> +       char    feature[80];
> +} aliases[] __initconst = {
>         { "kvm-arm.mode=nvhe",          "id_aa64mmfr1.vh=0" },
>         { "kvm-arm.mode=protected",     "id_aa64mmfr1.vh=0" },
>         { "arm64.nobti",                "id_aa64pfr1.bt=0" },
>
> --
> Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ardb@kernel.org>
To: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Jing Zhang <jingzhangos@google.com>,
	Prasad Sodagudi <psodagud@codeaurora.org>,
	Srinivas Ramana <sramana@codeaurora.org>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	James Morse <james.morse@arm.com>,
	Julien Thierry <julien.thierry.kdev@gmail.com>,
	Ajay Patil <pajay@qti.qualcomm.com>,
	Android Kernel Team <kernel-team@android.com>,
	David Brazdil <dbrazdil@google.com>,
	Will Deacon <will@kernel.org>,
	kvmarm <kvmarm@lists.cs.columbia.edu>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v5 18/21] arm64: Move "nokaslr" over to the early cpufeature infrastructure
Date: Mon, 25 Jan 2021 15:19:30 +0100	[thread overview]
Message-ID: <CAMj1kXGTu8AtMnm7NxB8M2xFuXHSKzAx2hjjeaAW2v-usvavVQ@mail.gmail.com> (raw)
In-Reply-To: <3a98ff1db79c90c96038b924eb534643@kernel.org>

On Mon, 25 Jan 2021 at 14:54, Marc Zyngier <maz@kernel.org> wrote:
>
> On 2021-01-25 12:54, Ard Biesheuvel wrote:
> > On Mon, 25 Jan 2021 at 11:53, Marc Zyngier <maz@kernel.org> wrote:
> >>
> >> Given that the early cpufeature infrastructure has borrowed quite
> >> a lot of code from the kaslr implementation, let's reimplement
> >> the matching of the "nokaslr" option with it.
> >>
> >> Signed-off-by: Marc Zyngier <maz@kernel.org>
> >> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> >> Acked-by: David Brazdil <dbrazdil@google.com>
> >> ---
> >>  arch/arm64/kernel/idreg-override.c | 15 +++++++++++++
> >>  arch/arm64/kernel/kaslr.c          | 36
> >> ++----------------------------
> >>  2 files changed, 17 insertions(+), 34 deletions(-)
> >>
> >> diff --git a/arch/arm64/kernel/idreg-override.c
> >> b/arch/arm64/kernel/idreg-override.c
> >> index cbb8eaa48742..3ccf51b84ba4 100644
> >> --- a/arch/arm64/kernel/idreg-override.c
> >> +++ b/arch/arm64/kernel/idreg-override.c
> >> @@ -31,8 +31,22 @@ static const struct ftr_set_desc mmfr1 __initdata =
> >> {
> >>         },
> >>  };
> >>
> >> +extern struct arm64_ftr_override kaslr_feature_override;
> >> +
> >> +static const struct ftr_set_desc kaslr __initdata = {
> >
> > This should be __initconst not __initdata (below too)
> >
> >> +       .name           = "kaslr",
> >> +#ifdef CONFIG_RANDOMIZE_BASE
> >> +       .override       = &kaslr_feature_override,
> >> +#endif
> >> +       .fields         = {
> >> +               { "disabled", 0 },
> >> +               {}
> >> +       },
> >> +};
> >> +
> >>  static const struct ftr_set_desc * const regs[] __initdata = {
> >>         &mmfr1,
> >> +       &kaslr,
> >>  };
> >>
> >>  static const struct {
> >> @@ -41,6 +55,7 @@ static const struct {
> >>  } aliases[] __initdata = {
> >>         { "kvm-arm.mode=nvhe",          "id_aa64mmfr1.vh=0" },
> >>         { "kvm-arm.mode=protected",     "id_aa64mmfr1.vh=0" },
> >> +       { "nokaslr",                    "kaslr.disabled=1" },
> >>  };
> >>
> >
> > This struct now takes up
> > - ~100 bytes for the characters themselves (which btw are not emitted
> > into __initdata or __initconst)
> > - 6x8 bytes for the char pointers
> > - 6x24 bytes for the RELA relocations that annotate these pointers as
> > quantities that need to be relocated at boot (on a kernel built with
> > KASLR)
> >
> > I know it's only a drop in the ocean, but in this case, where the
> > struct is statically declared and defined only once, and in the same
> > place, we could easily turn this into
> >
> > static const struct {
> >    char alias[24];
> >    char param[20];
> > };
> >
> > and get rid of all the overhead. The only slightly annoying thing is
> > that the array sizes need to be kept in sync with the largest instance
> > appearing in the array, but this is easy when the struct type is
> > declared in the same place where its only instance is defined.
>
> Fair enough. I personally find the result butt-ugly, but I agree
> that it certainly saves some memory. Does the following work for
> you? I can even give symbolic names to the various constants (how
> generous of me! ;-).
>

To be honest, I was anticipating more of a discussion, but this looks
reasonable to me. Does 'char    feature[80];' really need 80 bytes
though?

> diff --git a/arch/arm64/kernel/idreg-override.c
> b/arch/arm64/kernel/idreg-override.c
> index d1310438d95c..9e7043bdc808 100644
> --- a/arch/arm64/kernel/idreg-override.c
> +++ b/arch/arm64/kernel/idreg-override.c
> @@ -14,15 +14,15 @@
>   #include <asm/setup.h>
>
>   struct ftr_set_desc {
> -       const char                      *name;
> +       char                            name[20];
>         struct arm64_ftr_override       *override;
>         struct {
> -               const char              *name;
> +               char                    name[20];
>                 u8                      shift;
>         }                               fields[];
>   };
>
> -static const struct ftr_set_desc mmfr1 __initdata = {
> +static const struct ftr_set_desc mmfr1 __initconst = {
>         .name           = "id_aa64mmfr1",
>         .override       = &id_aa64mmfr1_override,
>         .fields         = {
> @@ -31,7 +31,7 @@ static const struct ftr_set_desc mmfr1 __initdata = {
>         },
>   };
>
> -static const struct ftr_set_desc pfr1 __initdata = {
> +static const struct ftr_set_desc pfr1 __initconst = {
>         .name           = "id_aa64pfr1",
>         .override       = &id_aa64pfr1_override,
>         .fields         = {
> @@ -40,7 +40,7 @@ static const struct ftr_set_desc pfr1 __initdata = {
>         },
>   };
>
> -static const struct ftr_set_desc isar1 __initdata = {
> +static const struct ftr_set_desc isar1 __initconst = {
>         .name           = "id_aa64isar1",
>         .override       = &id_aa64isar1_override,
>         .fields         = {
> @@ -54,7 +54,7 @@ static const struct ftr_set_desc isar1 __initdata = {
>
>   extern struct arm64_ftr_override kaslr_feature_override;
>
> -static const struct ftr_set_desc kaslr __initdata = {
> +static const struct ftr_set_desc kaslr __initconst = {
>         .name           = "kaslr",
>   #ifdef CONFIG_RANDOMIZE_BASE
>         .override       = &kaslr_feature_override,
> @@ -65,7 +65,7 @@ static const struct ftr_set_desc kaslr __initdata = {
>         },
>   };
>
> -static const struct ftr_set_desc * const regs[] __initdata = {
> +static const struct ftr_set_desc * const regs[] __initconst = {
>         &mmfr1,
>         &pfr1,
>         &isar1,
> @@ -73,9 +73,9 @@ static const struct ftr_set_desc * const regs[]
> __initdata = {
>   };
>
>   static const struct {
> -       const char      *alias;
> -       const char      *feature;
> -} aliases[] __initdata = {
> +       char    alias[30];
> +       char    feature[80];
> +} aliases[] __initconst = {
>         { "kvm-arm.mode=nvhe",          "id_aa64mmfr1.vh=0" },
>         { "kvm-arm.mode=protected",     "id_aa64mmfr1.vh=0" },
>         { "arm64.nobti",                "id_aa64pfr1.bt=0" },
>
> --
> Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-01-26  6:35 UTC|newest]

Thread overview: 114+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-25 10:49 [PATCH v5 00/21] arm64: Early CPU feature override, and applications to VHE, BTI and PAuth Marc Zyngier
2021-01-25 10:49 ` Marc Zyngier
2021-01-25 10:49 ` Marc Zyngier
2021-01-25 10:49 ` [PATCH v5 01/21] arm64: Fix labels in el2_setup macros Marc Zyngier
2021-01-25 10:49   ` Marc Zyngier
2021-01-25 10:49   ` Marc Zyngier
2021-01-25 10:50 ` [PATCH v5 02/21] arm64: Fix outdated TCR setup comment Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50 ` [PATCH v5 03/21] arm64: Turn the MMU-on sequence into a macro Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50 ` [PATCH v5 04/21] arm64: Provide an 'upgrade to VHE' stub hypercall Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 12:13   ` Catalin Marinas
2021-01-25 12:13     ` Catalin Marinas
2021-01-25 12:13     ` Catalin Marinas
2021-01-25 10:50 ` [PATCH v5 05/21] arm64: Initialise as nVHE before switching to VHE Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 12:13   ` Catalin Marinas
2021-01-25 12:13     ` Catalin Marinas
2021-01-25 12:13     ` Catalin Marinas
2021-01-25 10:50 ` [PATCH v5 06/21] arm64: Move VHE-specific SPE setup to mutate_to_vhe() Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 12:14   ` Catalin Marinas
2021-01-25 12:14     ` Catalin Marinas
2021-01-25 12:14     ` Catalin Marinas
2021-01-25 10:50 ` [PATCH v5 07/21] arm64: Simplify init_el2_state to be non-VHE only Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 12:14   ` Catalin Marinas
2021-01-25 12:14     ` Catalin Marinas
2021-01-25 12:14     ` Catalin Marinas
2021-01-25 10:50 ` [PATCH v5 08/21] arm64: Move SCTLR_EL1 initialisation to EL-agnostic code Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50 ` [PATCH v5 09/21] arm64: cpufeature: Add global feature override facility Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 12:15   ` Catalin Marinas
2021-01-25 12:15     ` Catalin Marinas
2021-01-25 12:15     ` Catalin Marinas
2021-01-25 10:50 ` [PATCH v5 10/21] arm64: cpufeature: Use IDreg override in __read_sysreg_by_encoding() Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 12:19   ` Catalin Marinas
2021-01-25 12:19     ` Catalin Marinas
2021-01-25 12:19     ` Catalin Marinas
2021-01-25 10:50 ` [PATCH v5 11/21] arm64: Extract early FDT mapping from kaslr_early_init() Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50 ` [PATCH v5 12/21] arm64: cpufeature: Add an early command-line cpufeature override facility Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 18:37   ` Catalin Marinas
2021-01-25 18:37     ` Catalin Marinas
2021-01-25 18:37     ` Catalin Marinas
2021-01-25 10:50 ` [PATCH v5 13/21] arm64: Allow ID_AA64MMFR1_EL1.VH to be overridden from the command line Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 13:15   ` Suzuki K Poulose
2021-01-25 13:15     ` Suzuki K Poulose
2021-01-25 13:15     ` Suzuki K Poulose
2021-01-25 13:55     ` Marc Zyngier
2021-01-25 13:55       ` Marc Zyngier
2021-01-25 13:55       ` Marc Zyngier
2021-01-25 18:37   ` Catalin Marinas
2021-01-25 18:37     ` Catalin Marinas
2021-01-25 18:37     ` Catalin Marinas
2021-01-25 10:50 ` [PATCH v5 14/21] arm64: Honor VHE being disabled from the command-line Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 18:38   ` Catalin Marinas
2021-01-25 18:38     ` Catalin Marinas
2021-01-25 18:38     ` Catalin Marinas
2021-01-25 10:50 ` [PATCH v5 15/21] arm64: Add an aliasing facility for the idreg override Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50 ` [PATCH v5 16/21] arm64: Make kvm-arm.mode={nvhe, protected} an alias of id_aa64mmfr1.vh=0 Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50 ` [PATCH v5 17/21] KVM: arm64: Document HVC_VHE_RESTART stub hypercall Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50 ` [PATCH v5 18/21] arm64: Move "nokaslr" over to the early cpufeature infrastructure Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 12:54   ` Ard Biesheuvel
2021-01-25 12:54     ` Ard Biesheuvel
2021-01-25 12:54     ` Ard Biesheuvel
2021-01-25 13:54     ` Marc Zyngier
2021-01-25 13:54       ` Marc Zyngier
2021-01-25 13:54       ` Marc Zyngier
2021-01-25 14:19       ` Ard Biesheuvel [this message]
2021-01-25 14:19         ` Ard Biesheuvel
2021-01-25 14:19         ` Ard Biesheuvel
2021-01-25 14:28         ` Marc Zyngier
2021-01-25 14:28           ` Marc Zyngier
2021-01-25 14:28           ` Marc Zyngier
2021-01-25 15:00           ` Ard Biesheuvel
2021-01-25 15:00             ` Ard Biesheuvel
2021-01-25 15:00             ` Ard Biesheuvel
2021-01-25 10:50 ` [PATCH v5 19/21] arm64: cpufeatures: Allow disabling of BTI from the command-line Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50 ` [PATCH v5 20/21] arm64: Defer enabling pointer authentication on boot core Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50 ` [PATCH v5 21/21] arm64: cpufeatures: Allow disabling of Pointer Auth from the command-line Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier
2021-01-25 10:50   ` Marc Zyngier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMj1kXGTu8AtMnm7NxB8M2xFuXHSKzAx2hjjeaAW2v-usvavVQ@mail.gmail.com \
    --to=ardb@kernel.org \
    --cc=alexandru.elisei@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=dbrazdil@google.com \
    --cc=james.morse@arm.com \
    --cc=jingzhangos@google.com \
    --cc=julien.thierry.kdev@gmail.com \
    --cc=kernel-team@android.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=pajay@qti.qualcomm.com \
    --cc=psodagud@codeaurora.org \
    --cc=sramana@codeaurora.org \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.