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: <CAMn1gO7ai3EvHhepJJQXOvjc8_Mp6DEAZg0J1gMKSJTECnU0VA@mail.gmail.com>
Date: Fri, 2 May 2025 11:03:02 -0700
From: Peter Collingbourne <pcc@...gle.com>
To: Catalin Marinas <catalin.marinas@....com>
Cc: David Hildenbrand <david@...hat.com>, 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
Subject: Re: [PATCH v3 2/4] prtcl: introduce PR_MTE_STORE_ONLY

On Fri, May 2, 2025 at 10:37 AM Catalin Marinas <catalin.marinas@....com> wrote:
>
> 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).

If it's 8 bits per tag wouldn't the exclusion mask need to be 256
bits? I probably wouldn't try to anticipate this case since it would
likely require a different API anyway.

Peter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ