Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 25 Aug 2022 08:41:19 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Segher Boessenkool <segher@kernel.crashing.org>
Cc:     Borislav Petkov <bp@alien8.de>, X86 ML <x86@kernel.org>,
        Michael Matz <matz@suse.de>, linux-toolchains@vger.kernel.org,
        LKML <linux-kernel@vger.kernel.org>,
        Josh Poimboeuf <jpoimboe@redhat.com>
Subject: Re: [PATCH] x86/sev: Mark snp_abort() noreturn
Message-ID: <YwcZjxVkO/lspvmv@worktop.programming.kicks-ass.net>
References: <20220824152420.20547-1-bp@alien8.de>
 <20220824172929.GA25951@gate.crashing.org>
 <YwaN2HtMyM0YEdSB@worktop.programming.kicks-ass.net>
 <20220824224144.GC25951@gate.crashing.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220824224144.GC25951@gate.crashing.org>
Precedence: bulk

On Wed, Aug 24, 2022 at 05:41:44PM -0500, Segher Boessenkool wrote:

> It is!  A noreturn function (that doesn't warn like "warning: 'noreturn'
> function does return") does not have whatever your architecture uses for
> function returns in it.  Just like most non-noreturn functions that do
> not return btw: the attribute affects code generation of the *caller* of
> such functions.

Yeah, but objtool can't tell if the compiler just spazzed out and
stopped generating code or if it was intentional.

> > STT_FUNC_NORETURN would do I suppose, except then all
> > the tools will need to be taught how to deal with that, which is also
> > very painful.
> 
> What is that?  Even Google has no idea.  Hrm.

Something I just made up :-) A new symbol type for noreturn functions
would be very useful.

> What fundamental problem does objtool have in dealing with any normal
> compiled code itself?  Does it try to understand the semantics of the
> machine code (not very tractable), does it expect some magic markup to
> be generated together with the machine code, does it want to have
> compilers hamstrung wrt what kind of code they can generate?
> 
> There is some serious disconnect here, and I'm not even completely sure
> what it is :-(

Objtool follows control flow. As you said above, noreturn functions
behave differently and code-gen after a call to a noreturn function
stops.

Typically objtool expects a call instruction to return and continue on
the next instruction; if all of a sudden there's nothing there, it gets
suspicious and says the compiler messed up.

(FWIW, we've found a fair number of actual compiler bugs with this)

Now, as mentioned we have heuristics that try and detect if a function
is noreturn or not; but all those fail horribly if the function is in
another translation unit for example.