linux-kernel - Re: [GIT PULL] core kernel fixes

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: <20171105195346.ndwucxwfhq25gqtp@treble>
Date:   Sun, 5 Nov 2017 13:53:46 -0600
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] core kernel fixes

On Sun, Nov 05, 2017 at 10:09:59AM -0800, Linus Torvalds wrote:
> On Sun, Nov 5, 2017 at 6:33 AM, Ingo Molnar <mingo@...nel.org> wrote:
> >
> > Please note that this pull request is RFC due to the top commit:
> >
> >   ec1e1b610917: objtool: Prevent GCC from merging annotate_unreachable(), take 2
> >
> > ... which is admittedly somewhat of an ad-hoc workaround for something the
> > compiler should have done - if there's another solution we can try that.
> 
> So I'm certainly ok with that workaround since apparently "asm
> volatile" doesn't do it.
> 
> That said, I think that if that asm needs to not be merged, it should
> _also_ be marked as "volatile" - since that's the documented bit for
> "not moved significantly". Of course, then because apparently that
> isn't enough, the __COUNTER__ games are ok, but might really mention
> an explicit comment in the code as to why they exist. Because right
> now they look just odd and nonsensical.

The GCC manual says:

  "asm statements that have no output operands, including asm goto
   statements, are implicitly volatile."

Since these macros have input operands, but no output operands, I assume
they're already implicitly volatile.  But we can certainly make it
explicit.  And yes, a comment would be good.

Something like so?

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 3672353a0acd..188ed9f65517 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -88,17 +88,22 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
 
 /* Unreachable code */
 #ifdef CONFIG_STACK_VALIDATION
+/*
+ * These macros help objtool understand GCC code flow for unreachable code.
+ * The __COUNTER__ based labels are a hack to make each instance of the macros
+ * unique, to convince GCC not to merge duplicate inline asm statements.
+ */
 #define annotate_reachable() ({						\
-	asm("%c0:\n\t"							\
-	    ".pushsection .discard.reachable\n\t"			\
-	    ".long %c0b - .\n\t"					\
-	    ".popsection\n\t" : : "i" (__COUNTER__));			\
+	asm volatile("%c0:\n\t"						\
+		     ".pushsection .discard.reachable\n\t"		\
+		     ".long %c0b - .\n\t"				\
+		     ".popsection\n\t" : : "i" (__COUNTER__));		\
 })
 #define annotate_unreachable() ({					\
-	asm("%c0:\n\t"							\
-	    ".pushsection .discard.unreachable\n\t"			\
-	    ".long %c0b - .\n\t"					\
-	    ".popsection\n\t" : : "i" (__COUNTER__));			\
+	asm volatile("%c0:\n\t"						\
+		     ".pushsection .discard.unreachable\n\t"		\
+		     ".long %c0b - .\n\t"				\
+		     ".popsection\n\t" : : "i" (__COUNTER__));		\
 })
 #define ASM_UNREACHABLE							\
 	"999:\n\t"							\