Hello,

Is the branch where the MTE patches currently are being applied
for-net/mte?  It looks like that's the place, but I want to confirm.

On Tue, Sep 8, 2020 at 11:42 AM Catalin Marinas [off-list ref] wrote:

On Tue, Sep 08, 2020 at 04:02:06PM +0200, Andrey Konovalov wrote:

quoted

On Thu, Aug 27, 2020 at 2:16 PM Catalin Marinas [off-list ref] wrote:

quoted

On Thu, Aug 27, 2020 at 11:56:49AM +0100, Vincenzo Frascino wrote:

quoted

On 8/27/20 11:38 AM, Catalin Marinas wrote:

quoted

On Fri, Aug 14, 2020 at 07:27:06PM +0200, Andrey Konovalov wrote:

quoted

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.

quoted

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

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

-- 
Derrick McKee
Phone: (703) 957-9362
Email: derrick.mckee@gmail.com

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