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: <nycvar.YFH.7.76.2001290404240.31058@cbobk.fhfr.pm>
Date:   Wed, 29 Jan 2020 04:14:36 +0100 (CET)
From:   Jiri Kosina <jikos@...nel.org>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
cc:     Petr Mladek <pmladek@...e.com>, Miroslav Benes <mbenes@...e.cz>,
        Peter Zijlstra <peterz@...radead.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Joe Lawrence <joe.lawrence@...hat.com>,
        Jessica Yu <jeyu@...nel.org>, x86@...nel.org,
        linux-kernel@...r.kernel.org, mhiramat@...nel.org,
        bristot@...hat.com, jbaron@...mai.com,
        torvalds@...ux-foundation.org, tglx@...utronix.de,
        mingo@...nel.org, namit@...are.com, hpa@...or.com, luto@...nel.org,
        ard.biesheuvel@...aro.org, live-patching@...r.kernel.org,
        Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [PATCH v3 5/6] x86/ftrace: Use text_poke()

On Tue, 28 Jan 2020, Josh Poimboeuf wrote:

> > For the cases I've seen so far, it has always been gcc deciding under 
> > certain circumstances not to propagate __attribute__((__noreturn__)) from 
> > callee to caller even in the cases when caller unconditionally called 
> > callee.
> > 
> > AFAIU, the behavior is (and always will) be dependent on the state of gcc 
> > optimizations, and therefore I don't see any other way than adding 
> > __noreturn anotation transitively everywhere in order to silence objtool.
> > 
> > So those cases have to be fixed anyway.
> > 
> > What are the other cases please? Either I have completely missed those, or 
> > they haven't been mentioned in this thread.
> 
> For example, see:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/commit/?h=objtool-fixes&id=6265238af90b395a1e5e5032a41f012a552d8a9e
> 
> Many of those callees are static noreturns, for which we've *never*
> needed annotations.  Disabling -fipa-pure-const has apparently changed
> that.

For some reason I thought you were talking about static inlines, sorry for 
the noise.

Yeah, so I agree with you -- whether we need those anotations depends on 
compiler implementation of optimizations, and most importantly on (the 
current state of) internal implementation of specific optimizations in 
gcc.

Leaving live patching completely aside for the sake of this discussion for 
now -- I believe we either fully rely on gcc to propagate the 'noreturn' 
propery throughout the callstack upward, or we don't.

If we don't, then we do need the anotations (both the global and static 
ones), and problem solved.

If we do, well, where is the 'this is *the* behavior of any current/future 
clang^Wcompiler' invariant guarantee?

Thanks,

-- 
Jiri Kosina
SUSE Labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ