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]

Message-ID: <20190528154057.GD32006@arrakis.emea.arm.com>
Date:   Tue, 28 May 2019 16:40:58 +0100
From:   Catalin Marinas <catalin.marinas@....com>
To:     Andrew Murray <andrew.murray@....com>
Cc:     Andrey Konovalov <andreyknvl@...gle.com>,
        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,
        Felix Kuehling <Felix.Kuehling@....com>,
        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>,
        Dave Martin <Dave.Martin@....com>,
        Evgeniy Stepanov <eugenis@...gle.com>,
        linux-media@...r.kernel.org, Kevin Brodsky <kevin.brodsky@....com>,
        Kees Cook <keescook@...omium.org>,
        Ruben Ayrapetyan <Ruben.Ayrapetyan@....com>,
        Ramana Radhakrishnan <Ramana.Radhakrishnan@....com>,
        Alex Williamson <alex.williamson@...hat.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        linux-arm-kernel@...ts.infradead.org,
        Kostya Serebryany <kcc@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Yishai Hadas <yishaih@...lanox.com>,
        linux-kernel@...r.kernel.org,
        Jens Wiklander <jens.wiklander@...aro.org>,
        Lee Smith <Lee.Smith@....com>,
        Alexander Deucher <Alexander.Deucher@....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 03:54:11PM +0100, Andrew Murray wrote:
> On Mon, May 27, 2019 at 03:37:20PM +0100, Catalin Marinas wrote:
> > On Mon, May 06, 2019 at 06:30:51PM +0200, Andrey Konovalov wrote:
> > > This patch is a part of a series that extends arm64 kernel ABI to allow to
> > > pass tagged user pointers (with the top byte set to something else other
> > > than 0x00) as syscall arguments.
> > > 
> > > This patch allows tagged pointers to be passed to the following memory
> > > syscalls: brk, get_mempolicy, madvise, mbind, mincore, mlock, mlock2,
> > > mmap, mmap_pgoff, mprotect, mremap, msync, munlock, munmap,
> > > remap_file_pages, shmat and shmdt.
> > > 
> > > This is done by untagging pointers passed to these syscalls in the
> > > prologues of their handlers.
> > > 
> > > Signed-off-by: Andrey Konovalov <andreyknvl@...gle.com>
> > 
> > Actually, I don't think any of these wrappers get called (have you
> > tested this patch?). Following commit 4378a7d4be30 ("arm64: implement
> > syscall wrappers"), I think we have other macro names for overriding the
> > sys_* ones.
> 
> What is the value in adding these wrappers?

Not much value, initially proposed just to keep the core changes small.
I'm fine with moving them back in the generic code (but see below).

I think another aspect is how we define the ABI. Is allowing tags to
mlock() for example something specific to arm64 or would sparc ADI need
the same? In the absence of other architectures defining such ABI, my
preference would be to keep the wrappers in the arch code.

Assuming sparc won't implement untagged_addr(), we can place the macros
back in the generic code but, as per the review here, we need to be more
restrictive on where we allow tagged addresses. For example, if mmap()
gets a tagged address with MAP_FIXED, is it expected to return the tag?

My thoughts on allowing tags (quick look):

brk - no
get_mempolicy - yes
madvise - yes
mbind - yes
mincore - yes
mlock, mlock2, munlock - yes
mmap - no (we may change this with MTE but not for TBI)
mmap_pgoff - not used on arm64
mprotect - yes
mremap - yes for old_address, no for new_address (on par with mmap)
msync - yes
munmap - probably no (mmap does not return tagged ptrs)
remap_file_pages - no (also deprecated syscall)
shmat, shmdt - shall we allow tagged addresses on shared memory?

The above is only about the TBI ABI while ignoring hardware MTE. For the
latter, we may want to change the mmap() to allow pre-colouring on page
fault which means that munmap()/mprotect() should also support tagged
pointers. Possibly mremap() as well but we need to decide whether it
should allow re-colouring the page (probably no, in which case
old_address and new_address should have the same tag). For some of these
we'll end up with arm64 specific wrappers again, unless sparc ADI adopts
exactly the same ABI restrictions.

-- 
Catalin