lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXHBccOwtLWuT9P1ozpVm7bTcfPfjfXTVzJnCzsCYm1RfQ@mail.gmail.com>
Date: Wed, 9 Oct 2024 17:18:36 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Josh Poimboeuf <jpoimboe@...nel.org>, Kees Cook <kees@...nel.org>
Cc: linux-kernel@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>, 
	linux-hardening@...r.kernel.org
Subject: Re: [PATCH] objtool: Deal with relative jump tables correctly

On Tue, 8 Oct 2024 at 19:42, Josh Poimboeuf <jpoimboe@...nel.org> 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.

> Otherwise the patch looks ok.
>

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? 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.







ffffffff83203a40 <fdt_pmu_probe_pmu_dev.isra.0>:
3a40:  nopl   0x0(%rax,%rax,1)
3a45:  push   %r15
3a47:  push   %r14
3a49:  lea    0x597a98(%rip),%r14  <--- load of jump table address
3a50:  push   %r13
3a52:  mov    %rsi,%r13
3a55:  push   %r12
3a57:  lea    0x530(%r13),%r15
3a5e:  push   %rbp
3a5f:  push   %rbx
3a60:  mov    %rdi,%rbx
3a63:  sub    $0x10,%rsp
3a67:  mov    0x40(%rsp),%rdi
3a6c:  call   ffffffff81745c00 <__tsan_func_entry>
3a71:  call   ffffffff814ae4c0 <__sanitizer_cov_trace_pc>
3a76:  mov    %r15,%rdi
3a79:  call   ffffffff81747a00 <__tsan_read8>
3a7e:  mov    0x530(%r13),%rdi
3a85:  xor    %esi,%esi
3a87:  call   ffffffff82a25800 <of_get_next_child>
3a8c:  mov    %rax,%r12
3a8f:  call   ffffffff814ae4c0 <__sanitizer_cov_trace_pc>
3a94:  test   %r12,%r12
3a97:  je     ffffffff83203d55 <fdt_pmu_probe_pmu_dev.isra.0+0x315>
3a9d:  call   ffffffff814ae4c0 <__sanitizer_cov_trace_pc>
3aa2:  mov    %r12,%rdi
3aa5:  call   ffffffff82a26e00 <of_device_is_available>
3aaa:  xor    %edi,%edi
3aac:  mov    %eax,%ebp
3aae:  mov    %eax,%esi
3ab0:  call   ffffffff814ae740 <__sanitizer_cov_trace_const_cmp1>
3ab5:  test   %bpl,%bpl
3ab8:  je     ffffffff83203d31 <fdt_pmu_probe_pmu_dev.isra.0+0x2f1>
3abe:  call   ffffffff814ae4c0 <__sanitizer_cov_trace_pc>
3ac3:  lea    0x68e996(%rip),%rsi        # ffffffff83892460 <.LC29>
3aca:  mov    %r12,%rdi
3acd:  call   ffffffff82a26180 <of_device_is_compatible>
3ad2:  xor    %edi,%edi
3ad4:  mov    %eax,%ebp
3ad6:  mov    %eax,%esi
3ad8:  call   ffffffff814ae7c0 <__sanitizer_cov_trace_const_cmp4>
3add:  test   %ebp,%ebp
3adf:  je     ffffffff83203b03 <fdt_pmu_probe_pmu_dev.isra.0+0xc3>
3ae1:  call   ffffffff814ae4c0 <__sanitizer_cov_trace_pc>
3ae6:  mov    %rbx,%rdi
3ae9:  call   ffffffff81747a00 <__tsan_read8>
3aee:  mov    (%rbx),%rdi
3af1:  xor    %edx,%edx
3af3:  mov    %r12,%rsi
3af6:  call   ffffffff83203800 <fdt_get_pmu_hw_inf.isra.0>
3afb:  mov    %rax,%rbp
3afe:  jmp    ffffffff83203bd7 <fdt_pmu_probe_pmu_dev.isra.0+0x197>
3b03:  call   ffffffff814ae4c0 <__sanitizer_cov_trace_pc>
3b08:  lea    0x68e963(%rip),%rsi        # ffffffff83892472 <.LC30>
3b0f:  mov    %r12,%rdi
3b12:  call   ffffffff82a26180 <of_device_is_compatible>
3b17:  xor    %edi,%edi
3b19:  mov    %eax,%ebp
3b1b:  mov    %eax,%esi
3b1d:  call   ffffffff814ae7c0 <__sanitizer_cov_trace_const_cmp4>
3b22:  test   %ebp,%ebp
3b24:  je     ffffffff83203b4b <fdt_pmu_probe_pmu_dev.isra.0+0x10b>
3b26:  call   ffffffff814ae4c0 <__sanitizer_cov_trace_pc>
3b2b:  mov    %rbx,%rdi
3b2e:  call   ffffffff81747a00 <__tsan_read8>
3b33:  mov    (%rbx),%rdi
3b36:  mov    $0x1,%edx
3b3b:  mov    %r12,%rsi
3b3e:  call   ffffffff83203800 <fdt_get_pmu_hw_inf.isra.0>
3b43:  mov    %rax,%rbp
3b46:  jmp    ffffffff83203bd7 <fdt_pmu_probe_pmu_dev.isra.0+0x197>
3b4b:  call   ffffffff814ae4c0 <__sanitizer_cov_trace_pc>
3b50:  lea    0x68e92d(%rip),%rsi        # ffffffff83892484 <.LC31>
3b57:  mov    %r12,%rdi
3b5a:  call   ffffffff82a26180 <of_device_is_compatible>
3b5f:  xor    %edi,%edi
3b61:  mov    %eax,%ebp
3b63:  mov    %eax,%esi
3b65:  call   ffffffff814ae7c0 <__sanitizer_cov_trace_const_cmp4>
3b6a:  test   %ebp,%ebp
3b6c:  je     ffffffff83203b90 <fdt_pmu_probe_pmu_dev.isra.0+0x150>
3b6e:  call   ffffffff814ae4c0 <__sanitizer_cov_trace_pc>
3b73:  mov    %rbx,%rdi
3b76:  call   ffffffff81747a00 <__tsan_read8>
3b7b:  mov    (%rbx),%rdi
3b7e:  mov    $0x3,%edx
3b83:  mov    %r12,%rsi
3b86:  call   ffffffff83203800 <fdt_get_pmu_hw_inf.isra.0>
3b8b:  mov    %rax,%rbp
3b8e:  jmp    ffffffff83203bd7 <fdt_pmu_probe_pmu_dev.isra.0+0x197>
3b90:  call   ffffffff814ae4c0 <__sanitizer_cov_trace_pc>
3b95:  lea    0x68e8fa(%rip),%rsi        # ffffffff83892496 <.LC32>
3b9c:  mov    %r12,%rdi
3b9f:  call   ffffffff82a26180 <of_device_is_compatible>
3ba4:  xor    %edi,%edi
3ba6:  mov    %eax,%ebp
3ba8:  mov    %eax,%esi
3baa:  call   ffffffff814ae7c0 <__sanitizer_cov_trace_const_cmp4>
3baf:  test   %ebp,%ebp
3bb1:  je     ffffffff83203d31 <fdt_pmu_probe_pmu_dev.isra.0+0x2f1>
3bb7:  call   ffffffff814ae4c0 <__sanitizer_cov_trace_pc>
3bbc:  mov    %rbx,%rdi
3bbf:  call   ffffffff81747a00 <__tsan_read8>
3bc4:  mov    (%rbx),%rdi
3bc7:  mov    $0x4,%edx
3bcc:  mov    %r12,%rsi
3bcf:  call   ffffffff83203800 <fdt_get_pmu_hw_inf.isra.0>
3bd4:  mov    %rax,%rbp
3bd7:  call   ffffffff814ae4c0 <__sanitizer_cov_trace_pc>
3bdc:  test   %rbp,%rbp
3bdf:  je     ffffffff83203d31 <fdt_pmu_probe_pmu_dev.isra.0+0x2f1>
3be5:  call   ffffffff814ae4c0 <__sanitizer_cov_trace_pc>
3bea:  mov    %rbp,%rsi
3bed:  mov    %rbx,%rdi
3bf0:  call   ffffffff82a864c0 <xgene_pmu_dev_add>
3bf5:  xor    %edi,%edi
3bf7:  mov    %eax,%esi
3bf9:  mov    %eax,(%rsp)
3bfc:  call   ffffffff814ae7c0 <__sanitizer_cov_trace_const_cmp4>
3c01:  mov    (%rsp),%eax
3c04:  test   %eax,%eax
3c06:  je     ffffffff83203c25 <fdt_pmu_probe_pmu_dev.isra.0+0x1e5>
3c08:  call   ffffffff814ae4c0 <__sanitizer_cov_trace_pc>
3c0d:  mov    %rbx,%rdi
3c10:  call   ffffffff81747a00 <__tsan_read8>
3c15:  mov    (%rbx),%rdi
3c18:  mov    %rbp,%rsi
3c1b:  call   ffffffff8283d3c0 <devm_kfree>
3c20:  jmp    ffffffff83203d31 <fdt_pmu_probe_pmu_dev.isra.0+0x2f1>
3c25:  call   ffffffff814ae4c0 <__sanitizer_cov_trace_pc>
3c2a:  lea    0x20(%rbp),%rdi
3c2e:  call   ffffffff817474c0 <__tsan_read4>
3c33:  mov    0x20(%rbp),%eax
3c36:  lea    0x597923(%rip),%rsi
3c3d:  mov    %rax,%rdi
3c40:  mov    %eax,0xc(%rsp)
3c44:  mov    %rax,(%rsp)
3c48:  call   ffffffff814ae840 <__sanitizer_cov_trace_switch>
3c4d:  mov    0xc(%rsp),%edx
3c51:  cmp    $0x4,%edx
3c54:  ja     ffffffff83203d31 <fdt_pmu_probe_pmu_dev.isra.0+0x2f1>
3c5a:  mov    (%rsp),%rax
3c5e:  add    $0x8,%rbp
3c62:  movslq (%r14,%rax,4),%rax
3c66:  add    %r14,%rax
3c69:  jmp    *%rax
3c6b:  int3

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ