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-prev] [day] [month] [year] [list]
Message-ID: <CAG_fn=WTUXdGH+1oKx8LSwDXrFFMz3Fy1XZUAcbw3TmFmpopFg@mail.gmail.com>
Date: Wed, 16 Oct 2024 18:34:05 +0200
From: Alexander Potapenko <glider@...gle.com>
To: Sabyrzhan Tasbolatov <snovitoll@...il.com>
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, 
	dave.hansen@...ux.intel.com, x86@...nel.org, akpm@...ux-foundation.org, 
	linux-kernel@...r.kernel.org, kasan-dev@...glegroups.com
Subject: Re: [PATCH] x86/traps: move kmsan check after instrumentation_begin

On Wed, Oct 16, 2024 at 5:23 PM Sabyrzhan Tasbolatov
<snovitoll@...il.com> wrote:
>
> During x86_64 kernel build with CONFIG_KMSAN, the objtool warns
> following:
>
>   AR      built-in.a
>   AR      vmlinux.a
>   LD      vmlinux.o
> vmlinux.o: warning: objtool: handle_bug+0x4: call to
>     kmsan_unpoison_entry_regs() leaves .noinstr.text section
>   OBJCOPY modules.builtin.modinfo
>   GEN     modules.builtin
>   MODPOST Module.symvers
>   CC      .vmlinux.export.o
>
> Moving kmsan_unpoison_entry_regs() _after_ instrumentation_begin() fixes
> the warning.

Thanks for taking care of this!

> There is decode_bug(regs->ip, &imm) is left before KMSAN unpoisoining,

(side note: decode_bug itself is inlined into handle_bug(), so it is
not instrumented, and no bugs are reported in it)

> but it has the return condition and if we include it after
> instrumentation_begin() it results the warning
> "return with instrumentation enabled", hence, I'm concerned that regs
> will not be KMSAN unpoisoned if `ud_type == BUG_NONE` is true.

So far the only caller of handle_bug() passes regs to
irqentry_enter(), which unpoisons them anyway.
I think this is fine, adding an extra instrumentation region around
kmsan_unpoison_entry_regs() in handle_bug() would be an overkill.

>
> Fixes: ba54d194f8da ("x86/traps: avoid KMSAN bugs originating from handle_bug()")
> Signed-off-by: Sabyrzhan Tasbolatov <snovitoll@...il.com>
Reviewed-by: Alexander Potapenko <glider@...gle.com>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ