Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Thu, 26 May 2022 08:05:49 -0700
From:   Josh Poimboeuf <jpoimboe@kernel.org>
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     x86@kernel.org, jpoimboe@redhat.com, linux-kernel@vger.kernel.org,
        elver@google.com, jbaron@akamai.com, rostedt@goodmis.org,
        ardb@kernel.org, mark.rutland@arm.com
Subject: Re: [PATCH 2/7] objtool: Extend UNWIND_HINT based ENDBR rules
Message-ID: <20220526150549.vqvggcuqmw2baslp@treble>
References: <20220526105252.440440893@infradead.org>
 <20220526105957.817269865@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20220526105957.817269865@infradead.org>
Precedence: bulk

On Thu, May 26, 2022 at 12:52:54PM +0200, Peter Zijlstra wrote:
> Extend the UNWIND hint driven rules for ENDBR placement. Currently
> objtool expects an ENDBR at any UNWINT_HINT_IRET_REGS that is at +0 of
> an STB_GLOBAL symbol, with the expectation that this is an exception
> entry point.
> 
> Extend this to also expect ENDBR at UNWIND_HINT_EMPTY at +0 for
> STB_GLOBAL symbols, with the expectation that these are also machine
> entry points (SYSCALL et. al.).
> 
> This guarantees all machine entry points are covered by objtool rules at
> the expense of a few additional false positives:
> 
>   vmlinux.o: warning: objtool: startup_64+0x0: UNWIND_HINT_EMPTY without ENDBR
>   vmlinux.o: warning: objtool: start_cpu0+0x0: UNWIND_HINT_EMPTY without ENDBR
> 
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>

I can't remember if this was my bright idea, but it feels kind of
arbitrary.  Hopefully there won't be a lot of false positives.

Anyway, won't SYSCALL-type symbols typically be referenced elsewhere in
the kernel and thus be found by the regular IBT validation?

Do you have any examples of where this warning would trigger if there
were a missing ENDBR?

-- 
Josh