Re: [PATCH v5 01/15] objtool: Add CONFIG_CFI_CLANG support

From: Kees Cook
Date: Wed Oct 13 2021 - 14:59:41 EST


On Wed, Oct 13, 2021 at 11:16:44AM -0700, Sami Tolvanen wrote:
> The upcoming CONFIG_CFI_CLANG support uses -fsanitize=cfi, the
> non-canonical version of which hijacks function entry by changing
> function relocation references to point to an intermediary jump table.
>
> For example:
>
> Relocation section '.rela.discard.func_stack_frame_non_standard' at offset 0x37e018 contains 6 entries:
> Offset Info Type Symbol's Value Symbol's Name + Addend
> 0000000000000000 0002944700000002 R_X86_64_PC32 00000000000023f0 do_suspend_lowlevel + 0
> 0000000000000008 0003c11900000001 R_X86_64_64 0000000000000008 xen_cpuid$e69bc59f4fade3b6f2b579b3934137df.cfi_jt + 0
> 0000000000000010 0003980900000001 R_X86_64_64 0000000000000060 machine_real_restart.cfi_jt + 0
> 0000000000000018 0003962b00000001 R_X86_64_64 0000000000000e18 kretprobe_trampoline.cfi_jt + 0
> 0000000000000020 000028f300000001 R_X86_64_64 0000000000000000 .rodata + 12
> 0000000000000028 000349f400000001 R_X86_64_64 0000000000000018 __crash_kexec.cfi_jt + 0
>
> 0000000000000060 <machine_real_restart.cfi_jt>:
> 60: e9 00 00 00 00 jmpq 65 <machine_real_restart.cfi_jt+0x5>
> 61: R_X86_64_PLT32 machine_real_restart-0x4
> 65: cc int3
> 66: cc int3
> 67: cc int3
>
> This breaks objtool vmlinux validation in many ways, including static
> call site detection and the STACK_FRAME_NON_STANDARD() macro.
>
> Fix it by converting those relocations' symbol references back to their
> original non-jump-table versions. Note this doesn't change the actual
> relocations in the object itself, it just changes objtool's view of
> them. This change is based on Josh's initial patch:
>
> https://lore.kernel.org/r/d743f4b36e120c06506567a9f87a062ae03da47f.1611263462.git.jpoimboe@xxxxxxxxxx/
>
> Reported-by: Sedat Dilek <sedat.dilek@xxxxxxxxx>
> Suggested-by: Josh Poimboeuf <jpoimboe@xxxxxxxxxx>
> Signed-off-by: Sami Tolvanen <samitolvanen@xxxxxxxxxx>

This looks really clean. Thanks!

Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx>

--
Kees Cook