Re: [PATCH 20/22] objtool: Fix seg fault on bad switch table entry

[Nick Desaulniers]

On Sun, Jul 14, 2019 at 5:37 PM Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:
>
> In one rare case, Clang generated the following code:
>
>  5ca:       83 e0 21                and    $0x21,%eax
>  5cd:       b9 04 00 00 00          mov    $0x4,%ecx
>  5d2:       ff 24 c5 00 00 00 00    jmpq   *0x0(,%rax,8)
>                     5d5: R_X86_64_32S       .rodata+0x38
>
> which uses the corresponding jump table relocations:
>
>   000000000038  000200000001 R_X86_64_64       0000000000000000 .text + 834
>   000000000040  000200000001 R_X86_64_64       0000000000000000 .text + 5d9
>   000000000048  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   000000000050  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   000000000058  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   000000000060  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   000000000068  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   000000000070  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   000000000078  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   000000000080  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   000000000088  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   000000000090  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   000000000098  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   0000000000a0  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   0000000000a8  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   0000000000b0  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   0000000000b8  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   0000000000c0  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   0000000000c8  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   0000000000d0  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   0000000000d8  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   0000000000e0  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   0000000000e8  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   0000000000f0  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   0000000000f8  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   000000000100  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   000000000108  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   000000000110  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   000000000118  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   000000000120  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   000000000128  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   000000000130  000200000001 R_X86_64_64       0000000000000000 .text + b96
>   000000000138  000200000001 R_X86_64_64       0000000000000000 .text + 82f
>   000000000140  000200000001 R_X86_64_64       0000000000000000 .text + 828
>
> Since %eax was masked with 0x21, only the first two and the last two
> entries are possible.
>
> Objtool doesn't actually emulate all the code, so it isn't smart enough
> to know that all the middle entries aren't reachable.  They point to the
> NOP padding area after the end of the function, so objtool seg faulted
> when it tried to dereference a NULL insn->func.
>
> After this fix, objtool still gives an "unreachable" error because it
> stops reading the jump table when it encounters the bad addresses:
>
>   /home/jpoimboe/objtool-tests/adm1275.o: warning: objtool: adm1275_probe()+0x828: unreachable instruction
>
> While the above code is technically correct, it's very wasteful of
> memory -- it uses 34 jump table entries when only 4 are needed.  It's
> also not possible for objtool to validate this type of switch table
> because the unused entries point outside the function and objtool has no
> way of determining if that's intentional.  Hopefully the Clang folks can
> fix it.

So this came from
drivers/hwmon/pmbus/adm1275.c ?
Any special configuration?
-- 
Thanks,
~Nick Desaulniers