* [PATCH tip/locking/core 6/6] compiler-context-analysis: Remove __assume_ctx_lock from initializers
From: Marco Elver @ 2026-01-19 9:05 UTC (permalink / raw)
To: elver, Peter Zijlstra, Ingo Molnar
Cc: Thomas Gleixner, Will Deacon, Boqun Feng, Waiman Long,
Christoph Hellwig, Steven Rostedt, Bart Van Assche, kasan-dev,
llvm, linux-crypto, linux-doc, linux-security-module,
linux-kernel
In-Reply-To: <20260119094029.1344361-1-elver@google.com>
Remove __assume_ctx_lock() from lock initializers.
Implicitly asserting an active context during initialization caused
false-positive double-lock errors when acquiring a lock immediately after its
initialization. Moving forward, guarded member initialization must either:
1. Use guard(type_init)(&lock) or scoped_guard(type_init, ...).
2. Use context_unsafe() for simple initialization.
Link: https://lore.kernel.org/all/57062131-e79e-42c2-aa0b-8f931cb8cac2@acm.org/
Reported-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Marco Elver <elver@google.com>
---
include/linux/local_lock_internal.h | 3 ---
include/linux/mutex.h | 1 -
include/linux/rwlock.h | 3 +--
include/linux/rwlock_rt.h | 1 -
include/linux/rwsem.h | 2 --
include/linux/seqlock.h | 1 -
include/linux/spinlock.h | 5 +----
include/linux/spinlock_rt.h | 1 -
include/linux/ww_mutex.h | 1 -
lib/test_context-analysis.c | 6 ------
10 files changed, 2 insertions(+), 22 deletions(-)
diff --git a/include/linux/local_lock_internal.h b/include/linux/local_lock_internal.h
index 4521c40895f8..ebfcdf517224 100644
--- a/include/linux/local_lock_internal.h
+++ b/include/linux/local_lock_internal.h
@@ -87,13 +87,11 @@ do { \
0, LD_WAIT_CONFIG, LD_WAIT_INV, \
LD_LOCK_PERCPU); \
local_lock_debug_init(lock); \
- __assume_ctx_lock(lock); \
} while (0)
#define __local_trylock_init(lock) \
do { \
__local_lock_init((local_lock_t *)lock); \
- __assume_ctx_lock(lock); \
} while (0)
#define __spinlock_nested_bh_init(lock) \
@@ -105,7 +103,6 @@ do { \
0, LD_WAIT_CONFIG, LD_WAIT_INV, \
LD_LOCK_NORMAL); \
local_lock_debug_init(lock); \
- __assume_ctx_lock(lock); \
} while (0)
#define __local_lock_acquire(lock) \
diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index 6b12009351d2..ecaa0440f6ec 100644
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h
@@ -62,7 +62,6 @@ do { \
static struct lock_class_key __key; \
\
__mutex_init((mutex), #mutex, &__key); \
- __assume_ctx_lock(mutex); \
} while (0)
/**
diff --git a/include/linux/rwlock.h b/include/linux/rwlock.h
index 65a5b55e1bcd..3390d21c95dd 100644
--- a/include/linux/rwlock.h
+++ b/include/linux/rwlock.h
@@ -22,11 +22,10 @@ do { \
static struct lock_class_key __key; \
\
__rwlock_init((lock), #lock, &__key); \
- __assume_ctx_lock(lock); \
} while (0)
#else
# define rwlock_init(lock) \
- do { *(lock) = __RW_LOCK_UNLOCKED(lock); __assume_ctx_lock(lock); } while (0)
+ do { *(lock) = __RW_LOCK_UNLOCKED(lock); } while (0)
#endif
#ifdef CONFIG_DEBUG_SPINLOCK
diff --git a/include/linux/rwlock_rt.h b/include/linux/rwlock_rt.h
index 37b387dcab21..5353abbfdc0b 100644
--- a/include/linux/rwlock_rt.h
+++ b/include/linux/rwlock_rt.h
@@ -22,7 +22,6 @@ do { \
\
init_rwbase_rt(&(rwl)->rwbase); \
__rt_rwlock_init(rwl, #rwl, &__key); \
- __assume_ctx_lock(rwl); \
} while (0)
extern void rt_read_lock(rwlock_t *rwlock) __acquires_shared(rwlock);
diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
index ea1bbdb57a47..9bf1d93d3d7b 100644
--- a/include/linux/rwsem.h
+++ b/include/linux/rwsem.h
@@ -121,7 +121,6 @@ do { \
static struct lock_class_key __key; \
\
__init_rwsem((sem), #sem, &__key); \
- __assume_ctx_lock(sem); \
} while (0)
/*
@@ -175,7 +174,6 @@ do { \
static struct lock_class_key __key; \
\
__init_rwsem((sem), #sem, &__key); \
- __assume_ctx_lock(sem); \
} while (0)
static __always_inline int rwsem_is_locked(const struct rw_semaphore *sem)
diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
index 22216df47b0f..c0c6235dff59 100644
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -817,7 +817,6 @@ static __always_inline void write_seqcount_latch_end(seqcount_latch_t *s)
do { \
spin_lock_init(&(sl)->lock); \
seqcount_spinlock_init(&(sl)->seqcount, &(sl)->lock); \
- __assume_ctx_lock(sl); \
} while (0)
/**
diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
index 7b11991c742a..e1e2f144af9b 100644
--- a/include/linux/spinlock.h
+++ b/include/linux/spinlock.h
@@ -106,12 +106,11 @@ do { \
static struct lock_class_key __key; \
\
__raw_spin_lock_init((lock), #lock, &__key, LD_WAIT_SPIN); \
- __assume_ctx_lock(lock); \
} while (0)
#else
# define raw_spin_lock_init(lock) \
- do { *(lock) = __RAW_SPIN_LOCK_UNLOCKED(lock); __assume_ctx_lock(lock); } while (0)
+ do { *(lock) = __RAW_SPIN_LOCK_UNLOCKED(lock); } while (0)
#endif
#define raw_spin_is_locked(lock) arch_spin_is_locked(&(lock)->raw_lock)
@@ -324,7 +323,6 @@ do { \
\
__raw_spin_lock_init(spinlock_check(lock), \
#lock, &__key, LD_WAIT_CONFIG); \
- __assume_ctx_lock(lock); \
} while (0)
#else
@@ -333,7 +331,6 @@ do { \
do { \
spinlock_check(_lock); \
*(_lock) = __SPIN_LOCK_UNLOCKED(_lock); \
- __assume_ctx_lock(_lock); \
} while (0)
#endif
diff --git a/include/linux/spinlock_rt.h b/include/linux/spinlock_rt.h
index 0a585768358f..373618a4243c 100644
--- a/include/linux/spinlock_rt.h
+++ b/include/linux/spinlock_rt.h
@@ -20,7 +20,6 @@ static inline void __rt_spin_lock_init(spinlock_t *lock, const char *name,
do { \
rt_mutex_base_init(&(slock)->lock); \
__rt_spin_lock_init(slock, name, key, percpu); \
- __assume_ctx_lock(slock); \
} while (0)
#define _spin_lock_init(slock, percpu) \
diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h
index 58e959ee10e9..c47d4b9b88b3 100644
--- a/include/linux/ww_mutex.h
+++ b/include/linux/ww_mutex.h
@@ -107,7 +107,6 @@ context_lock_struct(ww_acquire_ctx) {
*/
static inline void ww_mutex_init(struct ww_mutex *lock,
struct ww_class *ww_class)
- __assumes_ctx_lock(lock)
{
ww_mutex_base_init(&lock->base, ww_class->mutex_name, &ww_class->mutex_key);
lock->ctx = NULL;
diff --git a/lib/test_context-analysis.c b/lib/test_context-analysis.c
index 0f05943d957f..140efa8a9763 100644
--- a/lib/test_context-analysis.c
+++ b/lib/test_context-analysis.c
@@ -542,12 +542,6 @@ struct test_ww_mutex_data {
int counter __guarded_by(&mtx);
};
-static void __used test_ww_mutex_init(struct test_ww_mutex_data *d)
-{
- ww_mutex_init(&d->mtx, &ww_class);
- d->counter = 0;
-}
-
static void __used test_ww_mutex_lock_noctx(struct test_ww_mutex_data *d)
{
if (!ww_mutex_lock(&d->mtx, NULL)) {
--
2.52.0.457.g6b5491de43-goog
^ permalink raw reply related
* [PATCH tip/locking/core 5/6] tomoyo: Use scoped init guard
From: Marco Elver @ 2026-01-19 9:05 UTC (permalink / raw)
To: elver, Peter Zijlstra, Ingo Molnar
Cc: Thomas Gleixner, Will Deacon, Boqun Feng, Waiman Long,
Christoph Hellwig, Steven Rostedt, Bart Van Assche, kasan-dev,
llvm, linux-crypto, linux-doc, linux-security-module,
linux-kernel
In-Reply-To: <20260119094029.1344361-1-elver@google.com>
Convert lock initialization to scoped guarded initialization where
lock-guarded members are initialized in the same scope.
This ensures the context analysis treats the context as active during member
initialization. This is required to avoid errors once implicit context
assertion is removed.
Signed-off-by: Marco Elver <elver@google.com>
---
security/tomoyo/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/tomoyo/common.c b/security/tomoyo/common.c
index 86ce56c32d37..7e1f825d903b 100644
--- a/security/tomoyo/common.c
+++ b/security/tomoyo/common.c
@@ -2557,7 +2557,7 @@ int tomoyo_open_control(const u8 type, struct file *file)
if (!head)
return -ENOMEM;
- mutex_init(&head->io_sem);
+ guard(mutex_init)(&head->io_sem);
head->type = type;
switch (type) {
case TOMOYO_DOMAINPOLICY:
--
2.52.0.457.g6b5491de43-goog
^ permalink raw reply related
* [PATCH tip/locking/core 4/6] crypto: Use scoped init guard
From: Marco Elver @ 2026-01-19 9:05 UTC (permalink / raw)
To: elver, Peter Zijlstra, Ingo Molnar
Cc: Thomas Gleixner, Will Deacon, Boqun Feng, Waiman Long,
Christoph Hellwig, Steven Rostedt, Bart Van Assche, kasan-dev,
llvm, linux-crypto, linux-doc, linux-security-module,
linux-kernel
In-Reply-To: <20260119094029.1344361-1-elver@google.com>
Convert lock initialization to scoped guarded initialization where
lock-guarded members are initialized in the same scope.
This ensures the context analysis treats the context as active during member
initialization. This is required to avoid errors once implicit context
assertion is removed.
Signed-off-by: Marco Elver <elver@google.com>
---
crypto/crypto_engine.c | 2 +-
crypto/drbg.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/crypto_engine.c b/crypto/crypto_engine.c
index 1653a4bf5b31..afb6848f7df4 100644
--- a/crypto/crypto_engine.c
+++ b/crypto/crypto_engine.c
@@ -453,7 +453,7 @@ struct crypto_engine *crypto_engine_alloc_init_and_set(struct device *dev,
snprintf(engine->name, sizeof(engine->name),
"%s-engine", dev_name(dev));
- spin_lock_init(&engine->queue_lock);
+ guard(spinlock_init)(&engine->queue_lock);
crypto_init_queue(&engine->queue, qlen);
engine->kworker = kthread_run_worker(0, "%s", engine->name);
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 0a6f6c05a78f..21b339c76cca 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1780,7 +1780,7 @@ static inline int __init drbg_healthcheck_sanity(void)
if (!drbg)
return -ENOMEM;
- mutex_init(&drbg->drbg_mutex);
+ guard(mutex_init)(&drbg->drbg_mutex);
drbg->core = &drbg_cores[coreref];
drbg->reseed_threshold = drbg_max_requests(drbg);
--
2.52.0.457.g6b5491de43-goog
^ permalink raw reply related
* [PATCH tip/locking/core 3/6] kcov: Use scoped init guard
From: Marco Elver @ 2026-01-19 9:05 UTC (permalink / raw)
To: elver, Peter Zijlstra, Ingo Molnar
Cc: Thomas Gleixner, Will Deacon, Boqun Feng, Waiman Long,
Christoph Hellwig, Steven Rostedt, Bart Van Assche, kasan-dev,
llvm, linux-crypto, linux-doc, linux-security-module,
linux-kernel
In-Reply-To: <20260119094029.1344361-1-elver@google.com>
Convert lock initialization to scoped guarded initialization where
lock-guarded members are initialized in the same scope.
This ensures the context analysis treats the context as active during
member initialization. This is required to avoid errors once implicit
context assertion is removed.
Signed-off-by: Marco Elver <elver@google.com>
---
kernel/kcov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/kcov.c b/kernel/kcov.c
index 6cbc6e2d8aee..5397d0c14127 100644
--- a/kernel/kcov.c
+++ b/kernel/kcov.c
@@ -530,7 +530,7 @@ static int kcov_open(struct inode *inode, struct file *filep)
kcov = kzalloc(sizeof(*kcov), GFP_KERNEL);
if (!kcov)
return -ENOMEM;
- spin_lock_init(&kcov->lock);
+ guard(spinlock_init)(&kcov->lock);
kcov->mode = KCOV_MODE_DISABLED;
kcov->sequence = 1;
refcount_set(&kcov->refcount, 1);
--
2.52.0.457.g6b5491de43-goog
^ permalink raw reply related
* [PATCH tip/locking/core 2/6] compiler-context-analysis: Introduce scoped init guards
From: Marco Elver @ 2026-01-19 9:05 UTC (permalink / raw)
To: elver, Peter Zijlstra, Ingo Molnar
Cc: Thomas Gleixner, Will Deacon, Boqun Feng, Waiman Long,
Christoph Hellwig, Steven Rostedt, Bart Van Assche, kasan-dev,
llvm, linux-crypto, linux-doc, linux-security-module,
linux-kernel
In-Reply-To: <20260119094029.1344361-1-elver@google.com>
Add scoped init guard definitions for common synchronization primitives
supported by context analysis.
The scoped init guards treat the context as active within initialization
scope of the underlying context lock, given initialization implies
exclusive access to the underlying object. This allows initialization of
guarded members without disabling context analysis, while documenting
initialization from subsequent usage.
The documentation is updated with the new recommendation. Where scoped
init guards are not provided or cannot be implemented (ww_mutex omitted
for lack of multi-arg guard initializers), the alternative is to just
disable context analysis where guarded members are initialized.
Link: https://lore.kernel.org/all/20251212095943.GM3911114@noisy.programming.kicks-ass.net/
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Marco Elver <elver@google.com>
---
Documentation/dev-tools/context-analysis.rst | 30 ++++++++++++++++++--
include/linux/compiler-context-analysis.h | 9 ++----
include/linux/local_lock.h | 8 ++++++
include/linux/local_lock_internal.h | 1 +
include/linux/mutex.h | 3 ++
include/linux/rwsem.h | 4 +++
include/linux/seqlock.h | 5 ++++
include/linux/spinlock.h | 12 ++++++++
lib/test_context-analysis.c | 16 +++++------
9 files changed, 70 insertions(+), 18 deletions(-)
diff --git a/Documentation/dev-tools/context-analysis.rst b/Documentation/dev-tools/context-analysis.rst
index e69896e597b6..54d9ee28de98 100644
--- a/Documentation/dev-tools/context-analysis.rst
+++ b/Documentation/dev-tools/context-analysis.rst
@@ -83,9 +83,33 @@ Currently the following synchronization primitives are supported:
`bit_spinlock`, RCU, SRCU (`srcu_struct`), `rw_semaphore`, `local_lock_t`,
`ww_mutex`.
-For context locks with an initialization function (e.g., `spin_lock_init()`),
-calling this function before initializing any guarded members or globals
-prevents the compiler from issuing warnings about unguarded initialization.
+To initialize variables guarded by a context lock with an initialization
+function (``type_init(&lock)``), prefer using ``guard(type_init)(&lock)`` or
+``scoped_guard(type_init, &lock) { ... }`` to initialize such guarded members
+or globals in the enclosing scope. This initializes the context lock and treats
+the context as active within the initialization scope (initialization implies
+exclusive access to the underlying object).
+
+For example::
+
+ struct my_data {
+ spinlock_t lock;
+ int counter __guarded_by(&lock);
+ };
+
+ void init_my_data(struct my_data *d)
+ {
+ ...
+ guard(spinlock_init)(&d->lock);
+ d->counter = 0;
+ ...
+ }
+
+Alternatively, initializing guarded variables can be done with context analysis
+disabled, preferably in the smallest possible scope (due to lack of any other
+checking): either with a ``context_unsafe(var = init)`` expression, or by
+marking small initialization functions with the ``__context_unsafe(init)``
+attribute.
Lockdep assertions, such as `lockdep_assert_held()`, inform the compiler's
context analysis that the associated synchronization primitive is held after
diff --git a/include/linux/compiler-context-analysis.h b/include/linux/compiler-context-analysis.h
index db7e0d48d8f2..27ea01adeb2c 100644
--- a/include/linux/compiler-context-analysis.h
+++ b/include/linux/compiler-context-analysis.h
@@ -32,13 +32,8 @@
/*
* The "assert_capability" attribute is a bit confusingly named. It does not
* generate a check. Instead, it tells the analysis to *assume* the capability
- * is held. This is used for:
- *
- * 1. Augmenting runtime assertions, that can then help with patterns beyond the
- * compiler's static reasoning abilities.
- *
- * 2. Initialization of context locks, so we can access guarded variables right
- * after initialization (nothing else should access the same object yet).
+ * is held. This is used for augmenting runtime assertions, that can then help
+ * with patterns beyond the compiler's static reasoning abilities.
*/
# define __assumes_ctx_lock(...) __attribute__((assert_capability(__VA_ARGS__)))
# define __assumes_shared_ctx_lock(...) __attribute__((assert_shared_capability(__VA_ARGS__)))
diff --git a/include/linux/local_lock.h b/include/linux/local_lock.h
index 99c06e499375..b8830148a859 100644
--- a/include/linux/local_lock.h
+++ b/include/linux/local_lock.h
@@ -104,6 +104,8 @@ DEFINE_LOCK_GUARD_1(local_lock_nested_bh, local_lock_t __percpu,
local_lock_nested_bh(_T->lock),
local_unlock_nested_bh(_T->lock))
+DEFINE_LOCK_GUARD_1(local_lock_init, local_lock_t, local_lock_init(_T->lock), /* */)
+
DECLARE_LOCK_GUARD_1_ATTRS(local_lock, __acquires(_T), __releases(*(local_lock_t __percpu **)_T))
#define class_local_lock_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(local_lock, _T)
DECLARE_LOCK_GUARD_1_ATTRS(local_lock_irq, __acquires(_T), __releases(*(local_lock_t __percpu **)_T))
@@ -112,5 +114,11 @@ DECLARE_LOCK_GUARD_1_ATTRS(local_lock_irqsave, __acquires(_T), __releases(*(loca
#define class_local_lock_irqsave_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(local_lock_irqsave, _T)
DECLARE_LOCK_GUARD_1_ATTRS(local_lock_nested_bh, __acquires(_T), __releases(*(local_lock_t __percpu **)_T))
#define class_local_lock_nested_bh_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(local_lock_nested_bh, _T)
+DECLARE_LOCK_GUARD_1_ATTRS(local_lock_init, __acquires(_T), __releases(*(local_lock_t **)_T))
+#define class_local_lock_init_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(local_lock_init, _T)
+
+DEFINE_LOCK_GUARD_1(local_trylock_init, local_trylock_t, local_trylock_init(_T->lock), /* */)
+DECLARE_LOCK_GUARD_1_ATTRS(local_trylock_init, __acquires(_T), __releases(*(local_trylock_t **)_T))
+#define class_local_trylock_init_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(local_trylock_init, _T)
#endif
diff --git a/include/linux/local_lock_internal.h b/include/linux/local_lock_internal.h
index e8c4803d8db4..4521c40895f8 100644
--- a/include/linux/local_lock_internal.h
+++ b/include/linux/local_lock_internal.h
@@ -6,6 +6,7 @@
#include <linux/percpu-defs.h>
#include <linux/irqflags.h>
#include <linux/lockdep.h>
+#include <linux/debug_locks.h>
#include <asm/current.h>
#ifndef CONFIG_PREEMPT_RT
diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index 89977c215cbd..6b12009351d2 100644
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h
@@ -254,6 +254,7 @@ extern int atomic_dec_and_mutex_lock(atomic_t *cnt, struct mutex *lock) __cond_a
DEFINE_LOCK_GUARD_1(mutex, struct mutex, mutex_lock(_T->lock), mutex_unlock(_T->lock))
DEFINE_LOCK_GUARD_1_COND(mutex, _try, mutex_trylock(_T->lock))
DEFINE_LOCK_GUARD_1_COND(mutex, _intr, mutex_lock_interruptible(_T->lock), _RET == 0)
+DEFINE_LOCK_GUARD_1(mutex_init, struct mutex, mutex_init(_T->lock), /* */)
DECLARE_LOCK_GUARD_1_ATTRS(mutex, __acquires(_T), __releases(*(struct mutex **)_T))
#define class_mutex_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(mutex, _T)
@@ -261,6 +262,8 @@ DECLARE_LOCK_GUARD_1_ATTRS(mutex_try, __acquires(_T), __releases(*(struct mutex
#define class_mutex_try_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(mutex_try, _T)
DECLARE_LOCK_GUARD_1_ATTRS(mutex_intr, __acquires(_T), __releases(*(struct mutex **)_T))
#define class_mutex_intr_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(mutex_intr, _T)
+DECLARE_LOCK_GUARD_1_ATTRS(mutex_init, __acquires(_T), __releases(*(struct mutex **)_T))
+#define class_mutex_init_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(mutex_init, _T)
extern unsigned long mutex_get_owner(struct mutex *lock);
diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
index 8da14a08a4e1..ea1bbdb57a47 100644
--- a/include/linux/rwsem.h
+++ b/include/linux/rwsem.h
@@ -280,6 +280,10 @@ DECLARE_LOCK_GUARD_1_ATTRS(rwsem_write_try, __acquires(_T), __releases(*(struct
DECLARE_LOCK_GUARD_1_ATTRS(rwsem_write_kill, __acquires(_T), __releases(*(struct rw_semaphore **)_T))
#define class_rwsem_write_kill_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(rwsem_write_kill, _T)
+DEFINE_LOCK_GUARD_1(rwsem_init, struct rw_semaphore, init_rwsem(_T->lock), /* */)
+DECLARE_LOCK_GUARD_1_ATTRS(rwsem_init, __acquires(_T), __releases(*(struct rw_semaphore **)_T))
+#define class_rwsem_init_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(rwsem_init, _T)
+
/*
* downgrade write lock to read lock
*/
diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
index 113320911a09..22216df47b0f 100644
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -14,6 +14,7 @@
*/
#include <linux/compiler.h>
+#include <linux/cleanup.h>
#include <linux/kcsan-checks.h>
#include <linux/lockdep.h>
#include <linux/mutex.h>
@@ -1359,4 +1360,8 @@ static __always_inline void __scoped_seqlock_cleanup_ctx(struct ss_tmp **s)
#define scoped_seqlock_read(_seqlock, _target) \
__scoped_seqlock_read(_seqlock, _target, __UNIQUE_ID(seqlock))
+DEFINE_LOCK_GUARD_1(seqlock_init, seqlock_t, seqlock_init(_T->lock), /* */)
+DECLARE_LOCK_GUARD_1_ATTRS(seqlock_init, __acquires(_T), __releases(*(seqlock_t **)_T))
+#define class_seqlock_init_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(seqlock_init, _T)
+
#endif /* __LINUX_SEQLOCK_H */
diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
index 396b8c5d6c1b..7b11991c742a 100644
--- a/include/linux/spinlock.h
+++ b/include/linux/spinlock.h
@@ -582,6 +582,10 @@ DEFINE_LOCK_GUARD_1_COND(raw_spinlock_irqsave, _try,
DECLARE_LOCK_GUARD_1_ATTRS(raw_spinlock_irqsave_try, __acquires(_T), __releases(*(raw_spinlock_t **)_T))
#define class_raw_spinlock_irqsave_try_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(raw_spinlock_irqsave_try, _T)
+DEFINE_LOCK_GUARD_1(raw_spinlock_init, raw_spinlock_t, raw_spin_lock_init(_T->lock), /* */)
+DECLARE_LOCK_GUARD_1_ATTRS(raw_spinlock_init, __acquires(_T), __releases(*(raw_spinlock_t **)_T))
+#define class_raw_spinlock_init_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(raw_spinlock_init, _T)
+
DEFINE_LOCK_GUARD_1(spinlock, spinlock_t,
spin_lock(_T->lock),
spin_unlock(_T->lock))
@@ -626,6 +630,10 @@ DEFINE_LOCK_GUARD_1_COND(spinlock_irqsave, _try,
DECLARE_LOCK_GUARD_1_ATTRS(spinlock_irqsave_try, __acquires(_T), __releases(*(spinlock_t **)_T))
#define class_spinlock_irqsave_try_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(spinlock_irqsave_try, _T)
+DEFINE_LOCK_GUARD_1(spinlock_init, spinlock_t, spin_lock_init(_T->lock), /* */)
+DECLARE_LOCK_GUARD_1_ATTRS(spinlock_init, __acquires(_T), __releases(*(spinlock_t **)_T))
+#define class_spinlock_init_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(spinlock_init, _T)
+
DEFINE_LOCK_GUARD_1(read_lock, rwlock_t,
read_lock(_T->lock),
read_unlock(_T->lock))
@@ -664,5 +672,9 @@ DEFINE_LOCK_GUARD_1(write_lock_irqsave, rwlock_t,
DECLARE_LOCK_GUARD_1_ATTRS(write_lock_irqsave, __acquires(_T), __releases(*(rwlock_t **)_T))
#define class_write_lock_irqsave_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(write_lock_irqsave, _T)
+DEFINE_LOCK_GUARD_1(rwlock_init, rwlock_t, rwlock_init(_T->lock), /* */)
+DECLARE_LOCK_GUARD_1_ATTRS(rwlock_init, __acquires(_T), __releases(*(rwlock_t **)_T))
+#define class_rwlock_init_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(rwlock_init, _T)
+
#undef __LINUX_INSIDE_SPINLOCK_H
#endif /* __LINUX_SPINLOCK_H */
diff --git a/lib/test_context-analysis.c b/lib/test_context-analysis.c
index 1c5a381461fc..0f05943d957f 100644
--- a/lib/test_context-analysis.c
+++ b/lib/test_context-analysis.c
@@ -35,7 +35,7 @@ static void __used test_common_helpers(void)
}; \
static void __used test_##class##_init(struct test_##class##_data *d) \
{ \
- type_init(&d->lock); \
+ guard(type_init)(&d->lock); \
d->counter = 0; \
} \
static void __used test_##class(struct test_##class##_data *d) \
@@ -83,7 +83,7 @@ static void __used test_common_helpers(void)
TEST_SPINLOCK_COMMON(raw_spinlock,
raw_spinlock_t,
- raw_spin_lock_init,
+ raw_spinlock_init,
raw_spin_lock,
raw_spin_unlock,
raw_spin_trylock,
@@ -109,7 +109,7 @@ static void __used test_raw_spinlock_trylock_extra(struct test_raw_spinlock_data
TEST_SPINLOCK_COMMON(spinlock,
spinlock_t,
- spin_lock_init,
+ spinlock_init,
spin_lock,
spin_unlock,
spin_trylock,
@@ -163,7 +163,7 @@ struct test_mutex_data {
static void __used test_mutex_init(struct test_mutex_data *d)
{
- mutex_init(&d->mtx);
+ guard(mutex_init)(&d->mtx);
d->counter = 0;
}
@@ -226,7 +226,7 @@ struct test_seqlock_data {
static void __used test_seqlock_init(struct test_seqlock_data *d)
{
- seqlock_init(&d->sl);
+ guard(seqlock_init)(&d->sl);
d->counter = 0;
}
@@ -275,7 +275,7 @@ struct test_rwsem_data {
static void __used test_rwsem_init(struct test_rwsem_data *d)
{
- init_rwsem(&d->sem);
+ guard(rwsem_init)(&d->sem);
d->counter = 0;
}
@@ -475,7 +475,7 @@ static DEFINE_PER_CPU(struct test_local_lock_data, test_local_lock_data) = {
static void __used test_local_lock_init(struct test_local_lock_data *d)
{
- local_lock_init(&d->lock);
+ guard(local_lock_init)(&d->lock);
d->counter = 0;
}
@@ -519,7 +519,7 @@ static DEFINE_PER_CPU(struct test_local_trylock_data, test_local_trylock_data) =
static void __used test_local_trylock_init(struct test_local_trylock_data *d)
{
- local_trylock_init(&d->lock);
+ guard(local_trylock_init)(&d->lock);
d->counter = 0;
}
--
2.52.0.457.g6b5491de43-goog
^ permalink raw reply related
* [PATCH tip/locking/core 1/6] cleanup: Make __DEFINE_LOCK_GUARD handle commas in initializers
From: Marco Elver @ 2026-01-19 9:05 UTC (permalink / raw)
To: elver, Peter Zijlstra, Ingo Molnar
Cc: Thomas Gleixner, Will Deacon, Boqun Feng, Waiman Long,
Christoph Hellwig, Steven Rostedt, Bart Van Assche, kasan-dev,
llvm, linux-crypto, linux-doc, linux-security-module,
linux-kernel, kernel test robot
In-Reply-To: <20260119094029.1344361-1-elver@google.com>
Initialization macros can expand to structure initializers containing
commas, which when used as a "lock" function resulted in errors such as:
>> include/linux/spinlock.h:582:56: error: too many arguments provided to function-like macro invocation
582 | DEFINE_LOCK_GUARD_1(raw_spinlock_init, raw_spinlock_t, raw_spin_lock_init(_T->lock), /* */)
| ^
include/linux/spinlock.h:113:17: note: expanded from macro 'raw_spin_lock_init'
113 | do { *(lock) = __RAW_SPIN_LOCK_UNLOCKED(lock); } while (0)
| ^
include/linux/spinlock_types_raw.h:70:19: note: expanded from macro '__RAW_SPIN_LOCK_UNLOCKED'
70 | (raw_spinlock_t) __RAW_SPIN_LOCK_INITIALIZER(lockname)
| ^
include/linux/spinlock_types_raw.h:67:34: note: expanded from macro '__RAW_SPIN_LOCK_INITIALIZER'
67 | RAW_SPIN_DEP_MAP_INIT(lockname) }
| ^
include/linux/cleanup.h:496:9: note: macro '__DEFINE_LOCK_GUARD_1' defined here
496 | #define __DEFINE_LOCK_GUARD_1(_name, _type, _lock) \
| ^
include/linux/spinlock.h:582:1: note: parentheses are required around macro argument containing braced initializer list
582 | DEFINE_LOCK_GUARD_1(raw_spinlock_init, raw_spinlock_t, raw_spin_lock_init(_T->lock), /* */)
| ^
| (
include/linux/cleanup.h:558:60: note: expanded from macro 'DEFINE_LOCK_GUARD_1'
558 | __DEFINE_UNLOCK_GUARD(_name, _type, _unlock, __VA_ARGS__) \
| ^
Make __DEFINE_LOCK_GUARD_0 and __DEFINE_LOCK_GUARD_1 variadic so that
__VA_ARGS__ captures everything.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Marco Elver <elver@google.com>
---
include/linux/cleanup.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/cleanup.h b/include/linux/cleanup.h
index ee6df68c2177..dbc4162921e9 100644
--- a/include/linux/cleanup.h
+++ b/include/linux/cleanup.h
@@ -493,22 +493,22 @@ static __always_inline void class_##_name##_destructor(class_##_name##_t *_T) \
\
__DEFINE_GUARD_LOCK_PTR(_name, &_T->lock)
-#define __DEFINE_LOCK_GUARD_1(_name, _type, _lock) \
+#define __DEFINE_LOCK_GUARD_1(_name, _type, ...) \
static __always_inline class_##_name##_t class_##_name##_constructor(_type *l) \
__no_context_analysis \
{ \
class_##_name##_t _t = { .lock = l }, *_T = &_t; \
- _lock; \
+ __VA_ARGS__; \
return _t; \
}
-#define __DEFINE_LOCK_GUARD_0(_name, _lock) \
+#define __DEFINE_LOCK_GUARD_0(_name, ...) \
static __always_inline class_##_name##_t class_##_name##_constructor(void) \
__no_context_analysis \
{ \
class_##_name##_t _t = { .lock = (void*)1 }, \
*_T __maybe_unused = &_t; \
- _lock; \
+ __VA_ARGS__; \
return _t; \
}
--
2.52.0.457.g6b5491de43-goog
^ permalink raw reply related
* [PATCH tip/locking/core 0/6] compiler-context-analysis: Scoped init guards
From: Marco Elver @ 2026-01-19 9:05 UTC (permalink / raw)
To: elver, Peter Zijlstra, Ingo Molnar
Cc: Thomas Gleixner, Will Deacon, Boqun Feng, Waiman Long,
Christoph Hellwig, Steven Rostedt, Bart Van Assche, kasan-dev,
llvm, linux-crypto, linux-doc, linux-security-module,
linux-kernel
Current context analysis treats lock_init() as implicitly "holding" the
lock to allow initializing guarded members. This causes false-positive
"double lock" reports if the lock is acquired immediately after
initialization in the same scope; for example:
mutex_init(&d->mtx);
/* ... counter is guarded by mtx ... */
d->counter = 0; /* ok, but mtx is now "held" */
...
mutex_lock(&d->mtx); /* warning: acquiring mutex already held */
This series proposes a solution to this by introducing scoped init
guards which Peter suggested, using the guard(type_init)(&lock) or
scoped_guard(type_init, ..) interface. This explicitly marks init scope
where we can initialize guarded members. With that we can revert the
"implicitly hold" after init annotations, which allows use after
initialization scope as follows:
scoped_guard(mutex_init, &d->mtx) {
d->counter = 0;
}
...
mutex_lock(&d->mtx); /* ok */
Note: Scoped guarded initialization remains optional, and normal
initialization can still be used if no guarded members are being
initialized. Another alternative is to just disable context analysis to
initialize guarded members with `context_unsafe(var = init)` or adding
the `__context_unsafe(init)` function attribute (the latter not being
recommended for non-trivial functions due to lack of any checking):
mutex_init(&d->mtx);
context_unsafe(d->counter = 0); /* ok */
...
mutex_lock(&d->mtx);
This series is an alternative to the approach in [1]:
* Scoped init guards (this series): Sound interface, requires use of
guard(type_init)(&lock) or scoped_guard(type_init, ..) for guarded
member initialization.
* Reentrant init [1]: Less intrusive, type_init() just works, and
also allows guarded member initialization with later lock use in
the same function. But unsound, and e.g. misses double-lock bugs
immediately after init, trading false positives for false negatives.
[1] https://lore.kernel.org/all/20260115005231.1211866-1-elver@google.com/
Marco Elver (6):
cleanup: Make __DEFINE_LOCK_GUARD handle commas in initializers
compiler-context-analysis: Introduce scoped init guards
kcov: Use scoped init guard
crypto: Use scoped init guard
tomoyo: Use scoped init guard
compiler-context-analysis: Remove __assume_ctx_lock from initializers
Documentation/dev-tools/context-analysis.rst | 30 ++++++++++++++++++--
crypto/crypto_engine.c | 2 +-
crypto/drbg.c | 2 +-
include/linux/cleanup.h | 8 +++---
include/linux/compiler-context-analysis.h | 9 ++----
include/linux/local_lock.h | 8 ++++++
include/linux/local_lock_internal.h | 4 +--
include/linux/mutex.h | 4 ++-
include/linux/rwlock.h | 3 +-
include/linux/rwlock_rt.h | 1 -
include/linux/rwsem.h | 6 ++--
include/linux/seqlock.h | 6 +++-
include/linux/spinlock.h | 17 ++++++++---
include/linux/spinlock_rt.h | 1 -
include/linux/ww_mutex.h | 1 -
kernel/kcov.c | 2 +-
lib/test_context-analysis.c | 22 ++++++--------
security/tomoyo/common.c | 2 +-
18 files changed, 80 insertions(+), 48 deletions(-)
--
2.52.0.457.g6b5491de43-goog
^ permalink raw reply
* [PATCH -next] lockdown: Add break in lockdown_write
From: Cai Xinchen @ 2026-01-19 9:12 UTC (permalink / raw)
To: nicolas.bouchinet, xiujianfeng, paul, jmorris, serge
Cc: linux-security-module, linux-kernel, caixinchen1
After the label is matched successful, any other levels judgements
are meaningless. Therefore, add break to return early
Signed-off-by: Cai Xinchen <caixinchen1@huawei.com>
---
security/lockdown/lockdown.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index 8d46886d2cca..263dcc80d839 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -139,8 +139,10 @@ static ssize_t lockdown_write(struct file *file, const char __user *buf,
enum lockdown_reason level = lockdown_levels[i];
const char *label = lockdown_reasons[level];
- if (label && !strcmp(state, label))
+ if (label && !strcmp(state, label)) {
err = lock_kernel_down("securityfs", level);
+ break;
+ }
}
kfree(state);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] security: export binder symbols
From: Greg Kroah-Hartman @ 2026-01-19 9:13 UTC (permalink / raw)
To: Alice Ryhl
Cc: Paul Moore, James Morris, Serge E. Hallyn, Carlos Llamas,
linux-security-module, linux-kernel
In-Reply-To: <20260119085109.2238878-1-aliceryhl@google.com>
On Mon, Jan 19, 2026 at 08:51:07AM +0000, Alice Ryhl wrote:
> To enable building Rust Binder (possibly also C Binder) as a module,
> export these symbols.
>
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
> security/security.c | 4 ++++
> 1 file changed, 4 insertions(+)
We need this as a patch series that actually uses these symbols from a
module please.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] security: export binder symbols
From: Alice Ryhl @ 2026-01-19 8:51 UTC (permalink / raw)
To: Paul Moore, James Morris, Serge E. Hallyn
Cc: Alice Ryhl, Carlos Llamas, Greg Kroah-Hartman,
linux-security-module, linux-kernel
To enable building Rust Binder (possibly also C Binder) as a module,
export these symbols.
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
security/security.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/security/security.c b/security/security.c
index 31a688650601..b4776f0e25b3 100644
--- a/security/security.c
+++ b/security/security.c
@@ -479,61 +479,65 @@ int security_binder_set_context_mgr(const struct cred *mgr)
/**
* security_binder_set_context_mgr() - Check if becoming binder ctx mgr is ok
* @mgr: task credentials of current binder process
*
* Check whether @mgr is allowed to be the binder context manager.
*
* Return: Return 0 if permission is granted.
*/
int security_binder_set_context_mgr(const struct cred *mgr)
{
return call_int_hook(binder_set_context_mgr, mgr);
}
+EXPORT_SYMBOL_GPL(security_binder_set_context_mgr);
/**
* security_binder_transaction() - Check if a binder transaction is allowed
* @from: sending process
* @to: receiving process
*
* Check whether @from is allowed to invoke a binder transaction call to @to.
*
* Return: Returns 0 if permission is granted.
*/
int security_binder_transaction(const struct cred *from,
const struct cred *to)
{
return call_int_hook(binder_transaction, from, to);
}
+EXPORT_SYMBOL_GPL(security_binder_transaction);
/**
* security_binder_transfer_binder() - Check if a binder transfer is allowed
* @from: sending process
* @to: receiving process
*
* Check whether @from is allowed to transfer a binder reference to @to.
*
* Return: Returns 0 if permission is granted.
*/
int security_binder_transfer_binder(const struct cred *from,
const struct cred *to)
{
return call_int_hook(binder_transfer_binder, from, to);
}
+EXPORT_SYMBOL_GPL(security_binder_transfer_binder);
/**
* security_binder_transfer_file() - Check if a binder file xfer is allowed
* @from: sending process
* @to: receiving process
* @file: file being transferred
*
* Check whether @from is allowed to transfer @file to @to.
*
* Return: Returns 0 if permission is granted.
*/
int security_binder_transfer_file(const struct cred *from,
const struct cred *to, const struct file *file)
{
return call_int_hook(binder_transfer_file, from, to, file);
}
+EXPORT_SYMBOL_GPL(security_binder_transfer_file);
/**
* security_ptrace_access_check() - Check if tracing is allowed
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
prerequisite-patch-id: 0000000000000000000000000000000000000000
--
2.52.0.457.g6b5491de43-goog
^ permalink raw reply related
* Re: [PATCH 2/3] evm: Don't enable fix mode when secure boot is enabled
From: Coiby Xu @ 2026-01-19 4:10 UTC (permalink / raw)
To: Roberto Sassu
Cc: Mimi Zohar, linux-integrity, Heiko Carstens, Roberto Sassu,
Dmitry Kasatkin, Eric Snowberg, Paul Moore, James Morris,
Serge E. Hallyn, open list:SECURITY SUBSYSTEM, open list
In-Reply-To: <f38b2512d51351f83c51b6e2b5dec11eb7e6959d.camel@huaweicloud.com>
On Fri, Jan 16, 2026 at 01:06:32PM +0100, Roberto Sassu wrote:
>On Thu, 2026-01-15 at 13:15 -0500, Mimi Zohar wrote:
>> On Thu, 2026-01-15 at 08:43 +0800, Coiby Xu wrote:
>> > Similar to IMA fix mode, forbid EVM fix mode when secure boot is
>> > enabled.
>> >
>> > Reported-and-suggested-by: Mimi Zohar <zohar@linux.ibm.com>
>> > Suggested-by: Roberto Sassu <roberto.sassu@huaweicloud.com>
>
>Ah, if possible, could you please change the email to
>roberto.sassu@huawei.com?
Thanks for the reminder! I'll use the above email.
--
Best regards,
Coiby
^ permalink raw reply
* Re: [PATCH 1/3] integrity: Make arch_ima_get_secureboot integrity-wide
From: Coiby Xu @ 2026-01-19 4:04 UTC (permalink / raw)
To: Ard Biesheuvel, Mimi Zohar
Cc: linux-integrity, Heiko Carstens, Roberto Sassu, Catalin Marinas,
Will Deacon, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), H. Peter Anvin,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Paul Moore,
James Morris, Serge E. Hallyn, Jarkko Sakkinen,
moderated list:ARM64 PORT (AARCH64 ARCHITECTURE), open list,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:S390 ARCHITECTURE,
open list:EXTENSIBLE FIRMWARE INTERFACE (EFI),
open list:SECURITY SUBSYSTEM, open list:KEYS/KEYRINGS_INTEGRITY
In-Reply-To: <ac5e5e45c12e9b0bda19807e60b06057d74be0b3.camel@linux.ibm.com>
On Sun, Jan 18, 2026 at 01:25:52PM -0500, Mimi Zohar wrote:
>On Fri, 2026-01-16 at 18:27 +0100, Ard Biesheuvel wrote:
Hi Ard and Mimi,
Thanks for your discussion on improving the patch!
>> On Fri, 16 Jan 2026 at 17:39, Mimi Zohar <zohar@linux.ibm.com> wrote:
>> >
>> > On Fri, 2026-01-16 at 14:18 +0100, Ard Biesheuvel wrote:
>> > > On Fri, 16 Jan 2026 at 14:11, Mimi Zohar <zohar@linux.ibm.com> wrote:
>> > > >
>> > > > On Fri, 2026-01-16 at 10:41 +0100, Ard Biesheuvel wrote:
>> > > > > On Thu, 15 Jan 2026 at 01:43, Coiby Xu <coxu@redhat.com> wrote:
>> > > > > >
>> > > > > > EVM and other LSMs need the ability to query the secure boot status of
>> > > > > > the system, without directly calling the IMA arch_ima_get_secureboot
>> > > > > > function. Refactor the secure boot status check into a general,
>> > > > > > integrity-wide function named arch_integrity_get_secureboot.
>> > > > > >
>> > > > > > Define a new Kconfig option CONFIG_INTEGRITY_SECURE_BOOT, which is
>> > > > > > automatically configured by the supported architectures. The existing
>> > > > > > IMA_SECURE_AND_OR_TRUSTED_BOOT Kconfig loads the architecture specific
>> > > > > > IMA policy based on the refactored secure boot status code.
>> > > > > >
>> > > > > > Reported-and-suggested-by: Mimi Zohar <zohar@linux.ibm.com>
>> > > > > > Suggested-by: Roberto Sassu <roberto.sassu@huaweicloud.com>
>> > > > > > Signed-off-by: Coiby Xu <coxu@redhat.com>
>> > > > > > ---
>> > > > > > arch/arm64/Kconfig | 1 +
>> > > > > > arch/powerpc/Kconfig | 1 +
>> > > > > > arch/powerpc/kernel/Makefile | 2 +-
>> > > > > > arch/powerpc/kernel/ima_arch.c | 5 --
>> > > > > > arch/powerpc/kernel/integrity_sb_arch.c | 13 +++++
>> > > > > > arch/s390/Kconfig | 1 +
>> > > > > > arch/s390/kernel/Makefile | 1 +
>> > > > > > arch/s390/kernel/ima_arch.c | 6 --
>> > > > > > arch/s390/kernel/integrity_sb_arch.c | 9 +++
>> > > > > > arch/x86/Kconfig | 1 +
>> > > > > > arch/x86/include/asm/efi.h | 4 +-
>> > > > > > arch/x86/platform/efi/efi.c | 2 +-
>> > > > > > include/linux/ima.h | 7 +--
>> > > > > > include/linux/integrity.h | 8 +++
>> > > > > > security/integrity/Kconfig | 6 ++
>> > > > > > security/integrity/Makefile | 3 +
>> > > > > > security/integrity/efi_secureboot.c | 56 +++++++++++++++++++
>> > > > > > security/integrity/ima/ima_appraise.c | 2 +-
>> > > > > > security/integrity/ima/ima_efi.c | 47 +---------------
>> > > > > > security/integrity/ima/ima_main.c | 4 +-
>> > > > > > security/integrity/platform_certs/load_uefi.c | 2 +-
>> > > > > > 21 files changed, 111 insertions(+), 70 deletions(-)
>> > > > > > create mode 100644 arch/powerpc/kernel/integrity_sb_arch.c
>> > > > > > create mode 100644 arch/s390/kernel/integrity_sb_arch.c
>> > > > > > create mode 100644 security/integrity/efi_secureboot.c
>> > > > > >
>> > > > > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> > > > > > index 93173f0a09c7..4c265b7386bb 100644
>> > > > > > --- a/arch/arm64/Kconfig
>> > > > > > +++ b/arch/arm64/Kconfig
>> > > > > > @@ -2427,6 +2427,7 @@ config EFI
>> > > > > > select EFI_STUB
>> > > > > > select EFI_GENERIC_STUB
>> > > > > > imply IMA_SECURE_AND_OR_TRUSTED_BOOT
>> > > > > > + imply INTEGRITY_SECURE_BOOT
>> > > > >
>> > > > > This allows both to be en/disabled individually, which I don't think
>> > > > > is what we want. It also results in more churn across the
>> > > > > arch-specific Kconfigs than needed.
>> > > > >
>> > > > > Wouldn't it be better if IMA_SECURE_AND_OR_TRUSTED_BOOT 'select'ed
>> > > > > INTEGRITY_SECURE_BOOT in its Kconfig definition?
>> > > >
>> > > > As much as possible, EVM (and other LSMs) shouldn't be dependent on another LSM,
>> > > > in this case IMA, being configured.
>> > >
>> > > Sure, but that is not my point.
>> > >
>> > > This arrangement allows for IMA_SECURE_AND_OR_TRUSTED_BOOT to be
>> > > enabled without INTEGRITY_SECURE_BOOT, resulting in the stub
>> > > implementation of arch_integrity_get_secureboot() being used, which
>> > > always returns false.
Since both INTEGRITY_SECURE_BOOT and IMA_SECURE_AND_OR_TRUSTED_BOOT
don't define a prompt, they are not user-configurable and will always be
enable/disabled together with arch-specific secure boot feature. So
despite the "imply" key word, the case where
IMA_SECURE_AND_OR_TRUSTED_BOOT is enabled whereas INTEGRITY_SECURE_BOOT
is disabled won't happen.
But I agree an arch may not care much about INTEGRITY_SECURE_BOOT so it
may be a churn. So limiting it to the scope of the integrity subsystem
can be a better idea.
>> >
>> > I understand your concern, but instead of "select"ing INTEGRITY_SECURE_BOOT from
>> > IMA_SECURE_AND_OR_TRUSTED_BOOT, how making IMA_SECURE_AND_OR_TRUSTED_BOOT
>> > dependent on both IMA_ARCH_POLICY and INTEGRITY_SECURE_BOOT.
>> >
>>
>> Given that INTEGRITY_SECURE_BOOT has no dependencies of its own,
>> afaict, selecting it is the least disruptive option, as otherwise,
>> existing configs will disable IMA_SECURE_AND_OR_TRUSTED_BOOT as the
>> kernel is being upgraded. But conceptually, I agree that they are
>> equivalent.
As already pointed out on by Mimi, INTEGRITY_SECURE_BOOT depend on
arch-specific secure boot feature. So we can't say INTEGRITY_SECURE_BOOT
has no dependencies.
>>
>> > Including the "imply INTEGRITY_SECURE_BOOT" here in the arch Kconfig allows EVM
>> > to query the secure boot state without relying on IMA_SECURE_AND_OR_TRUSTED_BOOT
>> > being configured.
>>
>> Yes, I understand that this is the whole point of the exercise. But
>> 'imply' should be used with care, and in this case, implying both from
>> CONFIG_EFI really makes little sense. INTEGRITY_SECURE_BOOT should be
>> selected by options that need the functionality, not 'implied' by
>> options that might provide it.
But again I agree INTEGRITY_SECURE_BOOT should "not 'implied' by options
that might provide it".
>
>As not all arch's implement arch_integrity_get_secureboot, the definition in
>include/linux/integrity.h would need to be updated. Something like:
>
>-#ifdef CONFIG_INTEGRITY_SECURE_BOOT
>+#if (defined(CONFIG_INTEGRITY_SECURE_BOOT) && \
>+ (defined(CONFIG_X86) && defined(CONFIG_EFI)) || defined(CONFIG_S390) \
>+ || defined(CONFIG_PPC_SECURE_BOOT))
>
>Then IMA_SECURE_AND_OR_TRUSTED_BOOT and EVM could select INTEGRITY_SECURE_BOOT,
>as suggested.
Since INTEGRITY_SECURE_BOOT has a dependency, select doesn't seem to be
a good choice. If EVM does select INTEGRITY_SECURE_BOOT,
INTEGRITY_SECURE_BOOT will be enabled even if arch-specific secure boot
feature is disabled and this can lead to a building failure. How about
always enabling INTEGRITY_SECURE_BOOT when secure boot feature is
enabled and also making IMA_SECURE_AND_OR_TRUSTED_BOOT depend on
INTEGRITY_SECURE_BOOT?
diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig
index 916d4f2bfc44..cd44b46d0325 100644
--- a/security/integrity/Kconfig
+++ b/security/integrity/Kconfig
@@ -97,6 +97,13 @@ config INTEGRITY_CA_MACHINE_KEYRING_MAX
will not be loaded. The remaining MOK keys are loaded into the
.platform keyring.
+config INTEGRITY_SECURE_BOOT
+ def_bool y
+ depends on EFI || PPC_SECURE_BOOT || S390
+ help
+ Provide secure boot related helper functions like querying the
+ secure boot status.
+
diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
index 976e75f9b9ba..5dce572192d6 100644
--- a/security/integrity/ima/Kconfig
+++ b/security/integrity/ima/Kconfig
@@ -311,6 +311,7 @@ config IMA_QUEUE_EARLY_BOOT_KEYS
config IMA_SECURE_AND_OR_TRUSTED_BOOT
bool
depends on IMA_ARCH_POLICY
+ depends on INTEGRITY_SECURE_BOOT
Another idea is make a tree-wide arch_get_secureboot i.e. to move
current arch_ima_get_secureboot code to arch-specific secure boot
implementation. By this way, there will no need for a new Kconfig option
INTEGRITY_SECURE_BOOT. But I'm not sure if there is any unforeseen
concern.
--
Best regards,
Coiby
^ permalink raw reply related
* Re: [GIT PULL] Landlock fix for v6.19-rc6
From: Linus Torvalds @ 2026-01-18 23:19 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Günther Noack, Matthieu Buffet, Tingmao Wang, linux-kernel,
linux-security-module
In-Reply-To: <20260116.feegh2ohQuae@digikod.net>
On Fri, 16 Jan 2026 at 06:18, Mickaël Salaün <mic@digikod.net> wrote:
>
> Please let me know what you prefer.
Ok, I took a closer look, and yeah, it's mostly just moved lines that
made it all look rather big for this stage of the release, so I've
pulled it as-is.
I do think some of them could have been delayed, but ..
Linus
^ permalink raw reply
* Re: [PATCH 1/3] integrity: Make arch_ima_get_secureboot integrity-wide
From: Mimi Zohar @ 2026-01-18 18:25 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Coiby Xu, linux-integrity, Heiko Carstens, Roberto Sassu,
Catalin Marinas, Will Deacon, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
H. Peter Anvin, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn, Jarkko Sakkinen,
moderated list:ARM64 PORT (AARCH64 ARCHITECTURE), open list,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:S390 ARCHITECTURE,
open list:EXTENSIBLE FIRMWARE INTERFACE (EFI),
open list:SECURITY SUBSYSTEM, open list:KEYS/KEYRINGS_INTEGRITY
In-Reply-To: <CAMj1kXGx4ebaK87W7k0SNUNQnO9+=z1nmYxXC7retmp3OqRRFg@mail.gmail.com>
On Fri, 2026-01-16 at 18:27 +0100, Ard Biesheuvel wrote:
> On Fri, 16 Jan 2026 at 17:39, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >
> > On Fri, 2026-01-16 at 14:18 +0100, Ard Biesheuvel wrote:
> > > On Fri, 16 Jan 2026 at 14:11, Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > >
> > > > On Fri, 2026-01-16 at 10:41 +0100, Ard Biesheuvel wrote:
> > > > > On Thu, 15 Jan 2026 at 01:43, Coiby Xu <coxu@redhat.com> wrote:
> > > > > >
> > > > > > EVM and other LSMs need the ability to query the secure boot status of
> > > > > > the system, without directly calling the IMA arch_ima_get_secureboot
> > > > > > function. Refactor the secure boot status check into a general,
> > > > > > integrity-wide function named arch_integrity_get_secureboot.
> > > > > >
> > > > > > Define a new Kconfig option CONFIG_INTEGRITY_SECURE_BOOT, which is
> > > > > > automatically configured by the supported architectures. The existing
> > > > > > IMA_SECURE_AND_OR_TRUSTED_BOOT Kconfig loads the architecture specific
> > > > > > IMA policy based on the refactored secure boot status code.
> > > > > >
> > > > > > Reported-and-suggested-by: Mimi Zohar <zohar@linux.ibm.com>
> > > > > > Suggested-by: Roberto Sassu <roberto.sassu@huaweicloud.com>
> > > > > > Signed-off-by: Coiby Xu <coxu@redhat.com>
> > > > > > ---
> > > > > > arch/arm64/Kconfig | 1 +
> > > > > > arch/powerpc/Kconfig | 1 +
> > > > > > arch/powerpc/kernel/Makefile | 2 +-
> > > > > > arch/powerpc/kernel/ima_arch.c | 5 --
> > > > > > arch/powerpc/kernel/integrity_sb_arch.c | 13 +++++
> > > > > > arch/s390/Kconfig | 1 +
> > > > > > arch/s390/kernel/Makefile | 1 +
> > > > > > arch/s390/kernel/ima_arch.c | 6 --
> > > > > > arch/s390/kernel/integrity_sb_arch.c | 9 +++
> > > > > > arch/x86/Kconfig | 1 +
> > > > > > arch/x86/include/asm/efi.h | 4 +-
> > > > > > arch/x86/platform/efi/efi.c | 2 +-
> > > > > > include/linux/ima.h | 7 +--
> > > > > > include/linux/integrity.h | 8 +++
> > > > > > security/integrity/Kconfig | 6 ++
> > > > > > security/integrity/Makefile | 3 +
> > > > > > security/integrity/efi_secureboot.c | 56 +++++++++++++++++++
> > > > > > security/integrity/ima/ima_appraise.c | 2 +-
> > > > > > security/integrity/ima/ima_efi.c | 47 +---------------
> > > > > > security/integrity/ima/ima_main.c | 4 +-
> > > > > > security/integrity/platform_certs/load_uefi.c | 2 +-
> > > > > > 21 files changed, 111 insertions(+), 70 deletions(-)
> > > > > > create mode 100644 arch/powerpc/kernel/integrity_sb_arch.c
> > > > > > create mode 100644 arch/s390/kernel/integrity_sb_arch.c
> > > > > > create mode 100644 security/integrity/efi_secureboot.c
> > > > > >
> > > > > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > > > > > index 93173f0a09c7..4c265b7386bb 100644
> > > > > > --- a/arch/arm64/Kconfig
> > > > > > +++ b/arch/arm64/Kconfig
> > > > > > @@ -2427,6 +2427,7 @@ config EFI
> > > > > > select EFI_STUB
> > > > > > select EFI_GENERIC_STUB
> > > > > > imply IMA_SECURE_AND_OR_TRUSTED_BOOT
> > > > > > + imply INTEGRITY_SECURE_BOOT
> > > > >
> > > > > This allows both to be en/disabled individually, which I don't think
> > > > > is what we want. It also results in more churn across the
> > > > > arch-specific Kconfigs than needed.
> > > > >
> > > > > Wouldn't it be better if IMA_SECURE_AND_OR_TRUSTED_BOOT 'select'ed
> > > > > INTEGRITY_SECURE_BOOT in its Kconfig definition?
> > > >
> > > > As much as possible, EVM (and other LSMs) shouldn't be dependent on another LSM,
> > > > in this case IMA, being configured.
> > >
> > > Sure, but that is not my point.
> > >
> > > This arrangement allows for IMA_SECURE_AND_OR_TRUSTED_BOOT to be
> > > enabled without INTEGRITY_SECURE_BOOT, resulting in the stub
> > > implementation of arch_integrity_get_secureboot() being used, which
> > > always returns false.
> >
> > I understand your concern, but instead of "select"ing INTEGRITY_SECURE_BOOT from
> > IMA_SECURE_AND_OR_TRUSTED_BOOT, how making IMA_SECURE_AND_OR_TRUSTED_BOOT
> > dependent on both IMA_ARCH_POLICY and INTEGRITY_SECURE_BOOT.
> >
>
> Given that INTEGRITY_SECURE_BOOT has no dependencies of its own,
> afaict, selecting it is the least disruptive option, as otherwise,
> existing configs will disable IMA_SECURE_AND_OR_TRUSTED_BOOT as the
> kernel is being upgraded. But conceptually, I agree that they are
> equivalent.
>
> > Including the "imply INTEGRITY_SECURE_BOOT" here in the arch Kconfig allows EVM
> > to query the secure boot state without relying on IMA_SECURE_AND_OR_TRUSTED_BOOT
> > being configured.
>
> Yes, I understand that this is the whole point of the exercise. But
> 'imply' should be used with care, and in this case, implying both from
> CONFIG_EFI really makes little sense. INTEGRITY_SECURE_BOOT should be
> selected by options that need the functionality, not 'implied' by
> options that might provide it.
As not all arch's implement arch_integrity_get_secureboot, the definition in
include/linux/integrity.h would need to be updated. Something like:
-#ifdef CONFIG_INTEGRITY_SECURE_BOOT
+#if (defined(CONFIG_INTEGRITY_SECURE_BOOT) && \
+ (defined(CONFIG_X86) && defined(CONFIG_EFI)) || defined(CONFIG_S390) \
+ || defined(CONFIG_PPC_SECURE_BOOT))
Then IMA_SECURE_AND_OR_TRUSTED_BOOT and EVM could select INTEGRITY_SECURE_BOOT,
as suggested.
Mimi
^ permalink raw reply
* Re: [PATCH v2 0/5] landlock: Pathname-based UNIX connect() control
From: Günther Noack @ 2026-01-18 17:44 UTC (permalink / raw)
To: Justin Suess
Cc: Mickaël Salaün, Paul Moore, James Morris,
Serge E . Hallyn, linux-security-module, Tingmao Wang,
Samasth Norway Ananda, Matthieu Buffet, Mikhail Ivanov,
konstantin.meskhidze, Demi Marie Obenour, Alyssa Ross, Jann Horn,
Tahera Fahimi, Simon Horman, netdev, Alexander Viro,
Christian Brauner
In-Reply-To: <62eda124-de91-4445-b163-9dfb8039d08c@gmail.com>
Hello!
On Sat, Jan 17, 2026 at 01:57:20PM -0500, Justin Suess wrote:
> On 1/12/26 15:53, Günther Noack wrote:
> > On Mon, Jan 12, 2026 at 05:08:02PM +0100, Mickaël Salaün wrote:
> >> On Sat, Jan 10, 2026 at 03:32:55PM +0100, Günther Noack wrote:
> >>> ## Alternatives and Related Work
> >>>
> >>> ### Alternative: Use existing LSM hooks
> >>>
> >>> The existing hooks security_unix_stream_connect(),
> >>> security_unix_may_send() and security_socket_connect() do not give
> >>> access to the resolved file system path.
> >>>
> >>> Resolving the file system path again within Landlock would in my
> >>> understanding produce a TOCTOU race, so making the decision based on
> >>> the struct sockaddr_un contents is not an option.
> >>>
> >>> It is tempting to use the struct path that the listening socket is
> >>> bound to, which can be acquired through the existing hooks.
> >>> Unfortunately, the listening socket may have been bound from within a
> >>> different namespace, and it is therefore a path that can not actually
> >>> be referenced by the sandboxed program at the time of constructing the
> >>> Landlock policy. (More details are on the Github issue at [6] and on
> >>> the LKML at [9]).
> >> Please move (or duplicate) this rationale in the patch dedicated to the
> >> new hook. It helps patch review (and to understand commits when already
> >> merged).
> > Justin, would you like to look into this?
> > Please feel free to copy the wording.
> No problem.
>
> It's quite long, so would it make sense in the notes?
> Instead of directly in the commit message?
I think including it in the commit message is what Mickaël meant here.
The quoted email above is already from the cover letter (which I
assume you meant by "notes"?). IMHO, the considerations that are
specific to the LSM hook are OK to put on the commit that introduces
it, even if they are a bit longer. That way, a summary of the
tradeoffs also makes its way into the overall commit history (unlike
the cover letter).
FWIW, commit messages with long descriptions are not unheard of,
e.g. commit ee6a44da3c87 ("tty: Require CAP_SYS_ADMIN for all usages
of TIOCL_SELMOUSEREPORT"), which I submitted a while back.
For reference, the official guidance on commit messages is
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes
> >>> Seeking feedback on:
> >>>
> >>> - Feedback on the LSM hook name would be appreciated. We realize that
> >>> not all invocations of the LSM hook are related to connect(2) as the
> >>> name suggests, but some also happen during sendmsg(2).
> >> Renaming security_unix_path_connect() to security_unix_find() would look
> >> appropriate to me wrt the caller.
> > Justin, this is also on your commit. (I find security_unix_find() and
> > security_unix_resolve() equally acceptable options.)
> security_unix_find works for me, and seems to better match the hook
> location. I'll send an updated commit.
Thanks! Please feel free to ping me, I'd be ready to send an updated v3.
–Günther
^ permalink raw reply
* Re: [PATCH v2 0/5] landlock: Pathname-based UNIX connect() control
From: Justin Suess @ 2026-01-17 18:57 UTC (permalink / raw)
To: Günther Noack, Mickaël Salaün
Cc: Paul Moore, James Morris, Serge E . Hallyn, linux-security-module,
Tingmao Wang, Samasth Norway Ananda, Matthieu Buffet,
Mikhail Ivanov, konstantin.meskhidze, Demi Marie Obenour,
Alyssa Ross, Jann Horn, Tahera Fahimi, Simon Horman, netdev,
Alexander Viro, Christian Brauner
In-Reply-To: <20260112.a7f8e16a6573@gnoack.org>
On 1/12/26 15:53, Günther Noack wrote:
> Thanks for the review!
>
> On Mon, Jan 12, 2026 at 05:08:02PM +0100, Mickaël Salaün wrote:
>> On Sat, Jan 10, 2026 at 03:32:55PM +0100, Günther Noack wrote:
>>> ## Alternatives and Related Work
>>>
>>> ### Alternative: Use existing LSM hooks
>>>
>>> The existing hooks security_unix_stream_connect(),
>>> security_unix_may_send() and security_socket_connect() do not give
>>> access to the resolved file system path.
>>>
>>> Resolving the file system path again within Landlock would in my
>>> understanding produce a TOCTOU race, so making the decision based on
>>> the struct sockaddr_un contents is not an option.
>>>
>>> It is tempting to use the struct path that the listening socket is
>>> bound to, which can be acquired through the existing hooks.
>>> Unfortunately, the listening socket may have been bound from within a
>>> different namespace, and it is therefore a path that can not actually
>>> be referenced by the sandboxed program at the time of constructing the
>>> Landlock policy. (More details are on the Github issue at [6] and on
>>> the LKML at [9]).
>> Please move (or duplicate) this rationale in the patch dedicated to the
>> new hook. It helps patch review (and to understand commits when already
>> merged).
> Justin, would you like to look into this?
> Please feel free to copy the wording.
No problem.
It's quite long, so would it make sense in the notes?
Instead of directly in the commit message?
>
>
>>> ### Related work: Scope Control for Pathname Unix Sockets
>>>
>>> The motivation for this patch is the same as in Tingmao Wang's patch
>>> set for "scoped" control for pathname Unix sockets [2], originally
>>> proposed in the Github feature request [5].
>>>
>>> In my reply to this patch set [3], I have discussed the differences
>>> between these two approaches. On the related discussions on Github
>>> [4] and [5], there was consensus that the scope-based control is
>>> complimentary to the file system based control, but does not replace
>>> it. Mickael's opening remark on [5] says:
>>>
>>>> This scoping would be complementary to #36 which would mainly be
>>>> about allowing a sandboxed process to connect to a more privileged
>>>> service (identified with a path).
>>> ## Open questions in V2
>>>
>>> Seeking feedback on:
>>>
>>> - Feedback on the LSM hook name would be appreciated. We realize that
>>> not all invocations of the LSM hook are related to connect(2) as the
>>> name suggests, but some also happen during sendmsg(2).
>> Renaming security_unix_path_connect() to security_unix_find() would look
>> appropriate to me wrt the caller.
> Justin, this is also on your commit. (I find security_unix_find() and
> security_unix_resolve() equally acceptable options.)
security_unix_find works for me, and seems to better match the hook
location. I'll send an updated commit.
>
>
>>> - Feedback on the structuring of the Landlock access rights, splitting
>>> them up by socket type. (Also naming; they are now consistently
>>> called "RESOLVE", but could be named "CONNECT" in the stream and
>>> seqpacket cases?)
>> I don't see use cases where differenciating the type of unix socket
>> would be useful. LANDLOCK_ACCESS_FS_RESOLVE_UNIX would look good to me.
> I did it mostly because it seemed consistent with the TCP and (soon)
> UDP controls, which are also controls specific to the socket type and
> not just the address family. But I agree that the granularity is
> likely not needed here. I can change it back for v3 and rename it to
> LANDLOCK_ACCESS_FS_RESOLVE_UNIX.
>
>
>> What would be the inverse of "resolve" (i.e. to restrict the server
>> side)? Would LANDLOCK_ACCESS_FS_MAKE_SOCK be enough?
> Yes, that would be enough. My reasoning is as follows:
>
> The server-side operation that is related to associating the service
> with a given file system name is bind(2), and that is restrictable in
> that case using LANDLOCK_ACCESS_FS_MAKE_SOCK.
>
> Also, to my delight (and other than in TCP), listening on an unbound
> socket does not work (see unix_listen() in af_unix.c):
>
> if (!READ_ONCE(u->addr))
> goto out; /* No listens on an unbound socket */
>
> (You can get it to "autobind" during an explicit bind() or a connect()
> call, but that creates an abstract UNIX address. (Documented in
> socket(7) and implemented in unix_autobind() in af_unix.c))
>
>
> –Günther
^ permalink raw reply
* Re: [PATCH] ima: Detect changes to files via kstat changes rather than i_version
From: Frederick Lawler @ 2026-01-16 21:25 UTC (permalink / raw)
To: Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn, Darrick J. Wong,
Christian Brauner, Josef Bacik, Jeff Layton
Cc: linux-kernel, linux-integrity, linux-security-module, kernel-team
In-Reply-To: <20260112-xfs-ima-fixup-v1-1-8d13b6001312@cloudflare.com>
On Mon, Jan 12, 2026 at 04:32:23PM -0600, Frederick Lawler wrote:
> Commit 1cf7e834a6fb ("xfs: switch to multigrain timestamps")
> introduced a means to track change detection for an inode
> via ctime updates, opposed to setting kstat.change_cookie when
> calling into xfs_vn_getattr().
>
> This introduced a regression because IMA caches kstat.change_cookie
> to compare against an inode's i_version directly in
> integrity_inode_attrs_changed(), and thus could be out of date
> depending on how file systems increment i_version.
>
> To address this, require integrity_inode_attrs_changed() to query
> vfs_getattr_nosec() to compare the cached version against
> kstat.change_cookie directly. This ensures that when updates occur,
> we're accessing the same changed inode version on changes, and fallback
> to compare against an artificial version generated from kstat.ctime
> via integrity_ctime_guard() when there's no detected change
> to the kstat.change_cookie.
>
> This ensures that in the absence of i_version support for file systems,
> and in the absence of a kstat.change_cookie update, we ultimately have a
> unique-enough version to compare against.
>
> The exact implementation for integrity_ctime_guard() is to ensure that
> if tv_sec or tv_nsec are zero, there's some value to store back into
> struct integrity_inode_attributes.version. This also avoids the need to
> add additional storage and comparisons.
>
> Lastly, because EVM still relies on querying and caching a backing inode's
> i_version, the integrity_inode_attrs_changed() falls back to the
> original inode.i_version != cached comparison. This maintains the
> invariant that a re-evaluation in unknown change detection circumstances
> is required.
>
> Link: https://lore.kernel.org/all/aTspr4_h9IU4EyrR@CMGLRV3
> Suggested-by: Jeff Layton <jlayton@kernel.org>
> Signed-off-by: Frederick Lawler <fred@cloudflare.com>
> ---
> We uncovered a case in kernels >= 6.13 where XFS is no longer updating
> struct kstat.change_cookie on i_op getattr() access calls. Instead, XFS is
> using multigrain ctime (as well as other file systems) for
> change detection in commit 1cf7e834a6fb ("xfs: switch to
> multigrain timestamps").
>
> Because file systems may implement i_version as they see fit, IMA
> caching may be behind as well as file systems that don't support/export
> i_version. Thus we're proposing to compare against the kstat.change_cookie
> directly to the cached version, and fall back to a ctime guard when
> that's not updated.
>
> EVM is largely left alone since there's no trivial way to query a file
> directly in the LSM call paths to obtain kstat.change_cookie &
> kstat.ctime to cache. Thus retains accessing i_version directly.
>
> Regression tests will be added to the Linux Test Project instead of
> selftest to help catch future file system changes that may impact
> future evaluation of IMA.
>
> I'd like this to be backported to at least 6.18 if possible.
>
> Below is a simplified test that demonstrates the issue:
>
> _fragment.config_
> CONFIG_XFS_FS=y
> CONFIG_OVERLAY_FS=y
> CONFIG_IMA=y
> CONFIG_IMA_WRITE_POLICY=y
> CONFIG_IMA_READ_POLICY=y
>
> _./test.sh_
>
> IMA_POLICY="/sys/kernel/security/ima/policy"
> TEST_BIN="/bin/date"
> MNT_BASE="/tmp/ima_test_root"
>
> mkdir -p "$MNT_BASE"
> mount -t tmpfs tmpfs "$MNT_BASE"
> mkdir -p "$MNT_BASE"/{xfs_disk,upper,work,ovl}
>
> dd if=/dev/zero of="$MNT_BASE/xfs.img" bs=1M count=300
> mkfs.xfs -q "$MNT_BASE/xfs.img"
> mount "$MNT_BASE/xfs.img" "$MNT_BASE/xfs_disk"
> cp "$TEST_BIN" "$MNT_BASE/xfs_disk/test_prog"
>
> mount -t overlay overlay -o \
> "lowerdir=$MNT_BASE/xfs_disk,upperdir=$MNT_BASE/upper,workdir=$MNT_BASE/work" \
> "$MNT_BASE/ovl"
>
> echo "audit func=BPRM_CHECK uid=$(id -u nobody)" > "$IMA_POLICY"
>
> target_prog="$MNT_BASE/ovl/test_prog"
> setpriv --reuid nobody "$target_prog"
> setpriv --reuid nobody "$target_prog"
> setpriv --reuid nobody "$target_prog"
>
> audit_count=$(dmesg | grep -c "file=\"$target_prog\"")
>
> if [[ "$audit_count" -eq 1 ]]; then
> echo "PASS: Found exactly 1 audit event."
> else
> echo "FAIL: Expected 1 audit event, but found $audit_count."
> exit 1
> fi
> ---
> Changes since RFC:
> - Remove calls to I_IS_VERSION()
> - Function documentation/comments
> - Abide IMA/EVM change detection fallback invariants
> - Combined ctime guard into version for attributes struct
> - Link to RFC: https://lore.kernel.org/r/20251229-xfs-ima-fixup-v1-1-6a717c939f7c@cloudflare.com
> ---
> include/linux/integrity.h | 42 +++++++++++++++++++++++++++++++++++----
> security/integrity/evm/evm_main.c | 5 ++---
> security/integrity/ima/ima_api.c | 11 +++++++---
> security/integrity/ima/ima_main.c | 15 +++++---------
> 4 files changed, 53 insertions(+), 20 deletions(-)
>
> diff --git a/include/linux/integrity.h b/include/linux/integrity.h
> index f5842372359be5341b6870a43b92e695e8fc78af..5eca8aa2769f9238c68bb40885ecc46910524f11 100644
> --- a/include/linux/integrity.h
> +++ b/include/linux/integrity.h
> @@ -9,6 +9,7 @@
>
> #include <linux/fs.h>
> #include <linux/iversion.h>
> +#include <linux/kernel.h>
>
> enum integrity_status {
> INTEGRITY_PASS = 0,
> @@ -36,6 +37,14 @@ struct integrity_inode_attributes {
> dev_t dev;
> };
>
> +/*
> + * Wrapper to generate an artificial version for a file.
> + */
> +static inline u64 integrity_ctime_guard(struct kstat stat)
> +{
> + return stat.ctime.tv_sec ^ stat.ctime.tv_nsec;
> +}
> +
> /*
> * On stacked filesystems the i_version alone is not enough to detect file data
> * or metadata change. Additional metadata is required.
> @@ -51,14 +60,39 @@ integrity_inode_attrs_store(struct integrity_inode_attributes *attrs,
>
> /*
> * On stacked filesystems detect whether the inode or its content has changed.
> + *
> + * Must be called in process context.
> */
> static inline bool
> integrity_inode_attrs_changed(const struct integrity_inode_attributes *attrs,
> - const struct inode *inode)
> + struct file *file, struct inode *inode)
> {
> - return (inode->i_sb->s_dev != attrs->dev ||
> - inode->i_ino != attrs->ino ||
> - !inode_eq_iversion(inode, attrs->version));
> + struct kstat stat;
> +
> + might_sleep();
> +
> + if (inode->i_sb->s_dev != attrs->dev || inode->i_ino != attrs->ino)
> + return true;
> +
> + /*
> + * EVM currently relies on backing inode i_version. While IS_I_VERSION
> + * is not a good indicator of i_version support, this still retains
> + * the logic such that a re-evaluation should still occur for EVM, and
> + * only for IMA if vfs_getattr_nosec() fails.
> + */
> + if (!file || vfs_getattr_nosec(&file->f_path, &stat,
> + STATX_CHANGE_COOKIE | STATX_CTIME,
> + AT_STATX_SYNC_AS_STAT))
> + return !IS_I_VERSION(inode) ||
> + !inode_eq_iversion(inode, attrs->version);
> +
> + if (stat.result_mask & STATX_CHANGE_COOKIE)
> + return stat.change_cookie != attrs->version;
> +
> + if (stat.result_mask & STATX_CTIME)
> + return integrity_ctime_guard(stat) != attrs->version;
> +
> + return true;
> }
>
>
> diff --git a/security/integrity/evm/evm_main.c b/security/integrity/evm/evm_main.c
> index 73d500a375cb37a54f295b0e1e93fd6e5d9ecddc..6a4e0e246005246d5700b1db590c1759242b9cb6 100644
> --- a/security/integrity/evm/evm_main.c
> +++ b/security/integrity/evm/evm_main.c
> @@ -752,9 +752,8 @@ bool evm_metadata_changed(struct inode *inode, struct inode *metadata_inode)
> bool ret = false;
>
> if (iint) {
> - ret = (!IS_I_VERSION(metadata_inode) ||
> - integrity_inode_attrs_changed(&iint->metadata_inode,
> - metadata_inode));
> + ret = integrity_inode_attrs_changed(&iint->metadata_inode,
> + NULL, metadata_inode);
> if (ret)
> iint->evm_status = INTEGRITY_UNKNOWN;
> }
> diff --git a/security/integrity/ima/ima_api.c b/security/integrity/ima/ima_api.c
> index c35ea613c9f8d404ba4886e3b736c3bab29d1668..8096986f3689781d3cdf6595f330033782f9cc45 100644
> --- a/security/integrity/ima/ima_api.c
> +++ b/security/integrity/ima/ima_api.c
> @@ -272,10 +272,15 @@ int ima_collect_measurement(struct ima_iint_cache *iint, struct file *file,
> * to an initial measurement/appraisal/audit, but was modified to
> * assume the file changed.
> */
> - result = vfs_getattr_nosec(&file->f_path, &stat, STATX_CHANGE_COOKIE,
> + result = vfs_getattr_nosec(&file->f_path, &stat,
> + STATX_CHANGE_COOKIE | STATX_CTIME,
> AT_STATX_SYNC_AS_STAT);
> - if (!result && (stat.result_mask & STATX_CHANGE_COOKIE))
> - i_version = stat.change_cookie;
> + if (!result) {
> + if (stat.result_mask & STATX_CHANGE_COOKIE)
> + i_version = stat.change_cookie;
> + else if (stat.result_mask & STATX_CTIME)
> + i_version = integrity_ctime_guard(stat);
> + }
> hash.hdr.algo = algo;
> hash.hdr.length = hash_digest_size[algo];
>
> diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> index 5770cf691912aa912fc65280c59f5baac35dd725..3a4c32e254f925bba85cb91b63744ac142b3b049 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -22,6 +22,7 @@
> #include <linux/mount.h>
> #include <linux/mman.h>
> #include <linux/slab.h>
> +#include <linux/stat.h>
> #include <linux/xattr.h>
> #include <linux/ima.h>
> #include <linux/fs.h>
> @@ -191,18 +192,13 @@ static void ima_check_last_writer(struct ima_iint_cache *iint,
>
> mutex_lock(&iint->mutex);
> if (atomic_read(&inode->i_writecount) == 1) {
> - struct kstat stat;
> -
> clear_bit(IMA_EMITTED_OPENWRITERS, &iint->atomic_flags);
>
> update = test_and_clear_bit(IMA_UPDATE_XATTR,
> &iint->atomic_flags);
> if ((iint->flags & IMA_NEW_FILE) ||
> - vfs_getattr_nosec(&file->f_path, &stat,
> - STATX_CHANGE_COOKIE,
> - AT_STATX_SYNC_AS_STAT) ||
> - !(stat.result_mask & STATX_CHANGE_COOKIE) ||
> - stat.change_cookie != iint->real_inode.version) {
> + integrity_inode_attrs_changed(&iint->real_inode, file,
> + inode)) {
I'm working through my tests, and I don't think I can get away with this
change. The check for the inode->i_ino != attr->ino may result in a
re-evaluation because we're not updating the attr->ino while collecting
measurement on non-stacked file systems checks. Same for attr->dev not
updating.
I'll put this back in the next patch version, and still check ctime here
similar to the RFC version.
> iint->flags &= ~(IMA_DONE_MASK | IMA_NEW_FILE);
> iint->measured_pcrs = 0;
> if (update)
> @@ -328,9 +324,8 @@ static int process_measurement(struct file *file, const struct cred *cred,
> real_inode = d_real_inode(file_dentry(file));
> if (real_inode != inode &&
> (action & IMA_DO_MASK) && (iint->flags & IMA_DONE_MASK)) {
> - if (!IS_I_VERSION(real_inode) ||
> - integrity_inode_attrs_changed(&iint->real_inode,
> - real_inode)) {
> + if (integrity_inode_attrs_changed(&iint->real_inode,
> + file, real_inode)) {
> iint->flags &= ~IMA_DONE_MASK;
> iint->measured_pcrs = 0;
> }
>
> ---
> base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> change-id: 20251212-xfs-ima-fixup-931780a62c2c
>
> Best regards,
> --
> Frederick Lawler <fred@cloudflare.com>
>
^ permalink raw reply
* Re: [PATCH 1/3] integrity: Make arch_ima_get_secureboot integrity-wide
From: Ard Biesheuvel @ 2026-01-16 17:27 UTC (permalink / raw)
To: Mimi Zohar
Cc: Coiby Xu, linux-integrity, Heiko Carstens, Roberto Sassu,
Catalin Marinas, Will Deacon, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
H. Peter Anvin, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn, Jarkko Sakkinen,
moderated list:ARM64 PORT (AARCH64 ARCHITECTURE), open list,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:S390 ARCHITECTURE,
open list:EXTENSIBLE FIRMWARE INTERFACE (EFI),
open list:SECURITY SUBSYSTEM, open list:KEYS/KEYRINGS_INTEGRITY
In-Reply-To: <97b69bc79a5d9246f7a399510908c7b95b2e95e7.camel@linux.ibm.com>
On Fri, 16 Jan 2026 at 17:39, Mimi Zohar <zohar@linux.ibm.com> wrote:
>
> On Fri, 2026-01-16 at 14:18 +0100, Ard Biesheuvel wrote:
> > On Fri, 16 Jan 2026 at 14:11, Mimi Zohar <zohar@linux.ibm.com> wrote:
> > >
> > > On Fri, 2026-01-16 at 10:41 +0100, Ard Biesheuvel wrote:
> > > > On Thu, 15 Jan 2026 at 01:43, Coiby Xu <coxu@redhat.com> wrote:
> > > > >
> > > > > EVM and other LSMs need the ability to query the secure boot status of
> > > > > the system, without directly calling the IMA arch_ima_get_secureboot
> > > > > function. Refactor the secure boot status check into a general,
> > > > > integrity-wide function named arch_integrity_get_secureboot.
> > > > >
> > > > > Define a new Kconfig option CONFIG_INTEGRITY_SECURE_BOOT, which is
> > > > > automatically configured by the supported architectures. The existing
> > > > > IMA_SECURE_AND_OR_TRUSTED_BOOT Kconfig loads the architecture specific
> > > > > IMA policy based on the refactored secure boot status code.
> > > > >
> > > > > Reported-and-suggested-by: Mimi Zohar <zohar@linux.ibm.com>
> > > > > Suggested-by: Roberto Sassu <roberto.sassu@huaweicloud.com>
> > > > > Signed-off-by: Coiby Xu <coxu@redhat.com>
> > > > > ---
> > > > > arch/arm64/Kconfig | 1 +
> > > > > arch/powerpc/Kconfig | 1 +
> > > > > arch/powerpc/kernel/Makefile | 2 +-
> > > > > arch/powerpc/kernel/ima_arch.c | 5 --
> > > > > arch/powerpc/kernel/integrity_sb_arch.c | 13 +++++
> > > > > arch/s390/Kconfig | 1 +
> > > > > arch/s390/kernel/Makefile | 1 +
> > > > > arch/s390/kernel/ima_arch.c | 6 --
> > > > > arch/s390/kernel/integrity_sb_arch.c | 9 +++
> > > > > arch/x86/Kconfig | 1 +
> > > > > arch/x86/include/asm/efi.h | 4 +-
> > > > > arch/x86/platform/efi/efi.c | 2 +-
> > > > > include/linux/ima.h | 7 +--
> > > > > include/linux/integrity.h | 8 +++
> > > > > security/integrity/Kconfig | 6 ++
> > > > > security/integrity/Makefile | 3 +
> > > > > security/integrity/efi_secureboot.c | 56 +++++++++++++++++++
> > > > > security/integrity/ima/ima_appraise.c | 2 +-
> > > > > security/integrity/ima/ima_efi.c | 47 +---------------
> > > > > security/integrity/ima/ima_main.c | 4 +-
> > > > > security/integrity/platform_certs/load_uefi.c | 2 +-
> > > > > 21 files changed, 111 insertions(+), 70 deletions(-)
> > > > > create mode 100644 arch/powerpc/kernel/integrity_sb_arch.c
> > > > > create mode 100644 arch/s390/kernel/integrity_sb_arch.c
> > > > > create mode 100644 security/integrity/efi_secureboot.c
> > > > >
> > > > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > > > > index 93173f0a09c7..4c265b7386bb 100644
> > > > > --- a/arch/arm64/Kconfig
> > > > > +++ b/arch/arm64/Kconfig
> > > > > @@ -2427,6 +2427,7 @@ config EFI
> > > > > select EFI_STUB
> > > > > select EFI_GENERIC_STUB
> > > > > imply IMA_SECURE_AND_OR_TRUSTED_BOOT
> > > > > + imply INTEGRITY_SECURE_BOOT
> > > >
> > > > This allows both to be en/disabled individually, which I don't think
> > > > is what we want. It also results in more churn across the
> > > > arch-specific Kconfigs than needed.
> > > >
> > > > Wouldn't it be better if IMA_SECURE_AND_OR_TRUSTED_BOOT 'select'ed
> > > > INTEGRITY_SECURE_BOOT in its Kconfig definition?
> > >
> > > As much as possible, EVM (and other LSMs) shouldn't be dependent on another LSM,
> > > in this case IMA, being configured.
> >
> > Sure, but that is not my point.
> >
> > This arrangement allows for IMA_SECURE_AND_OR_TRUSTED_BOOT to be
> > enabled without INTEGRITY_SECURE_BOOT, resulting in the stub
> > implementation of arch_integrity_get_secureboot() being used, which
> > always returns false.
>
> I understand your concern, but instead of "select"ing INTEGRITY_SECURE_BOOT from
> IMA_SECURE_AND_OR_TRUSTED_BOOT, how making IMA_SECURE_AND_OR_TRUSTED_BOOT
> dependent on both IMA_ARCH_POLICY and INTEGRITY_SECURE_BOOT.
>
Given that INTEGRITY_SECURE_BOOT has no dependencies of its own,
afaict, selecting it is the least disruptive option, as otherwise,
existing configs will disable IMA_SECURE_AND_OR_TRUSTED_BOOT as the
kernel is being upgraded. But conceptually, I agree that they are
equivalent.
> Including the "imply INTEGRITY_SECURE_BOOT" here in the arch Kconfig allows EVM
> to query the secure boot state without relying on IMA_SECURE_AND_OR_TRUSTED_BOOT
> being configured.
Yes, I understand that this is the whole point of the exercise. But
'imply' should be used with care, and in this case, implying both from
CONFIG_EFI really makes little sense. INTEGRITY_SECURE_BOOT should be
selected by options that need the functionality, not 'implied' by
options that might provide it.
^ permalink raw reply
* Re: [PATCH 1/3] integrity: Make arch_ima_get_secureboot integrity-wide
From: Mimi Zohar @ 2026-01-16 16:38 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Coiby Xu, linux-integrity, Heiko Carstens, Roberto Sassu,
Catalin Marinas, Will Deacon, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
H. Peter Anvin, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn, Jarkko Sakkinen,
moderated list:ARM64 PORT (AARCH64 ARCHITECTURE), open list,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:S390 ARCHITECTURE,
open list:EXTENSIBLE FIRMWARE INTERFACE (EFI),
open list:SECURITY SUBSYSTEM, open list:KEYS/KEYRINGS_INTEGRITY
In-Reply-To: <CAMj1kXHsJNZoUEnbD1y=v4Ftuv9d2c08VckRV7ru4k4P83vZbQ@mail.gmail.com>
On Fri, 2026-01-16 at 14:18 +0100, Ard Biesheuvel wrote:
> On Fri, 16 Jan 2026 at 14:11, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >
> > On Fri, 2026-01-16 at 10:41 +0100, Ard Biesheuvel wrote:
> > > On Thu, 15 Jan 2026 at 01:43, Coiby Xu <coxu@redhat.com> wrote:
> > > >
> > > > EVM and other LSMs need the ability to query the secure boot status of
> > > > the system, without directly calling the IMA arch_ima_get_secureboot
> > > > function. Refactor the secure boot status check into a general,
> > > > integrity-wide function named arch_integrity_get_secureboot.
> > > >
> > > > Define a new Kconfig option CONFIG_INTEGRITY_SECURE_BOOT, which is
> > > > automatically configured by the supported architectures. The existing
> > > > IMA_SECURE_AND_OR_TRUSTED_BOOT Kconfig loads the architecture specific
> > > > IMA policy based on the refactored secure boot status code.
> > > >
> > > > Reported-and-suggested-by: Mimi Zohar <zohar@linux.ibm.com>
> > > > Suggested-by: Roberto Sassu <roberto.sassu@huaweicloud.com>
> > > > Signed-off-by: Coiby Xu <coxu@redhat.com>
> > > > ---
> > > > arch/arm64/Kconfig | 1 +
> > > > arch/powerpc/Kconfig | 1 +
> > > > arch/powerpc/kernel/Makefile | 2 +-
> > > > arch/powerpc/kernel/ima_arch.c | 5 --
> > > > arch/powerpc/kernel/integrity_sb_arch.c | 13 +++++
> > > > arch/s390/Kconfig | 1 +
> > > > arch/s390/kernel/Makefile | 1 +
> > > > arch/s390/kernel/ima_arch.c | 6 --
> > > > arch/s390/kernel/integrity_sb_arch.c | 9 +++
> > > > arch/x86/Kconfig | 1 +
> > > > arch/x86/include/asm/efi.h | 4 +-
> > > > arch/x86/platform/efi/efi.c | 2 +-
> > > > include/linux/ima.h | 7 +--
> > > > include/linux/integrity.h | 8 +++
> > > > security/integrity/Kconfig | 6 ++
> > > > security/integrity/Makefile | 3 +
> > > > security/integrity/efi_secureboot.c | 56 +++++++++++++++++++
> > > > security/integrity/ima/ima_appraise.c | 2 +-
> > > > security/integrity/ima/ima_efi.c | 47 +---------------
> > > > security/integrity/ima/ima_main.c | 4 +-
> > > > security/integrity/platform_certs/load_uefi.c | 2 +-
> > > > 21 files changed, 111 insertions(+), 70 deletions(-)
> > > > create mode 100644 arch/powerpc/kernel/integrity_sb_arch.c
> > > > create mode 100644 arch/s390/kernel/integrity_sb_arch.c
> > > > create mode 100644 security/integrity/efi_secureboot.c
> > > >
> > > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > > > index 93173f0a09c7..4c265b7386bb 100644
> > > > --- a/arch/arm64/Kconfig
> > > > +++ b/arch/arm64/Kconfig
> > > > @@ -2427,6 +2427,7 @@ config EFI
> > > > select EFI_STUB
> > > > select EFI_GENERIC_STUB
> > > > imply IMA_SECURE_AND_OR_TRUSTED_BOOT
> > > > + imply INTEGRITY_SECURE_BOOT
> > >
> > > This allows both to be en/disabled individually, which I don't think
> > > is what we want. It also results in more churn across the
> > > arch-specific Kconfigs than needed.
> > >
> > > Wouldn't it be better if IMA_SECURE_AND_OR_TRUSTED_BOOT 'select'ed
> > > INTEGRITY_SECURE_BOOT in its Kconfig definition?
> >
> > As much as possible, EVM (and other LSMs) shouldn't be dependent on another LSM,
> > in this case IMA, being configured.
>
> Sure, but that is not my point.
>
> This arrangement allows for IMA_SECURE_AND_OR_TRUSTED_BOOT to be
> enabled without INTEGRITY_SECURE_BOOT, resulting in the stub
> implementation of arch_integrity_get_secureboot() being used, which
> always returns false.
I understand your concern, but instead of "select"ing INTEGRITY_SECURE_BOOT from
IMA_SECURE_AND_OR_TRUSTED_BOOT, how making IMA_SECURE_AND_OR_TRUSTED_BOOT
dependent on both IMA_ARCH_POLICY and INTEGRITY_SECURE_BOOT.
Including the "imply INTEGRITY_SECURE_BOOT" here in the arch Kconfig allows EVM
to query the secure boot state without relying on IMA_SECURE_AND_OR_TRUSTED_BOOT
being configured.
^ permalink raw reply
* Re: [GIT PULL] Landlock fix for v6.19-rc6
From: Mickaël Salaün @ 2026-01-16 14:18 UTC (permalink / raw)
To: Linus Torvalds
Cc: Günther Noack, Matthieu Buffet, Tingmao Wang, linux-kernel,
linux-security-module
In-Reply-To: <CAHk-=wgPRijTr7fZQNs9pxbhRLBVQGdE7ceZDwQFP53MXjRBxg@mail.gmail.com>
On Thu, Jan 15, 2026 at 03:09:34PM -0800, Linus Torvalds wrote:
> On Thu, 15 Jan 2026 at 13:47, Mickaël Salaün <mic@digikod.net> wrote:
> >
> > This PR fixes TCP handling, tests, documentation, non-audit elided code,
> > and minor cosmetic changes.
>
> This seems significantly bigger than what you sent for the whole merge
> window for the Landlock code.
>
> The merge window pull was - ignoring tests - 4 files changed, 59
> insertions(+), 17 deletions(-).
>
> I want more explanations for why I'm suddenly getting more alleged
> fixes than I got any development and why this shouldn't wait until the
> next merge window.
>
> Because honestly, this just all seems out of place.
There are indeed relatively more line changes because the related
commits are fixes for different kernel versions, not specifically v6.19
but also v6.15 (type issue), v6.7 (TCP fix), and it required to move a
lot of lines (including a lot of comments) for a theoretically small
fix. In fact, the last merge window pull was mostly about fixes too
(which were on time for the merge window, but otherwise I would have
sent them as this one).
The other commits are documentation/comment fixes (including another
chunk of moved lines, which appears as kernel code diff), tests fixes or
minor cleanup. I can postpone these commits but because they don't
directly impact the kernel, I wanted to group all fixes and minor
non-kernel changes together to have a clean PR for the next merge
window. Please let me know what you prefer.
Mickaël
^ permalink raw reply
* Re: [PATCH 1/3] integrity: Make arch_ima_get_secureboot integrity-wide
From: Ard Biesheuvel @ 2026-01-16 13:18 UTC (permalink / raw)
To: Mimi Zohar
Cc: Coiby Xu, linux-integrity, Heiko Carstens, Roberto Sassu,
Catalin Marinas, Will Deacon, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
H. Peter Anvin, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn, Jarkko Sakkinen,
moderated list:ARM64 PORT (AARCH64 ARCHITECTURE), open list,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:S390 ARCHITECTURE,
open list:EXTENSIBLE FIRMWARE INTERFACE (EFI),
open list:SECURITY SUBSYSTEM, open list:KEYS/KEYRINGS_INTEGRITY
In-Reply-To: <8bfa859ed3a4f1cf0db0ab64d8c1c3b24684582a.camel@linux.ibm.com>
On Fri, 16 Jan 2026 at 14:11, Mimi Zohar <zohar@linux.ibm.com> wrote:
>
> On Fri, 2026-01-16 at 10:41 +0100, Ard Biesheuvel wrote:
> > On Thu, 15 Jan 2026 at 01:43, Coiby Xu <coxu@redhat.com> wrote:
> > >
> > > EVM and other LSMs need the ability to query the secure boot status of
> > > the system, without directly calling the IMA arch_ima_get_secureboot
> > > function. Refactor the secure boot status check into a general,
> > > integrity-wide function named arch_integrity_get_secureboot.
> > >
> > > Define a new Kconfig option CONFIG_INTEGRITY_SECURE_BOOT, which is
> > > automatically configured by the supported architectures. The existing
> > > IMA_SECURE_AND_OR_TRUSTED_BOOT Kconfig loads the architecture specific
> > > IMA policy based on the refactored secure boot status code.
> > >
> > > Reported-and-suggested-by: Mimi Zohar <zohar@linux.ibm.com>
> > > Suggested-by: Roberto Sassu <roberto.sassu@huaweicloud.com>
> > > Signed-off-by: Coiby Xu <coxu@redhat.com>
> > > ---
> > > arch/arm64/Kconfig | 1 +
> > > arch/powerpc/Kconfig | 1 +
> > > arch/powerpc/kernel/Makefile | 2 +-
> > > arch/powerpc/kernel/ima_arch.c | 5 --
> > > arch/powerpc/kernel/integrity_sb_arch.c | 13 +++++
> > > arch/s390/Kconfig | 1 +
> > > arch/s390/kernel/Makefile | 1 +
> > > arch/s390/kernel/ima_arch.c | 6 --
> > > arch/s390/kernel/integrity_sb_arch.c | 9 +++
> > > arch/x86/Kconfig | 1 +
> > > arch/x86/include/asm/efi.h | 4 +-
> > > arch/x86/platform/efi/efi.c | 2 +-
> > > include/linux/ima.h | 7 +--
> > > include/linux/integrity.h | 8 +++
> > > security/integrity/Kconfig | 6 ++
> > > security/integrity/Makefile | 3 +
> > > security/integrity/efi_secureboot.c | 56 +++++++++++++++++++
> > > security/integrity/ima/ima_appraise.c | 2 +-
> > > security/integrity/ima/ima_efi.c | 47 +---------------
> > > security/integrity/ima/ima_main.c | 4 +-
> > > security/integrity/platform_certs/load_uefi.c | 2 +-
> > > 21 files changed, 111 insertions(+), 70 deletions(-)
> > > create mode 100644 arch/powerpc/kernel/integrity_sb_arch.c
> > > create mode 100644 arch/s390/kernel/integrity_sb_arch.c
> > > create mode 100644 security/integrity/efi_secureboot.c
> > >
> > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > > index 93173f0a09c7..4c265b7386bb 100644
> > > --- a/arch/arm64/Kconfig
> > > +++ b/arch/arm64/Kconfig
> > > @@ -2427,6 +2427,7 @@ config EFI
> > > select EFI_STUB
> > > select EFI_GENERIC_STUB
> > > imply IMA_SECURE_AND_OR_TRUSTED_BOOT
> > > + imply INTEGRITY_SECURE_BOOT
> >
> > This allows both to be en/disabled individually, which I don't think
> > is what we want. It also results in more churn across the
> > arch-specific Kconfigs than needed.
> >
> > Wouldn't it be better if IMA_SECURE_AND_OR_TRUSTED_BOOT 'select'ed
> > INTEGRITY_SECURE_BOOT in its Kconfig definition?
>
> As much as possible, EVM (and other LSMs) shouldn't be dependent on another LSM,
> in this case IMA, being configured.
Sure, but that is not my point.
This arrangement allows for IMA_SECURE_AND_OR_TRUSTED_BOOT to be
enabled without INTEGRITY_SECURE_BOOT, resulting in the stub
implementation of arch_integrity_get_secureboot() being used, which
always returns false.
^ permalink raw reply
* Re: [PATCH 1/3] integrity: Make arch_ima_get_secureboot integrity-wide
From: Mimi Zohar @ 2026-01-16 13:11 UTC (permalink / raw)
To: Ard Biesheuvel, Coiby Xu
Cc: linux-integrity, Heiko Carstens, Roberto Sassu, Catalin Marinas,
Will Deacon, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), H. Peter Anvin,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Paul Moore,
James Morris, Serge E. Hallyn, Jarkko Sakkinen,
moderated list:ARM64 PORT (AARCH64 ARCHITECTURE), open list,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:S390 ARCHITECTURE,
open list:EXTENSIBLE FIRMWARE INTERFACE (EFI),
open list:SECURITY SUBSYSTEM, open list:KEYS/KEYRINGS_INTEGRITY
In-Reply-To: <CAMj1kXFXNo1-pMbo-VZrjQ3TYe1tufebrLr_avL12A0nHMSGnA@mail.gmail.com>
On Fri, 2026-01-16 at 10:41 +0100, Ard Biesheuvel wrote:
> On Thu, 15 Jan 2026 at 01:43, Coiby Xu <coxu@redhat.com> wrote:
> >
> > EVM and other LSMs need the ability to query the secure boot status of
> > the system, without directly calling the IMA arch_ima_get_secureboot
> > function. Refactor the secure boot status check into a general,
> > integrity-wide function named arch_integrity_get_secureboot.
> >
> > Define a new Kconfig option CONFIG_INTEGRITY_SECURE_BOOT, which is
> > automatically configured by the supported architectures. The existing
> > IMA_SECURE_AND_OR_TRUSTED_BOOT Kconfig loads the architecture specific
> > IMA policy based on the refactored secure boot status code.
> >
> > Reported-and-suggested-by: Mimi Zohar <zohar@linux.ibm.com>
> > Suggested-by: Roberto Sassu <roberto.sassu@huaweicloud.com>
> > Signed-off-by: Coiby Xu <coxu@redhat.com>
> > ---
> > arch/arm64/Kconfig | 1 +
> > arch/powerpc/Kconfig | 1 +
> > arch/powerpc/kernel/Makefile | 2 +-
> > arch/powerpc/kernel/ima_arch.c | 5 --
> > arch/powerpc/kernel/integrity_sb_arch.c | 13 +++++
> > arch/s390/Kconfig | 1 +
> > arch/s390/kernel/Makefile | 1 +
> > arch/s390/kernel/ima_arch.c | 6 --
> > arch/s390/kernel/integrity_sb_arch.c | 9 +++
> > arch/x86/Kconfig | 1 +
> > arch/x86/include/asm/efi.h | 4 +-
> > arch/x86/platform/efi/efi.c | 2 +-
> > include/linux/ima.h | 7 +--
> > include/linux/integrity.h | 8 +++
> > security/integrity/Kconfig | 6 ++
> > security/integrity/Makefile | 3 +
> > security/integrity/efi_secureboot.c | 56 +++++++++++++++++++
> > security/integrity/ima/ima_appraise.c | 2 +-
> > security/integrity/ima/ima_efi.c | 47 +---------------
> > security/integrity/ima/ima_main.c | 4 +-
> > security/integrity/platform_certs/load_uefi.c | 2 +-
> > 21 files changed, 111 insertions(+), 70 deletions(-)
> > create mode 100644 arch/powerpc/kernel/integrity_sb_arch.c
> > create mode 100644 arch/s390/kernel/integrity_sb_arch.c
> > create mode 100644 security/integrity/efi_secureboot.c
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 93173f0a09c7..4c265b7386bb 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -2427,6 +2427,7 @@ config EFI
> > select EFI_STUB
> > select EFI_GENERIC_STUB
> > imply IMA_SECURE_AND_OR_TRUSTED_BOOT
> > + imply INTEGRITY_SECURE_BOOT
>
> This allows both to be en/disabled individually, which I don't think
> is what we want. It also results in more churn across the
> arch-specific Kconfigs than needed.
>
> Wouldn't it be better if IMA_SECURE_AND_OR_TRUSTED_BOOT 'select'ed
> INTEGRITY_SECURE_BOOT in its Kconfig definition?
As much as possible, EVM (and other LSMs) shouldn't be dependent on another LSM,
in this case IMA, being configured.
^ permalink raw reply
* Re: [PATCH 2/3] evm: Don't enable fix mode when secure boot is enabled
From: Roberto Sassu @ 2026-01-16 12:06 UTC (permalink / raw)
To: Mimi Zohar, Coiby Xu, linux-integrity
Cc: Heiko Carstens, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn,
open list:SECURITY SUBSYSTEM, open list
In-Reply-To: <522f60ac43b8757c0d7df5df0239190e49f577a8.camel@linux.ibm.com>
On Thu, 2026-01-15 at 13:15 -0500, Mimi Zohar wrote:
> On Thu, 2026-01-15 at 08:43 +0800, Coiby Xu wrote:
> > Similar to IMA fix mode, forbid EVM fix mode when secure boot is
> > enabled.
> >
> > Reported-and-suggested-by: Mimi Zohar <zohar@linux.ibm.com>
> > Suggested-by: Roberto Sassu <roberto.sassu@huaweicloud.com>
Ah, if possible, could you please change the email to
roberto.sassu@huawei.com?
Thanks
Roberto
> > Signed-off-by: Coiby Xu <coxu@redhat.com>
>
> Thanks, Coiby!
>
> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH 1/3] integrity: Make arch_ima_get_secureboot integrity-wide
From: Ard Biesheuvel @ 2026-01-16 9:41 UTC (permalink / raw)
To: Coiby Xu
Cc: linux-integrity, Heiko Carstens, Mimi Zohar, Roberto Sassu,
Catalin Marinas, Will Deacon, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
H. Peter Anvin, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn, Jarkko Sakkinen,
moderated list:ARM64 PORT (AARCH64 ARCHITECTURE), open list,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:S390 ARCHITECTURE,
open list:EXTENSIBLE FIRMWARE INTERFACE (EFI),
open list:SECURITY SUBSYSTEM, open list:KEYS/KEYRINGS_INTEGRITY
In-Reply-To: <20260115004328.194142-2-coxu@redhat.com>
On Thu, 15 Jan 2026 at 01:43, Coiby Xu <coxu@redhat.com> wrote:
>
> EVM and other LSMs need the ability to query the secure boot status of
> the system, without directly calling the IMA arch_ima_get_secureboot
> function. Refactor the secure boot status check into a general,
> integrity-wide function named arch_integrity_get_secureboot.
>
> Define a new Kconfig option CONFIG_INTEGRITY_SECURE_BOOT, which is
> automatically configured by the supported architectures. The existing
> IMA_SECURE_AND_OR_TRUSTED_BOOT Kconfig loads the architecture specific
> IMA policy based on the refactored secure boot status code.
>
> Reported-and-suggested-by: Mimi Zohar <zohar@linux.ibm.com>
> Suggested-by: Roberto Sassu <roberto.sassu@huaweicloud.com>
> Signed-off-by: Coiby Xu <coxu@redhat.com>
> ---
> arch/arm64/Kconfig | 1 +
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/kernel/Makefile | 2 +-
> arch/powerpc/kernel/ima_arch.c | 5 --
> arch/powerpc/kernel/integrity_sb_arch.c | 13 +++++
> arch/s390/Kconfig | 1 +
> arch/s390/kernel/Makefile | 1 +
> arch/s390/kernel/ima_arch.c | 6 --
> arch/s390/kernel/integrity_sb_arch.c | 9 +++
> arch/x86/Kconfig | 1 +
> arch/x86/include/asm/efi.h | 4 +-
> arch/x86/platform/efi/efi.c | 2 +-
> include/linux/ima.h | 7 +--
> include/linux/integrity.h | 8 +++
> security/integrity/Kconfig | 6 ++
> security/integrity/Makefile | 3 +
> security/integrity/efi_secureboot.c | 56 +++++++++++++++++++
> security/integrity/ima/ima_appraise.c | 2 +-
> security/integrity/ima/ima_efi.c | 47 +---------------
> security/integrity/ima/ima_main.c | 4 +-
> security/integrity/platform_certs/load_uefi.c | 2 +-
> 21 files changed, 111 insertions(+), 70 deletions(-)
> create mode 100644 arch/powerpc/kernel/integrity_sb_arch.c
> create mode 100644 arch/s390/kernel/integrity_sb_arch.c
> create mode 100644 security/integrity/efi_secureboot.c
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 93173f0a09c7..4c265b7386bb 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -2427,6 +2427,7 @@ config EFI
> select EFI_STUB
> select EFI_GENERIC_STUB
> imply IMA_SECURE_AND_OR_TRUSTED_BOOT
> + imply INTEGRITY_SECURE_BOOT
This allows both to be en/disabled individually, which I don't think
is what we want. It also results in more churn across the
arch-specific Kconfigs than needed.
Wouldn't it be better if IMA_SECURE_AND_OR_TRUSTED_BOOT 'select'ed
INTEGRITY_SECURE_BOOT in its Kconfig definition?
^ permalink raw reply
* Re: [GIT PULL] Landlock fix for v6.19-rc6
From: Linus Torvalds @ 2026-01-15 23:09 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Günther Noack, Matthieu Buffet, Tingmao Wang, linux-kernel,
linux-security-module
In-Reply-To: <20260115214740.803611-1-mic@digikod.net>
On Thu, 15 Jan 2026 at 13:47, Mickaël Salaün <mic@digikod.net> wrote:
>
> This PR fixes TCP handling, tests, documentation, non-audit elided code,
> and minor cosmetic changes.
This seems significantly bigger than what you sent for the whole merge
window for the Landlock code.
The merge window pull was - ignoring tests - 4 files changed, 59
insertions(+), 17 deletions(-).
I want more explanations for why I'm suddenly getting more alleged
fixes than I got any development and why this shouldn't wait until the
next merge window.
Because honestly, this just all seems out of place.
Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox