linux-kernel - Re: [PATCH v3 2/4] prtcl: introduce PR_MTE_STORE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aBUC5fsSVzGkQtUV@arm.com>
Date: Fri, 2 May 2025 18:37:41 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: David Hildenbrand <david@...hat.com>
Cc: Yeoreum Yun <yeoreum.yun@....com>, will@...nel.org, broonie@...nel.org,
	anshuman.khandual@....com, joey.gouly@....com, maz@...nel.org,
	oliver.upton@...ux.dev, frederic@...nel.org, james.morse@....com,
	hardevsinh.palaniya@...iconsignals.io,
	shameerali.kolothum.thodi@...wei.com, huangxiaojia2@...wei.com,
	mark.rutland@....com, samuel.holland@...ive.com,
	palmer@...osinc.com, charlie@...osinc.com,
	thiago.bauermann@...aro.org, bgray@...ux.ibm.com,
	tglx@...utronix.de, puranjay@...nel.org,
	yang@...amperecomputing.com, mbenes@...e.cz,
	joel.granados@...nel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, nd@....com,
	Peter Collingbourne <pcc@...gle.com>
Subject: Re: [PATCH v3 2/4] prtcl: introduce PR_MTE_STORE_ONLY

On Thu, Apr 24, 2025 at 10:34:57PM +0200, David Hildenbrand wrote:
> On 10.04.25 10:07, Yeoreum Yun wrote:
> > PR_MTE_STORE_ONLY is used to restrict the MTE tag check for store
> > opeartion only.
> > 
> > Signed-off-by: Yeoreum Yun <yeoreum.yun@....com>
> > ---
> >   include/uapi/linux/prctl.h | 2 ++
> >   1 file changed, 2 insertions(+)
> > 
> > diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h
> > index 15c18ef4eb11..83ac566251d8 100644
> > --- a/include/uapi/linux/prctl.h
> > +++ b/include/uapi/linux/prctl.h
> > @@ -244,6 +244,8 @@ struct prctl_mm_map {
> >   # define PR_MTE_TAG_MASK		(0xffffUL << PR_MTE_TAG_SHIFT)
> >   /* Unused; kept only for source compatibility */
> >   # define PR_MTE_TCF_SHIFT		1
> > +/* MTE tag check store only */
> > +# define PR_MTE_STORE_ONLY		(1UL << 19)
> 
> That is the next available bit after PR_MTE_TAG_MASK, correct?
> 
> Would we want to leave some space to grow PR_MTE_TAG_MASK in the future
> (could that happen?)?

The current mask covers 16 tags (bits 59:56 of a pointer) and given the
reluctance to have a tag storage of 4 bits per 16 bytes (3% of RAM), I
doubt we'd ever grow this.

However, you have a good point, we could indeed leave 32 bits for the
tag mask, just in case MTE gets so much traction that someone wants 8
bits per tag (and likely a bigger granule than 16 bytes). It doesn't
cost us anything to add additional bits from (PR_MTE_TAG_SHIFT + 32).

Thanks.

-- 
Catalin