Re: [PATCH v2 5/5] crypto: x86/crc32c - Tweak jump table to validate objtool logic

[Ard Biesheuvel]

On Fri, 11 Oct 2024 at 18:05, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:
>
> On Fri, Oct 11, 2024 at 08:32:33AM +0200, Ard Biesheuvel wrote:
> > On Thu, 10 Oct 2024 at 22:34, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:
> > >
> > > On Thu, Oct 10, 2024 at 02:28:07PM +0200, Ard Biesheuvel wrote:
> > > > From: Ard Biesheuvel <ardb@xxxxxxxxxx>
> > > >
> > > > Tweak the jump table so
> > > > - the address is taken far way from its use
> > > > - its offset from the start of .rodata is != 0x0
> > > > - its type is STT_OBJECT and its size is set to the size of the actual
> > > >   table
> > > > - the indirect jump is annotated with a R_X86_64_NONE relocation
> > > >   pointing to the jump table
> > > >
> > > > Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx>
> > >
> > > This needs more "why", I assume the goals are to add the annotations +
> > > confuse objtool if it doesn't read them properly?
> > >
> >
> > As presented, this is just a vehicle to test the other changes in the
> > series. That is why I split it off from the previous one.
> >
> > Whether or not we want this code in the tree is up for debate, but I
> > guess it could be useful as a canary for objtool, given that most
> > configs now disable jump tables entirely.
>
> The annotations are definitely needed since that's the future of jump
> table handling.
>

Yeah, I'll split those off

> The rest of the changes aren't worth the effort IMO.  In general we
> don't compromise code quality to make objtool happy.
>
> And "unit test for deprecated jump table detection" is even less of a
> justification than would be something like "objtool can't otherwise
> follow the code".
>

No, quite the opposite - the changes will confuse objtool and so it
will only work correctly if the annotation is provided. That was the
point of this patch, but as I said, I never intended those changes to
be merged.