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]

Message-ID: <20180104120914.322fa95e@alans-desktop>
Date:   Thu, 4 Jan 2018 12:09:14 +0000
From:   Alan Cox <gnomes@...rguk.ukuu.org.uk>
To:     Pavel Machek <pavel@....cz>
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, 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.

That's all an optimization once we have correctness.

Alan