Re: [PATCH v2 2/3] kasan: skip HW tagging for all kernel thread stacks

[Catalin Marinas <catalin.marinas@arm.com>]

On Wed, Apr 22, 2026 at 02:31:14PM +0100, Ryan Roberts wrote:
> On 17/04/2026 09:31, Catalin Marinas wrote:
> > On Thu, Apr 16, 2026 at 11:03:46AM +0200, David Hildenbrand wrote:
> >> On 4/10/26 20:36, Catalin Marinas wrote:
> >>> On Fri, Apr 10, 2026 at 07:32:23PM +0100, Catalin Marinas wrote:
> >>>> What the original approach might help with is use-after-realloc in case
> >>>> we had a tagged pointer in a past life of a page and it still works now.
> >>>> Oh well, that's I guess for other types of hardening to address like
> >>>> delayed reallocation.
> >>>
> >>> Another thought (for a separate series) - we could try to map the stack
> >>> as Untagged (unless stack tagging is enabled; needs compiler
> >>> instrumentation) and enable canonical tag checking (newer addition to
> >>> MTE). This way, any stray tagged pointer won't work on the stack since
> >>> it needs a 0xf tag (canonical).
> >>
> >> Do you mean mapping it as Untagged in the vmap for CONFIG_VMAP_STACK or
> >> also as Untagged in the directmap?
> >>
> >> The latter brings in the set of problems with direct map fragmentation.
> > 
> > Just the vmap, there are a lot more problems with the direct map. Not
> > sure how much it does in terms of security, maybe marginally. A
> > match-all tag (0xf) would still be able to access the canonically tagged
> > memory.
> 
> I think with the first patch in this series, we are alredy vmapping the stack
> memory as untagged, right? vmalloc only calls arch_vmap_pgprot_tagged() if we
> are not skipping kasan. So I think we already have this protection? (perhaps we
> need to explicitly enable the canonical tag checks?)

Ah, yes, good point. So, we could just enable canonical tag checking so
that untagged memory only uses the 0xf tag while in the kernel (not sure
what might break but in theory these would only happen if we have use
after free bugs etc.)

I think it's just a matter of setting TCR_EL1.MTX1 but it has some
implications on the PAC bits. This setting would affect the kernel
image mapping, modules. Anyway, something to investigate separately.

-- 
Catalin