On Tue, Sep 08, 2020 at 04:02:06PM +0200, Andrey Konovalov wrote: > On Thu, Aug 27, 2020 at 2:16 PM Catalin Marinas <catalin.marinas@xxxxxxx> wrote: > > On Thu, Aug 27, 2020 at 11:56:49AM +0100, Vincenzo Frascino wrote: > > > On 8/27/20 11:38 AM, Catalin Marinas wrote: > > > > On Fri, Aug 14, 2020 at 07:27:06PM +0200, Andrey Konovalov wrote: > > > >> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c > > > >> index 7717ea9bc2a7..cfac7d02f032 100644 > > > >> --- a/arch/arm64/kernel/mte.c > > > >> +++ b/arch/arm64/kernel/mte.c > > > >> @@ -18,10 +18,14 @@ > > > >> > > > >> #include <asm/barrier.h> > > > >> #include <asm/cpufeature.h> > > > >> +#include <asm/kasan.h> > > > >> +#include <asm/kprobes.h> > > > >> #include <asm/mte.h> > > > >> #include <asm/ptrace.h> > > > >> #include <asm/sysreg.h> > > > >> > > > >> +u64 gcr_kernel_excl __read_mostly; > > > > > > > > Could we make this __ro_after_init? > > > > > > Yes, it makes sense, it should be updated only once through mte_init_tags(). > > > > > > Something to consider though here is that this might not be the right approach > > > if in future we want to add stack tagging. In such a case we need to know the > > > kernel exclude mask before any C code is executed. Initializing the mask via > > > mte_init_tags() it is too late. > > > > It depends on how stack tagging ends up in the kernel, whether it uses > > ADDG/SUBG or not. If it's only IRG, I think it can cope with changing > > the GCR_EL1.Excl in the middle of a function. > > > > > I was thinking to add a compilation define instead of having gcr_kernel_excl in > > > place. This might not work if the kernel excl mask is meant to change during the > > > execution. > > > > A macro with the default value works for me. That's what it basically is > > currently, only that it ends up in a variable. > > Some thoughts on the topic: gcr_kernel_excl is currently initialized > in mte_init_tags() and depends on the max_tag value dynamically > provided to it, so it's not something that can be expressed with a > define. In the case of KASAN the max_tag value is static, but if we > rely on that we make core MTE code depend on KASAN, which doesn't seem > right from the design perspective. The design is debatable. If we want MTE to run on production devices, we either (1) optimise out some bits of KASAN (configurable) or (2) we decouple MTE and KASAN completely and add new callbacks in the core code (slab allocator etc.) specific to MTE. My first choice is (1), unless there is a strong technical argument why it is not possible. -- Catalin
