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: <1516963050.30244.188.camel@infradead.org>
Date:   Fri, 26 Jan 2018 10:37:30 +0000
From:   David Woodhouse <dwmw2@...radead.org>
To:     Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     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 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:

--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -37,10 +37,15 @@
  * as gcc otherwise puts the data into the bss section and not into the init
  * section.
  */
+#if defined(RETPOLINE) && !defined(MODULE)
+#define __noretpoline __attribute__((indirect_branch("keep")))
+#else
+#define __noretpoline
+#endif
 
 /* These are for everybody (although not all archs will actually
    discard it in modules) */
-#define __init         __section(.init.text) __cold __inittrace __latent_entropy
+#define __init         __section(.init.text) __cold __inittrace __latent_entropy __noretpoline
 #define __initdata     __section(.init.data)
 #define __initconst    __section(.init.rodata)
 #define __exitdata     __section(.exit.data)


I had that once and dropped it because of concerns about VM guests
being "vulnerable" at boot time. But really, do they even have any
interesting data to purloin at that point? And shouldn't the hypervisor
be protecting them with STIBP if they have nasty HT siblings? 

(And if hypervisors do start doing that, it might be nice for a guest
to have a way to say "you can stop now; I'm safe")
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)