linux-kernel - Re: [PATCH 2/7] objtool: Extend UNWIND

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220526150549.vqvggcuqmw2baslp@treble>
Date:   Thu, 26 May 2022 08:05:49 -0700
From:   Josh Poimboeuf <jpoimboe@...nel.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     x86@...nel.org, jpoimboe@...hat.com, linux-kernel@...r.kernel.org,
        elver@...gle.com, jbaron@...mai.com, rostedt@...dmis.org,
        ardb@...nel.org, mark.rutland@....com
Subject: Re: [PATCH 2/7] objtool: Extend UNWIND_HINT based ENDBR rules

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@...radead.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