Messages in this thread | | | Date | Sat, 28 May 2022 16:09:13 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH 2/7] objtool: Extend UNWIND_HINT based ENDBR rules |
| |
On Thu, May 26, 2022 at 08:05:49AM -0700, Josh Poimboeuf wrote: > 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.
The existing UNWIND_HINT_IRET_REGS at +0 was your idea, I'm just trying to cover more.
> Anyway, won't SYSCALL-type symbols typically be referenced elsewhere in > the kernel and thus be found by the regular IBT validation?
They do indeed, and that's what we've been relying on. I just figured it would be more consistent to have rules covering all machine entry points.
(also all the Xen entry points are EMPTY like).
> Do you have any examples of where this warning would trigger if there > were a missing ENDBR?
No.
Anyway, I can drop these first two patches for now.
| |