linux-kernel - Re: [PATCH 08/24] x86,sme: Annotate indirect call

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: <20180131150451.5m2pg4u33d72bpbw@treble>
Date:   Wed, 31 Jan 2018 09:04:51 -0600
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     David Woodhouse <dwmw2@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org, Dave Hansen <dave.hansen@...el.com>,
        Ashok Raj <ashok.raj@...el.com>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Arjan Van De Ven <arjan.van.de.ven@...el.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Jun Nakajima <jun.nakajima@...el.com>,
        Asit Mallick <asit.k.mallick@...el.com>,
        Jason Baron <jbaron@...mai.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Borislav Petkov <bp@...e.de>
Subject: Re: [PATCH 08/24] x86,sme: Annotate indirect call

On Wed, Jan 31, 2018 at 10:29:21AM +0100, Peter Zijlstra wrote:
> On Fri, Jan 26, 2018 at 10:37:30AM +0000, David Woodhouse wrote:
> > On Tue, 2018-01-23 at 16:25 +0100, Peter Zijlstra wrote:
> > > This is boot code, we run this _way_ before userspace comes along to
> > > poison our branch predictor.
> > 
> > Hm, objtool knows about sections, doesn't it? Why it is whining about
> > indirect jumps in inittext anyway?
> > 
> > In fact, why are we even *doing* retpolines in inittext? Not that we
> > are; since we flipped the ALTERNATIVE logic around, at that point we
> > still have the 'oldinstr' which is a bare jmp anyway. We might as well
> > do this:

Ont the other hand, is there any harm in doing retpolines in .init.text?

I also had a similar question about the ANNOTATE_RETPOLINE_SAFE thing.

If there's no harm, it would be simpler and more robust to just do
retpolines everywhere and not worry about special cases.

(Forgetting paravirt for the moment, which is the eternal "special
case".)

I was also thinking about adding a debug option for _runtime_ retpoline
verification that decodes all kernel text and reports any indirect
branches it finds (yes, kind of like an in-kernel objtool).  That would
be a lot more straightforward without special cases.  Obviously
.init.text wouldn't be a problem there, but the other annotated safe
locations would.

-- 
Josh