linux-kernel - Re: [PATCH v15 05/17] arms64: untag user pointers passed to memory syscalls

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]

Date:   Wed, 29 May 2019 13:42:25 +0100
From:   Dave Martin <Dave.Martin@....com>
To:     Catalin Marinas <catalin.marinas@....com>
Cc:     Mark Rutland <mark.rutland@....com>, kvm@...r.kernel.org,
        Szabolcs Nagy <Szabolcs.Nagy@....com>,
        Will Deacon <will.deacon@....com>,
        dri-devel@...ts.freedesktop.org, linux-mm@...ck.org,
        linux-kselftest@...r.kernel.org,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        Jacob Bramley <Jacob.Bramley@....com>,
        Leon Romanovsky <leon@...nel.org>, linux-rdma@...r.kernel.org,
        amd-gfx@...ts.freedesktop.org, Dmitry Vyukov <dvyukov@...gle.com>,
        Ramana Radhakrishnan <Ramana.Radhakrishnan@....com>,
        Evgeniy Stepanov <eugenis@...gle.com>,
        linux-media@...r.kernel.org, Kees Cook <keescook@...omium.org>,
        Ruben Ayrapetyan <Ruben.Ayrapetyan@....com>,
        Andrey Konovalov <andreyknvl@...gle.com>,
        Kevin Brodsky <kevin.brodsky@....com>,
        Alex Williamson <alex.williamson@...hat.com>,
        Yishai Hadas <yishaih@...lanox.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        linux-arm-kernel@...ts.infradead.org,
        Kostya Serebryany <kcc@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Felix Kuehling <Felix.Kuehling@....com>,
        linux-kernel@...r.kernel.org,
        Jens Wiklander <jens.wiklander@...aro.org>,
        Lee Smith <Lee.Smith@....com>,
        Alexander Deucher <Alexander.Deucher@....com>,
        Andrew Murray <andrew.murray@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Robin Murphy <robin.murphy@....com>,
        Christian Koenig <Christian.Koenig@....com>,
        Luc Van Oostenryck <luc.vanoostenryck@...il.com>
Subject: Re: [PATCH v15 05/17] arms64: untag user pointers passed to memory
 syscalls

On Tue, May 28, 2019 at 05:34:00PM +0100, Catalin Marinas wrote:
> On Tue, May 28, 2019 at 04:56:45PM +0100, Dave P Martin wrote:
> > On Tue, May 28, 2019 at 04:40:58PM +0100, Catalin Marinas wrote:
> > 
> > [...]
> > 
> > > My thoughts on allowing tags (quick look):
> > >
> > > brk - no
> > 
> > [...]
> > 
> > > mlock, mlock2, munlock - yes
> > > mmap - no (we may change this with MTE but not for TBI)
> > 
> > [...]
> > 
> > > mprotect - yes
> > 
> > I haven't following this discussion closely... what's the rationale for
> > the inconsistencies here (feel free to refer me back to the discussion
> > if it's elsewhere).
> 
> _My_ rationale (feel free to disagree) is that mmap() by default would
> not return a tagged address (ignoring MTE for now). If it gets passed a
> tagged address or a "tagged NULL" (for lack of a better name) we don't
> have clear semantics of whether the returned address should be tagged in
> this ABI relaxation. I'd rather reserve this specific behaviour if we
> overload the non-zero tag meaning of mmap() for MTE. Similar reasoning
> for mremap(), at least on the new_address argument (not entirely sure
> about old_address).
> 
> munmap() should probably follow the mmap() rules.
> 
> As for brk(), I don't see why the user would need to pass a tagged
> address, we can't associate any meaning to this tag.
> 
> For the rest, since it's likely such addresses would have been tagged by
> malloc() in user space, we should allow tagged pointers.

Those arguments seem reasonable.  We should try to capture this
somewhere when documenting the ABI.

To be clear, I'm not sure that we should guarantee anywhere that a
tagged pointer is rejected: rather the behaviour should probably be
left unspecified.  Then we can tidy it up incrementally.

(The behaviour is unspecified today, in any case.)

Cheers
---Dave