Re: [tip: x86/core] objtool: Find unused ENDBR instructions
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [tip: x86/core] objtool: Find unused ENDBR instructions
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
- Date: Fri, 18 Mar 2022 11:49:58 +0100
- Cc: David Laight <David.Laight@xxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, "linux-tip-commits@xxxxxxxxxxxxxxx" <linux-tip-commits@xxxxxxxxxxxxxxx>, "x86@xxxxxxxxxx" <x86@xxxxxxxxxx>
- In-reply-to: <20220317222254.lm2f2337jejcf3uu@treble>
- References: <20220308154319.763643193@infradead.org> <164734101940.16921.11639161864874862247.tip-bot2@tip-bot2> <a5fa50d9f00542de8a6ad7a3fe0c49b3@AcuMS.aculab.com> <20220317222254.lm2f2337jejcf3uu@treble>
On Thu, Mar 17, 2022 at 03:22:54PM -0700, Josh Poimboeuf wrote:
> On Tue, Mar 15, 2022 at 03:39:52PM +0000, David Laight wrote:
> > From: Peter Zijlstra
> > >
> > > objtool: Find unused ENDBR instructions
> > >
> > > Find all ENDBR instructions which are never referenced and stick them
> > > in a section such that the kernel can poison them, sealing the
> > > functions from ever being an indirect call target.
> >
> > Thought, what happens if the only indirect call is from
> > code in a module?
>
> Then <boom>, I guess. Is it safe to assume in-tree modules don't need
> to do indirect calls to exported functions? I guess we'll find out :-)
So exported functions will keep their ENDBR. Specifically, their address
is taken by the EXPORT_SYMBOL thing.
Sealing them might work, but let's not do that just now ;-)
Any unexported function discovered through kallsyms OTOH... those
deservedly will go *boom*.
[Index of Archives]
[Linux Stable Commits]
[Linux Stable Kernel]
[Linux Kernel]
[Linux USB Devel]
[Linux Video &Media]
[Linux Audio Users]
[Yosemite News]
[Linux SCSI]