linux-kernel - Re: [PATCH] x86/uaccess: Use pointer masking to limit uaccess speculation

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20200904160006.GA21956@C02TD0UTHF1T.local>
Date:   Fri, 4 Sep 2020 17:00:06 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Christoph Hellwig <hch@....de>
Cc:     Josh Poimboeuf <jpoimboe@...hat.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Will Deacon <will@...nel.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Waiman Long <longman@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH] x86/uaccess: Use pointer masking to limit uaccess
 speculation

On Thu, Sep 03, 2020 at 08:56:13AM +0200, Christoph Hellwig wrote:
> On Wed, Sep 02, 2020 at 06:23:30PM +0100, Mark Rutland wrote:
> > I've pushed an initial/incomplete/WIP stab (just the kernel accessors)
> > to:
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/set_fs-removal
> 
> Thanks!
> 
> > ... and doing that made it clear that the necessary arm64 rework is a
> > bit more fractal than I thought (e.g. SDEI bits), so it might be a short
> > while before I post a series.
> 
> SDEI is just forcing back a KERNEL_DS to a normal USER_DS, isn't it?
 
It's a bit more involved -- we also need to fiddle with some HW state
(PSTATE.PAN, PSTATE.UAO, and TTBR0 for SW_PAN) because SDEI isn't a real
exception, so we have to simulate what HW (or the usual exception code)
does for exception entry/return.

It's simple enough to handle, but requires some refactoring as we now
rely on force_uaccess_{begin,end}() having those HW side-effects. I'll
probably factor that out into new arm64-specific helpers for simulating
exception entry/return (which we used to open-code) since it's the only
special case and that'll be clearer than repurposing generic helpers to
do so.

> > It might be handy to have a stable branch with the common bits so that
> > the arm64 rework could go via the arm64 tree in case there's any
> > fallout.
> 
> The series will need at least one more repost, but hopefully I'll have
> s stable branch soon.

I'll keep an eye out!

Mark.