[PATCH v2 0/4] support FEAT_MTE_STORE_ONLY feature

[Yeoreum Yun]

Hi David,

> On 04.04.25 21:33, Yeoreum Yun wrote:
> > Hi David.
> >
> > > On 03.04.25 19:46, Yeoreum Yun wrote:
> > > > The FEAT_MTE_STORE_ONLY feature provides support for
> > > > tag check for store operation only. read operation is considered
> > > > as unchecked operation so it doesn't raise tag check fault.
> > >
> > > Can you add/share more details of what the implications are, how it would be
> > > used, who would set it, etc.
> > >
> > > Just from staring at this short paragraph leaves me rather clueless.
> > >
> >
> > Sorry for my bad.
> >
> > ARMv8.5 based processors introduce the Memory Tagging Extension (MTE) feature.
> > MTE is built on top of the ARMv8.0 virtual address tagging TBI
> > (Top Byte Ignore) feature and allows software to access a 4-bit
> > allocation tag for each 16-byte granule in the physical address space.
> > A logical tag is derived from bits 59-56 of the virtual
> > address used for the memory access. A CPU with MTE enabled will compare
> > the logical tag against the allocation tag and potentially raise an
> > tag check fault on mismatch, subject to system registers configuration.
> >
> > Since ARMv8.9, FEAT_MTE_STORE_ONLY can be used to restrict raise of tag
> > check fault on store operation only.
>
> Oh, so other operations (read/fetch) will not check the tag.

Yes it is. the read operation considered as uncheck, so it wouldn't
check the tag.

> > For this, application can use PR_MTE_STORE_ONLY flag
> > when it sets the MTE setting with prctl().
> >
> > This would be useful for debugging purpose
> > i.e) finding memory courruption point, use-after-free and etc.
>
> So what's the benefit of this relaxation? I assume it's faster because less
> memory access has to perform tag checks, and the issues you mention here can
> still be mostly caught (not all cases of use-after-free, but at least the
> destructive ones).

Right. but as you mention, the to reduce overhead by omitting the
tag check on read operation (sometime this overhead is too much than
gain some benefit) [0]

[0] https://www.usenix.org/conference/woot24/presentation/jacobs


Thanks.
--
Sincerely,
Yeoreum Yun