Re: [PATCH] objtool: Deal with relative jump tables correctly

[Josh Poimboeuf]

[ Adding Jan and Jose for the jump table annotation discussion below ]

On Wed, Oct 09, 2024 at 05:18:36PM +0200, Ard Biesheuvel wrote:
> On Tue, 8 Oct 2024 at 19:42, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:
> >
> > On Tue, Oct 08, 2024 at 12:47:48AM +0200, Ard Biesheuvel wrote:
> > > -     /*
> > > -      * Use of RIP-relative switch jumps is quite rare, and
> > > -      * indicates a rare GCC quirk/bug which can leave dead
> > > -      * code behind.
> > > -      */
> > > -     if (reloc_type(text_reloc) == R_X86_64_PC32)
> > > -             file->ignore_unreachables = true;
> > > -
> >
> > I'm not sure if this bug still exists on current GCC versions.  If so,
> > it will start reporting "unreachable instruction" warnings again and
> > we'll have to figure out a way to resolve that.
> >
> 
> Ah, I mistook this for a check against the first entry in the table,
> but it is the reference *to* the table from the code.
> 
> So I'll just leave this alone.

But then with -fpie, unreachable instructions would always be ignored,
which is not ideal as those warnings are actually very useful and often
point to bigger problems.

> Thanks. I've added another tweak locally so validate_ibt_data_reloc()
> uses the corrected offset as well, or I end up with !ENDBR warnings.
> So with that in place, objtool can decipher the jump table if it
> manages to recognize it as one.
> 
> However, there are pathological cases (see one below) where the LEA
> that takes the address of the jump table is ridiculously far away from
> the indirect jump, resulting in a warning like
> 
> vmlinux.o: warning: objtool: fdt_pmu_probe_pmu_dev.isra.0+0x229:
> sibling call from callable instruction with modified stack frame
> 
> 
> This is with GCC 14 (it is the only warning introduced by PIC codegen
> in an allmodconfig build), and I suspect that this might happen with
> non-PIC codegen too, right?
> 
> So how important is jump table support now that it is turned off in
> most cases?

For x86 I believe -fjump-tables is still a possibility in some configs,
so it still needs to work.  That said we may be behind on keeping up
with all the latest warnings.  Jump table detection has always been
whack-a-mole hacks.

And we'd want to support it for other arches as well.

> And has there been any movement on compiler annotations?
> If this is worth while, it is something I could look into: Kees and I
> work very closely with both the GCC and the Clang folks, and have
> contributed other features that are specific to the kernel.

I spoke with several people about this at GNU Cauldron last month and
there is definitely interest in helping out.  If you and Kees also want
to help out, that would be awesome.

Jan proposed an idea to apply a R_*_NONE relocation at the indirect
branch instruction which references the jump table address.  And then
emit a sized ELF symbol for each jump table entry.  That would be all we
need.

-- 
Josh