linux-kernel - Re: Avoid speculative indirect calls in kernel

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:   Thu, 4 Jan 2018 14:32:14 +0100
From:   Pavel Machek <pavel@....cz>
To:     Alan Cox <gnomes@...rguk.ukuu.org.uk>
Cc:     Andi Kleen <andi@...stfloor.org>, tglx@...utronix.de,
        torvalds@...ux-foundation.org, gregkh@...ux-foundation.org,
        linux-kernel@...r.kernel.org, tim.c.chen@...ux.intel.com
Subject: Re: Avoid speculative indirect calls in kernel

On Thu 2018-01-04 12:09:14, Alan Cox wrote:
> On Thu, 4 Jan 2018 12:49:17 +0100
> Pavel Machek <pavel@....cz> wrote:
> 
> > Hi!
> > 
> > > This is a fix for Variant 2 in 
> > > https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
> > > 
> > > Any speculative indirect calls in the kernel can be tricked 
> > > to execute any kernel code, which may allow side channel
> > > attacks that can leak arbitrary kernel data.  
> > 
> > Ok.
> > 
> > > So we want to avoid speculative indirect calls in the kernel.
> > > 
> > > There's a special code sequence called a retpoline that can
> > > do indirect calls without speculation. We use a new compiler
> > > option -mindirect-branch=thunk-extern (gcc patch will be released
> > > separately) to recompile the kernel with this new sequence.  
> > 
> > So... this "retpoline" code is quite tricky; I guess it does the right
> > on recent Intel CPUs. Does it also do the right thing on all the AMD,
> > Cyrix, ... variants?
> > 
> > Is it neccessary on all the CPUs? I guess 486 does not need this?
> 
> It's architecturally valid x86 code so it should work on any x86-32
> processor.
> 
> You are correct older processors and some of the newer ones don't need
> it. AMD and VIA I don't know about but for Intel we can probably avoid it
> on older Atom, on Quark, and the really old CPUs nobody actually runs any
> more.

Ok. I guess I'd like to see comment in file explaining that.

> That's all an optimization once we have correctness.

Well, correctness first sounds as a good idea. OTOH for Spectre
problem, seems like a fix would be microcode update to flush branch
predictor caches on priviledge and context switches. That should make
it impractical to exploit for all the systems, not just latest Linux,
compiled by lastest Gcc, right?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)