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: <20180131092921.GI2269@hirez.programming.kicks-ass.net>
Date:   Wed, 31 Jan 2018 10:29:21 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     David Woodhouse <dwmw2@...radead.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        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 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:
> 
> --- 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)


Something like so then?

---

Subject: objtool: Add module specific retpoline rules
From: Peter Zijlstra <peterz@...radead.org>
Date: Wed Jan 31 10:18:28 CET 2018

David wanted to not use retpolines in .init.text but that will trip up
objtool retpoline validation, fix that.

Requested-by: David Woodhouse <dwmw2@...radead.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
---
 scripts/Makefile.build        |    2 ++
 tools/objtool/builtin-check.c |    3 ++-
 tools/objtool/builtin.h       |    2 +-
 tools/objtool/check.c         |    9 +++++++++
 4 files changed, 14 insertions(+), 2 deletions(-)

--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -256,6 +256,8 @@ __objtool_obj := $(objtree)/tools/objtoo
 
 objtool_args = $(if $(CONFIG_UNWINDER_ORC),orc generate,check)
 
+objtool_args += $(if $(part-of-module), --module,)
+
 ifndef CONFIG_FRAME_POINTER
 objtool_args += --no-fp
 endif
--- a/tools/objtool/builtin-check.c
+++ b/tools/objtool/builtin-check.c
@@ -29,7 +29,7 @@
 #include "builtin.h"
 #include "check.h"
 
-bool no_fp, no_unreachable, retpoline;
+bool no_fp, no_unreachable, retpoline, module;
 
 static const char * const check_usage[] = {
 	"objtool check [<options>] file.o",
@@ -40,6 +40,7 @@ const struct option check_options[] = {
 	OPT_BOOLEAN('f', "no-fp", &no_fp, "Skip frame pointer validation"),
 	OPT_BOOLEAN('u', "no-unreachable", &no_unreachable, "Skip 'unreachable instruction' warnings"),
 	OPT_BOOLEAN('r', "retpoline", &retpoline, "Validate retpoline assumptions"),
+	OPT_BOOLEAN('m', "module", &module, "Indicates the object will be part of a kernel module"),
 	OPT_END(),
 };
 
--- a/tools/objtool/builtin.h
+++ b/tools/objtool/builtin.h
@@ -20,7 +20,7 @@
 #include <subcmd/parse-options.h>
 
 extern const struct option check_options[];
-extern bool no_fp, no_unreachable, retpoline;
+extern bool no_fp, no_unreachable, retpoline, module;
 
 extern int cmd_check(int argc, const char **argv);
 extern int cmd_orc(int argc, const char **argv);
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -1920,6 +1920,15 @@ static int validate_retpoline(struct obj
 		if (insn->retpoline_safe)
 			continue;
 
+		/*
+		 * .init.text code is ran before userspace and thus doesn't
+		 * strictly need retpolines, except for modules which are
+		 * loaded late, they very much do need retpoline in their
+		 * .init.text
+		 */
+		if (!strcmp(insn->sec->name, ".init.text") && !module)
+			continue;
+
 		WARN_FUNC("indirect %s found in RETPOLINE build",
 			  insn->sec, insn->offset,
 			  insn->type == INSN_JUMP_DYNAMIC ? "jump" : "call");