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:   Tue, 1 Sep 2020 15:00:44 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Josh Poimboeuf' <jpoimboe@...hat.com>
CC:     "'x86@...nel.org'" <x86@...nel.org>,
        "'linux-kernel@...r.kernel.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>,
        'Christoph Hellwig' <hch@....de>
Subject: RE: [PATCH] x86/uaccess: Use pointer masking to limit uaccess
 speculation

From: Josh Poimboeuf
> Sent: 01 September 2020 15:27
> 
> On Tue, Sep 01, 2020 at 08:32:20AM +0000, David Laight wrote:
> > > Yes, it would make sense to put the masking in access_ok() somehow.  But
> > > to do it properly, I think we'd first need to make access_ok() generic.
> > > Maybe that's do-able, but it would be a much bigger patch set.
> > >
> > > First I'd prefer to just fix x86, like my patch does.  Then we could do
> > > an access_ok() rework.
> >
> > If you do a modified access_ok() you get to (slowly) collect all
> > the important paths.
> > No point replicating the same test.
> >
> > A lot of the access_ok() can be deleted - maybe remove some __
> > from the following functions.
> > Or change to the variants that enable user-space accesses.
> 
> Well, yes, but that's a much bigger job which can be done later.

Isn't this all rather difficult to exploit though?
(Unlike the original Spectre which trivially let kernel
memory be read.)
Don't you need to manage to 'preset' the branch predictor and BTB
to the right state and then manage some kind of timing attack
on L1 cache?

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ