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: <20190530165717.GC35418@arrakis.emea.arm.com>
Date:   Thu, 30 May 2019 17:57:18 +0100
From:   Catalin Marinas <catalin.marinas@....com>
To:     Khalid Aziz <khalid.aziz@...cle.com>
Cc:     Andrew Murray <andrew.murray@....com>,
        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 Thu, May 30, 2019 at 10:05:55AM -0600, Khalid Aziz wrote:
> On 5/30/19 9:11 AM, Catalin Marinas wrote:
> > So if a database program is doing an anonymous mmap(PROT_TBI) of 100GB,
> > IIUC for sparc the faulted-in pages will have random colours (on 64-byte
> > granularity). Ignoring the information leak from prior uses of such
> > pages, it would be the responsibility of the db program to issue the
> > stxa. On arm64, since we also want to do this via malloc(), any large
> > allocation would require all pages to be faulted in so that malloc() can
> > set the write colour before being handed over to the user. That's what
> > we want to avoid and the user is free to repaint the memory as it likes.
> 
> On sparc, any newly allocated page is cleared along with any old tags on
> it. Since clearing tag happens automatically when page is cleared on
> sparc, clear_user_page() will need to execute additional stxa
> instructions to set a new tag. It is doable. In a way it is done already
> if page is being pre-colored with tag 0 always ;)

Ah, good to know. On arm64 we'd have to use different instructions,
although the same loop.

> Where would the pre-defined tag be stored - as part of address stored
> in vm_start or a new field in vm_area_struct?

I think we can discuss the details when we post the actual MTE patches.
In our internal hack we overloaded the VM_HIGH_ARCH_* flags and selected
CONFIG_ARCH_USES_HIGH_VMA_FLAGS (used for pkeys on x86).

For the time being, I'd rather restrict tagged addresses passed to
mmap() until we agreed that they have any meaning. If we allowed them
now but get ignored (though probably no-one would be doing this), I feel
it's slightly harder to change the semantics afterwards.

Thanks.

-- 
Catalin