From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f73.google.com (mail-wr1-f73.google.com [209.85.221.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7D1B8221F26 for ; Thu, 18 Sep 2025 14:05:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758204332; cv=none; b=dAuvocuyynf1RGbAVAt0Mr6CVA6CQKcHlkt52Jw1ClgDsk7OSDPuqJ7nI9AR7dP2IUDZrgRyF4/UME3wxD3EEHwMwx5CcqZT8dwHa0XJ4P8PzvTJ36/zpN4u4mOCZeKiMJaVM3cegXM0DCs8N+anLcrQttt8DABkLTTM1B7YIq4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758204332; c=relaxed/simple; bh=jvD6EbLu6C+1usQPR8tlA6aJATIG8Vj8v16gqqXIbxQ=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=tDbMvZhfQ3JLD3WZKoZ2b91JGieV2nFu/gjCKx6faWFbX0f+ecSdJugZYm+3yC8sfradSScbCehs8LKQhfA57aXvOf1DFMwUs8SUFbRJawlIS8Kk37eMaVxITHCBLjb+S6majZysXKvXMeNaMjjHwrlxNI+tjvrDHroIaw0qZ5I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--elver.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=FrOGpPeh; arc=none smtp.client-ip=209.85.221.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--elver.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="FrOGpPeh" Received: by mail-wr1-f73.google.com with SMTP id ffacd0b85a97d-3ecdb10a612so613847f8f.2 for ; Thu, 18 Sep 2025 07:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1758204327; x=1758809127; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=wxDWT9Jhe5/U9R8flrhyT53CUNqFwMWNSIwpcA9ZCHg=; b=FrOGpPehSdf8EPA9O8jFjvH7oBHRCYP0bWtZ7uRVh7HtxvnbbI/kejSxCP2Rs7ET0g 3SbOf3vrvId+VKmpFldbbA1cv9Dv4+fuZroHQRaLWCDyzY2c9aWLntq8bd0YjOvAgM3z 3jqL2tzWIvKKP3YYyO1zWIFBeHeFXF7Ki2FfwkEne36UoMzoa8ZzB9r4P5PFZiDVMv8V 8odX3PURcN9fF2WVX3C/uPw4EVWasAhiw8QpFC8k+kskeoGwBf9qHM3qI0VQwbag1hV5 YWPzXK1dKW3mZc+Jqid1A2c+XOEduVxTAC47DpZUL0gIbOyLEXMtwl4e/rRe+31cODyl KBkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758204327; x=1758809127; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=wxDWT9Jhe5/U9R8flrhyT53CUNqFwMWNSIwpcA9ZCHg=; b=u+kcYnRf5zD4Y5Z2cqvatKD82ZKxThmd7nEnM9iizjYB9CsuLjG9zkVQV3tidxwj69 9ZMYkoud8ZmSL1NSu6g/j4tYsafhrr+sWghi33dYdC84j3Lu7vzsxjv9RlOZH+p6k7J1 mMuQLFmJMVcD1ZnnQHn708WhEoNqB+7fgFHKJw8sn6VcCG0dVRCTqrxVYEvi2hXL0XRz 9YnC4H7CeMOxdVf/3zhirRCSEugE+bcIwMG78VuYKlx3kRF0Ytrmvtwgo9PoxHU1hsqH oXapdaIQBk+Njd/Ldg8Z4qrsAFXE13+0HABMgTf1lcSKEFRygzrqlnHoO7V0leG3PEyB Hgjw== X-Forwarded-Encrypted: i=1; AJvYcCXo+K1cWbSW7mdoKfMdUfnMcjIeyWRCdnniltCvPbTA2CeBAZ4mmbbq3jAKR96FwSqPCMgIjAK4/wFeOkE=@vger.kernel.org X-Gm-Message-State: AOJu0YxJ8EYVKXyWVblX+3KYeqvATw6DO5yXVXeja5aFbaINMGMBIVKL uc0EuHG0F/vb/naIaLme2K5r8WPFYOHCxiLigdXAsDfAm37EFzy8+XAl/KKSqk4l7ISYyrST0M9 KWQ== X-Google-Smtp-Source: AGHT+IFy9SVTK9lkhhDe0k4MlUcY+fM8F7qwF5+lA1VEUPlhPe12zIpwiGbwOtlWJNddLkgwJGEEi7ziYQ== X-Received: from wrbcc12.prod.google.com ([2002:a5d:5c0c:0:b0:3ec:e0b7:7699]) (user=elver job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6000:2483:b0:3cd:ef83:a9a1 with SMTP id ffacd0b85a97d-3ecdf9c2666mr5663097f8f.20.1758204326802; Thu, 18 Sep 2025 07:05:26 -0700 (PDT) Date: Thu, 18 Sep 2025 15:59:11 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Mailer: git-send-email 2.51.0.384.g4c02a37b29-goog Message-ID: <20250918140451.1289454-1-elver@google.com> Subject: [PATCH v3 00/35] Compiler-Based Capability- and Locking-Analysis From: Marco Elver To: elver@google.com, Peter Zijlstra , Boqun Feng , Ingo Molnar , Will Deacon Cc: "David S. Miller" , Luc Van Oostenryck , "Paul E. McKenney" , Alexander Potapenko , Arnd Bergmann , Bart Van Assche , Bill Wendling , Christoph Hellwig , Dmitry Vyukov , Eric Dumazet , Frederic Weisbecker , Greg Kroah-Hartman , Herbert Xu , Ian Rogers , Jann Horn , Joel Fernandes , Jonathan Corbet , Josh Triplett , Justin Stitt , Kees Cook , Kentaro Takeda , Lukas Bulwahn , Mark Rutland , Mathieu Desnoyers , Miguel Ojeda , Nathan Chancellor , Neeraj Upadhyay , Nick Desaulniers , Steven Rostedt , Tetsuo Handa , Thomas Gleixner , Thomas Graf , Uladzislau Rezki , Waiman Long , kasan-dev@googlegroups.com, linux-crypto@vger.kernel.org, linux-doc@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-security-module@vger.kernel.org, linux-sparse@vger.kernel.org, llvm@lists.linux.dev, rcu@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Capability analysis is a C language extension, which enables statically checking that user-definable "capabilities" are acquired and released where required. An obvious application is lock-safety checking for the kernel's various synchronization primitives (each of which represents a "capability"), and checking that locking rules are not violated. Clang originally called the feature "Thread Safety Analysis" [1], with some terminology still using the thread-safety-analysis-only names. This was later changed and the feature became more flexible, gaining the ability to define custom "capabilities". Its foundations can be found in "capability systems" [2], used to specify the permissibility of operations to depend on some capability being held (or not held). Because the feature is not just able to express capabilities related to synchronization primitives, the naming chosen for the kernel departs from Clang's initial "Thread Safety" nomenclature and refers to the feature as "Capability Analysis" to avoid confusion. The implementation still makes references to the older terminology in some places, such as `-Wthread-safety` being the warning enabled option that also still appears in diagnostic messages. Enabling capability analysis can be seen as enabling a dialect of Linux C with a Capability System. Additional details can be found in the added kernel-doc documentation. An LWN article covered v2 of the series: https://lwn.net/Articles/1012990/ [1] https://clang.llvm.org/docs/ThreadSafetyAnalysis.html [2] https://www.cs.cornell.edu/talc/papers/capabilities.pdf === Development Approach === Prior art exists in the form of Sparse's context tracking. Locking annotations on functions exist, so the concept of analyzing locking rules is not foreign to the kernel's codebase. However, Clang's analysis is more complete vs. Sparse's, with the typical trade-offs in static analysis: improved completeness is sacrificed for more possible false positives or additional annotations required by the programmer. Numerous options exist to disable or opt out certain code from analysis. This series initially aimed to retain compatibility with Sparse, which can provide tree-wide analysis of a subset of the capability analysis introduced, but it was later decided to drop Sparse compatibility. For the most part, the new (and old) keywords used for annotations remain the same, and many of the pre-existing annotations remain valid. One big question is how to enable this feature, given we end up with a new dialect of C -- 2 approaches have been considered: A. Tree-wide all-or-nothing approach. This approach requires tree-wide changes, adding annotations or selective opt-outs. Making additional primitives capability-enabled increases churn, esp. where maintainers are unaware of the feature's existence and how to use it. Because we can't change the programming language (even if from one C dialect to another) of the kernel overnight, a different approach might cause less friction. B. A selective, incremental, and much less intrusive approach. Maintainers of subsystems opt in their modules or directories into "capability analysis" (via Makefile): CAPABILITY_ANALYSIS_foo.o := y # foo.o only CAPABILITY_ANALYSIS := y # all TUs Most (eventually all) synchronization primitives and more capabilities (including ones that could track "irq disabled", "preemption" disabled, etc.) could be supported. The approach taken by this series is B. This ensures that only subsystems where maintainers are willing to deal with any warnings are opted-in. Introducing the feature can be done incrementally, without large tree-wide changes and adding numerous opt-outs and annotations to the majority of code. Note: Bart Van Assche concurrently worked on enabling -Wthread-safety: https://lore.kernel.org/all/20250206175114.1974171-1-bvanassche@acm.org/ Bart's work has shown what it might take to go with approach A (tree-wide, restricted to 'mutex' usage). This has shown that the analysis finds real issues when applied to enough subsystems! We hope this serves as motivation to eventually enable the analysis in as many subsystems as possible, particularly subsystems that are not as easily tested by CI systems and test robots. === Initial Uses === With this initial series, the following synchronization primitives are supported: `raw_spinlock_t`, `spinlock_t`, `rwlock_t`, `mutex`, `seqlock_t`, `bit_spinlock`, RCU, SRCU (`srcu_struct`), `rw_semaphore`, `local_lock_t`, `ww_mutex`. To demonstrate use of the feature on real kernel code, the series also enables capability analysis for the following subsystems: * kernel/kcov * kernel/kcsan * kernel/sched/ * lib/rhashtable * lib/stackdepot * mm/kfence * security/tomoyo * crypto/ The initial benefits are static detection of violations of locking rules. As more capabilities are added, we would see more static checking beyond what regular C can provide, all while remaining easy (read quick) to use via the Clang compiler. Note: The kernel already provides dynamic analysis tools Lockdep and KCSAN for lock-safety checking and data-race detection respectively. Unlike those, Clang's capability analysis is a compile-time static analysis with no runtime impact. The static analysis complements existing dynamic analysis tools, as it may catch some issues before even getting into a running kernel, but is *not* a replacement for whole-kernel testing with the dynamic analysis tools enabled! === Appendix === A Clang version that supports `-Wthread-safety-pointer` and the new alias-analysis of capability pointers is required (from this version onwards): https://github.com/llvm/llvm-project/commit/b4c98fcbe1504841203e610c351a3227f36c92a4 [3] This series is also available at this Git tree: https://git.kernel.org/pub/scm/linux/kernel/git/melver/linux.git/log/?h=cap-analysis/dev === Changelog === v3: - Bump min. Clang version to 22+ (unreleased), which now supports: * re-entrancy via __attribute__((reentrant_capability)); * basic form of capability alias analysis [3] - which is the biggest improvement since v2. This was the result of conclusions from this discussion: https://lore.kernel.org/all/CANpmjNPquO=W1JAh1FNQb8pMQjgeZAKCPQUAd7qUg=5pjJ6x=Q@mail.gmail.com/ - Rename __asserts_cap/__assert_cap to __assumes_cap/__assume_cap. - Switch to DECLARE_LOCK_GUARD_1_ATTRS(). - Add __acquire_ret and __acquire_shared_ret helper macros - can be used to define function-like macros that return objects which contains a held capabilities. Works now because of capability alias analysis. - Add capability_unsafe_alias() helper, where the analysis rightfully points out we're doing strange things with aliases but we don't care. - Support multi-argument attributes. - Enable for kernel/sched/{core,fair}.c, kernel/kcsan. - Drop drivers/tty changes (revisit later). v2: https://lore.kernel.org/all/20250304092417.2873893-1-elver@google.com/ - Remove Sparse context tracking support - after the introduction of Clang support, so that backports can skip removal of Sparse support. - Remove __cond_lock() function-like helper. - ww_mutex support. - -Wthread-safety-addressof was reworked and committed in upstream Clang as -Wthread-safety-pointer. - Make __cond_acquires() and __cond_acquires_shared() take abstract value, since compiler only cares about zero and non-zero. - Rename __var_guarded_by to simply __guarded_by. Initially the idea was to be explicit about if the variable itself or the pointed-to data is guarded, but in the long-term, making this shorter might be better. - Likewise rename __ref_guarded_by to __pt_guarded_by. - Introduce common header warning suppressions - this is a better solution than guarding header inclusions with disable_ + enable_capability_analysis(). Header suppressions are disabled when selecting CONFIG_WARN_CAPABILITY_ANALYSIS_ALL=y. This bumps the minimum Clang version required to 20+. - Make the data_race() macro imply disabled capability analysis. Writing capability_unsafe(data_race(..)) is unnecessarily verbose and data_race() on its own already indicates something subtly unsafe is happening. This change was made after analysis of a finding in security/tomoyo. - Enable analysis in the following subsystems as additional examples of larger subsystem. Where it was obvious, the __guarded_by attribute was added to lock-guarded variables to improve coverage. * drivers/tty * security/tomoyo * crypto/ RFC v1: https://lore.kernel.org/lkml/20250206181711.1902989-1-elver@google.com Marco Elver (35): compiler_types: Move lock checking attributes to compiler-capability-analysis.h compiler-capability-analysis: Add infrastructure for Clang's capability analysis compiler-capability-analysis: Add test stub Documentation: Add documentation for Compiler-Based Capability Analysis checkpatch: Warn about capability_unsafe() without comment cleanup: Basic compatibility with capability analysis lockdep: Annotate lockdep assertions for capability analysis locking/rwlock, spinlock: Support Clang's capability analysis compiler-capability-analysis: Change __cond_acquires to take return value locking/mutex: Support Clang's capability analysis locking/seqlock: Support Clang's capability analysis bit_spinlock: Include missing bit_spinlock: Support Clang's capability analysis rcu: Support Clang's capability analysis srcu: Support Clang's capability analysis kref: Add capability-analysis annotations locking/rwsem: Support Clang's capability analysis locking/local_lock: Include missing headers locking/local_lock: Support Clang's capability analysis locking/ww_mutex: Support Clang's capability analysis debugfs: Make debugfs_cancellation a capability struct compiler-capability-analysis: Remove Sparse support compiler-capability-analysis: Remove __cond_lock() function-like helper compiler-capability-analysis: Introduce header suppressions compiler: Let data_race() imply disabled capability analysis MAINTAINERS: Add entry for Capability Analysis kfence: Enable capability analysis kcov: Enable capability analysis kcsan: Enable capability analysis stackdepot: Enable capability analysis rhashtable: Enable capability analysis printk: Move locking annotation to printk.c security/tomoyo: Enable capability analysis crypto: Enable capability analysis sched: Enable capability analysis for core.c and fair.c .../dev-tools/capability-analysis.rst | 148 +++++ Documentation/dev-tools/index.rst | 1 + Documentation/dev-tools/sparse.rst | 19 - Documentation/mm/process_addrs.rst | 6 +- MAINTAINERS | 11 + Makefile | 1 + crypto/Makefile | 2 + crypto/acompress.c | 6 +- crypto/algapi.c | 2 + crypto/api.c | 1 + crypto/crypto_engine.c | 2 +- crypto/drbg.c | 5 + crypto/internal.h | 2 +- crypto/proc.c | 3 + crypto/scompress.c | 24 +- .../net/wireless/intel/iwlwifi/iwl-trans.c | 4 +- .../net/wireless/intel/iwlwifi/iwl-trans.h | 6 +- .../intel/iwlwifi/pcie/gen1_2/internal.h | 5 +- .../intel/iwlwifi/pcie/gen1_2/trans.c | 4 +- fs/dlm/lock.c | 2 +- include/crypto/internal/acompress.h | 7 +- include/crypto/internal/engine.h | 2 +- include/linux/bit_spinlock.h | 24 +- include/linux/cleanup.h | 17 + include/linux/compiler-capability-analysis.h | 423 +++++++++++++ include/linux/compiler.h | 2 + include/linux/compiler_types.h | 18 +- include/linux/console.h | 4 +- include/linux/debugfs.h | 12 +- include/linux/kref.h | 2 + include/linux/list_bl.h | 2 + include/linux/local_lock.h | 45 +- include/linux/local_lock_internal.h | 73 ++- include/linux/lockdep.h | 12 +- include/linux/mm.h | 33 +- include/linux/mutex.h | 35 +- include/linux/mutex_types.h | 4 +- include/linux/rcupdate.h | 86 +-- include/linux/refcount.h | 6 +- include/linux/rhashtable.h | 14 +- include/linux/rwlock.h | 22 +- include/linux/rwlock_api_smp.h | 43 +- include/linux/rwlock_rt.h | 44 +- include/linux/rwlock_types.h | 10 +- include/linux/rwsem.h | 66 +- include/linux/sched.h | 6 +- include/linux/sched/signal.h | 16 +- include/linux/sched/task.h | 5 +- include/linux/sched/wake_q.h | 3 + include/linux/seqlock.h | 24 + include/linux/seqlock_types.h | 5 +- include/linux/spinlock.h | 89 ++- include/linux/spinlock_api_smp.h | 34 +- include/linux/spinlock_api_up.h | 112 +++- include/linux/spinlock_rt.h | 37 +- include/linux/spinlock_types.h | 10 +- include/linux/spinlock_types_raw.h | 5 +- include/linux/srcu.h | 60 +- include/linux/srcutiny.h | 4 + include/linux/srcutree.h | 6 +- include/linux/ww_mutex.h | 22 +- kernel/Makefile | 2 + kernel/kcov.c | 36 +- kernel/kcsan/Makefile | 2 + kernel/kcsan/report.c | 11 +- kernel/printk/printk.c | 2 + kernel/sched/Makefile | 3 + kernel/sched/core.c | 89 ++- kernel/sched/fair.c | 9 +- kernel/sched/sched.h | 110 +++- kernel/signal.c | 4 +- kernel/time/posix-timers.c | 13 +- lib/Kconfig.debug | 45 ++ lib/Makefile | 6 + lib/dec_and_lock.c | 8 +- lib/rhashtable.c | 5 +- lib/stackdepot.c | 20 +- lib/test_capability-analysis.c | 596 ++++++++++++++++++ mm/kfence/Makefile | 2 + mm/kfence/core.c | 20 +- mm/kfence/kfence.h | 14 +- mm/kfence/report.c | 4 +- mm/memory.c | 4 +- mm/pgtable-generic.c | 19 +- net/ipv4/tcp_sigpool.c | 2 +- scripts/Makefile.capability-analysis | 11 + scripts/Makefile.lib | 10 + scripts/capability-analysis-suppression.txt | 33 + scripts/checkpatch.pl | 8 + security/tomoyo/Makefile | 2 + security/tomoyo/common.c | 52 +- security/tomoyo/common.h | 77 +-- security/tomoyo/domain.c | 1 + security/tomoyo/environ.c | 1 + security/tomoyo/file.c | 5 + security/tomoyo/gc.c | 28 +- security/tomoyo/mount.c | 2 + security/tomoyo/network.c | 3 + tools/include/linux/compiler_types.h | 2 - 99 files changed, 2370 insertions(+), 589 deletions(-) create mode 100644 Documentation/dev-tools/capability-analysis.rst create mode 100644 include/linux/compiler-capability-analysis.h create mode 100644 lib/test_capability-analysis.c create mode 100644 scripts/Makefile.capability-analysis create mode 100644 scripts/capability-analysis-suppression.txt -- 2.51.0.384.g4c02a37b29-goog