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 10:24:06 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     David Laight <David.Laight@...lab.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

On Tue, Sep 01, 2020 at 03:00:44PM +0000, David Laight wrote:
> e 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?

In-place training of the branch predictor, and L1 timing attacks are
both trivial.

The harder part is finding another gadget to build on the speculative
load.  But there have been no shortage of new and creative ways to do
that over the last three years.

Also, since Spectre v1 affects many architectures, and may never get
fixed in HW, it's wise to harden these classes of attacks, especially if
we can do so easily.

Yes, it's not as efficient as it could be, but at least I think it's
better than the existing LFENCE.  And it will get more efficient after
Christoph's set_fs() removal, and then even more so when we move the
masking to inside access_ok().

-- 
Josh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ