linux-kernel - Re: KMSAN broken with lockdep again?

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 18 Nov 2022 19:19:33 +0100
From:   Alexander Potapenko <glider@...gle.com>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     Marco Elver <elver@...gle.com>, Dmitry Vyukov <dvyukov@...gle.com>,
        kasan-dev@...glegroups.com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: KMSAN broken with lockdep again?

On Fri, Nov 18, 2022 at 2:39 PM Alexander Potapenko <glider@...gle.com> wrote:
>
> > > As far as I can tell, removing `KMSAN_SANITIZE_lockdep.o := n` does
> > > not actually break anything now (although the kernel becomes quite
> > > slow with both lockdep and KMSAN). Let me experiment a bit and send a
> > > patch.
>
> Hm, no, lockdep isn't particularly happy with the nested
> lockdep->KMSAN->lockdep calls:
>
> ------------[ cut here ]------------
> DEBUG_LOCKS_WARN_ON(lockdep_hardirqs_enabled())
> WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:5508 check_flags+0x63/0x180
> ...
>  <TASK>
>  lock_acquire+0x196/0x640 kernel/locking/lockdep.c:5665
>  __raw_spin_lock_irqsave ./include/linux/spinlock_api_smp.h:110
>  _raw_spin_lock_irqsave+0xb3/0x110 kernel/locking/spinlock.c:162
>  __stack_depot_save+0x1b1/0x4b0 lib/stackdepot.c:479
>  stack_depot_save+0x13/0x20 lib/stackdepot.c:533
>  __msan_poison_alloca+0x100/0x1a0 mm/kmsan/instrumentation.c:263
>  native_save_fl ./include/linux/spinlock_api_smp.h:?
>  arch_local_save_flags ./arch/x86/include/asm/irqflags.h:70
>  arch_irqs_disabled ./arch/x86/include/asm/irqflags.h:130
>  __raw_spin_unlock_irqrestore ./include/linux/spinlock_api_smp.h:151
>  _raw_spin_unlock_irqrestore+0x60/0x100 kernel/locking/spinlock.c:194
>  tty_register_ldisc+0xcb/0x120 drivers/tty/tty_ldisc.c:68
>  n_tty_init+0x1f/0x21 drivers/tty/n_tty.c:2521
>  console_init+0x1f/0x7ee kernel/printk/printk.c:3287
>  start_kernel+0x577/0xaff init/main.c:1073
>  x86_64_start_reservations+0x2a/0x2c arch/x86/kernel/head64.c:556
>  x86_64_start_kernel+0x114/0x119 arch/x86/kernel/head64.c:537
>  secondary_startup_64_no_verify+0xcf/0xdb arch/x86/kernel/head_64.S:358
>  </TASK>
> ---[ end trace 0000000000000000 ]---

In fact, this message is printed in both cases: with and without KMSAN
instrumenting kernel/locking/lockdep.c
I wonder if this is a sign of a real problem in KMSAN, or just an
unavoidable consequence of instrumented code calling lockdep when
taking the stackdepot lock...

> > > If this won't work out, we'll need an explicit call to
> > > kmsan_unpoison_memory() somewhere in lockdep_init_map_type() to
> > > suppress these reports.
>
> I'll go for this option.
>
> > Thanks.
> >
> > I tried just disabling CONFIG_PROVE_LOCKING, but now KMSAN warnings are being
> > spammed from check_stack_object() in mm/usercopy.c.
> >
> > Commenting out the call to arch_within_stack_frames() makes it go away.
>
> Yeah, arch_within_stack_frames() performs stack frame walking, which
> confuses KMSAN.
> We'll need to apply __no_kmsan_checks to it, like we did for other
> stack unwinding functions.

Sent the patch.