linux-kernel - Re: [PATCH RFC 08/24] lockdep: Annotate lockdep assertions for capability analysis

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: <f5eda818-6119-4b8f-992f-33bc9c184a64@acm.org>
Date: Mon, 10 Feb 2025 10:53:44 -0800
From: Bart Van Assche <bvanassche@....org>
To: Marco Elver <elver@...gle.com>
Cc: "Paul E. McKenney" <paulmck@...nel.org>,
 Alexander Potapenko <glider@...gle.com>, Bill Wendling <morbo@...gle.com>,
 Boqun Feng <boqun.feng@...il.com>, Dmitry Vyukov <dvyukov@...gle.com>,
 Frederic Weisbecker <frederic@...nel.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Ingo Molnar <mingo@...nel.org>, Jann Horn <jannh@...gle.com>,
 Joel Fernandes <joel@...lfernandes.org>, Jonathan Corbet <corbet@....net>,
 Josh Triplett <josh@...htriplett.org>, Justin Stitt
 <justinstitt@...gle.com>, Kees Cook <kees@...nel.org>,
 Mark Rutland <mark.rutland@....com>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Miguel Ojeda <ojeda@...nel.org>, Nathan Chancellor <nathan@...nel.org>,
 Neeraj Upadhyay <neeraj.upadhyay@...nel.org>,
 Nick Desaulniers <ndesaulniers@...gle.com>,
 Peter Zijlstra <peterz@...radead.org>, Steven Rostedt <rostedt@...dmis.org>,
 Thomas Gleixner <tglx@...utronix.de>, Uladzislau Rezki <urezki@...il.com>,
 Waiman Long <longman@...hat.com>, Will Deacon <will@...nel.org>,
 kasan-dev@...glegroups.com, linux-kernel@...r.kernel.org,
 llvm@...ts.linux.dev, rcu@...r.kernel.org, linux-crypto@...r.kernel.org
Subject: Re: [PATCH RFC 08/24] lockdep: Annotate lockdep assertions for
 capability analysis

On 2/10/25 10:23 AM, Marco Elver wrote:
> If you try to write code where you access a guarded_by variable, but
> the lock is held not in all paths we can write it like this:
> 
> struct bar {
>    spinlock_t lock;
>    bool a; // true if lock held
>    int counter __var_guarded_by(&lock);
> };
> void foo(struct bar *d)
> {
>     ...
>     if (d->a) {
>       lockdep_assert_held(&d->lock);
>       d->counter++;
>     } else {
>       // lock not held!
>     }
>    ...
> }
> 
> Without lockdep_assert_held() you get false positives, and there's no
> other good way to express this if you do not want to always call foo()
> with the lock held.
> 
> It essentially forces addition of lockdep checks where the static
> analysis can't quite prove what you've done is right. This is
> desirable over adding no-analysis attributes and not checking anything
> at all.

In the above I see that two different options have been mentioned for
code that includes conditional lockdep_assert_held() calls:
- Either include __assert_cap() in the lockdep_assert_held() definition.
- Or annotate the entire function with __no_thread_safety_analysis.

I think there is a third possibility: add an explicit __assert_cap() 
call under the lockdep_assert_held() call. With this approach the
thread-safety analysis remains enabled for the annotated function and
the compiler will complain if neither __must_hold() nor __assert_cap()
has been used.

I prefer the third option since conditional lockdep_assert_held() calls
are relatively rare in the kernel. If I counted correctly, there are
about 40 times more unconditional lockdep_assert_held() calls than
conditional lockdep_assert_held() calls.

Bart.