* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Yeoreum Yun @ 2026-05-06 13:57 UTC (permalink / raw)
To: Mimi Zohar
Cc: David Safford, Jonathan McDowell, linux-security-module,
linux-kernel, linux-integrity, linux-arm-kernel, kvmarm, paul,
jmorris, serge, roberto.sassu, dmitry.kasatkin, eric.snowberg,
jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene
In-Reply-To: <9ff4853a8e9932b3a1424f2a6c3347f1723fb5f4.camel@linux.ibm.com>
Hi Mimi,
> On Wed, 2026-05-06 at 06:54 +0100, Yeoreum Yun wrote:
> > Hi Mimi,
> >
> > > On Sun, 2026-05-03 at 07:36 -0400, Mimi Zohar wrote:
> > > > On Fri, 2026-05-01 at 12:52 -0400, David Safford wrote:
> > > > > On Thu, Apr 30, 2026 at 5:43 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > >
> > > > > > On Thu, 2026-04-30 at 10:48 +0100, Yeoreum Yun wrote:
> > > > > > > With above change I confirmed there is no meaurement log
> > > > > > > between boot_aggregate and boot_aggregate_late except "kernel_version"
> > > > > > > But this is ignorable since this UTS measurement is done in
> > > > > > > "ima_init_core() (old: ima_init())" and it is part of ima initialisation.
> > > > > > >
> > > > > > > 1. ima_policy=tcb
> > > > > > >
> > > > > > > # cat /sys/kernel/security/ima/ascii_runtime_measurements
> > > > > > > 10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
> > > > > > > 10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late
> > > > > > > 10 7c23cc970eceec906f7a41bc2fbde770d7092209 ima-ng sha256:72ade6ae3d35cfe5ede7a77b1c0ed1d1782a899445fdcb219c0e994a084a70d5 /bin/busybox
> > > > > snip
> > > > > > >
> > > > > > > 2. ima_policy=critical_data
> > > > > > >
> > > > > > > # cat /sys/kernel/security/ima/ascii_runtime_measurements
> > > > > > > 10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
> > > > > > > 10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2 kernel_version 372e312e302d7263312b // Ignorable since it's generated by ima_init(_core)().
> > > > > > > 10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late
> > > > > > >
> > > > > > > Therefore, init_ima() could move into late_initcall_sync like v1 did:
> > > > > > > - https://lore.kernel.org/all/20260417175759.3191279-2-yeoreum.yun@arm.com/
> > > > > >
> > > > > > Thanks, Yeoreum. It's a bit premature to claim it's "safe" to move the
> > > > > > initcall. Hopefully others will respond.
> > > > > >
> > > > > > Mimi
> > > > >
> > > > > I have also run with this patch on a number of bare metal and virtual machines,
> > > > > running everything from default Fedora 44 to a version with everything turned on
> > > > > (uefi secure boot, UKI with sdboot stub measurements, IMA measurement
> > > > > and appraisal enabled,
> > > > > all systemd measurements on, and systemd using the TPM for root
> > > > > partition decryption.)
> > > > > I too see only the kernel_version event between the normal and late
> > > > > calls, if ima_policy=critical_data.
> > > >
> > > > Thanks, Dave! Were all the systems you tested x86_64? The next step would be
> > > > to test on different arch's (e.g. Z, Power).
> > >
> > > On both Z and PowerVM, there are ~30 measurements between boot_aggregate and
> > > boot_aggregate_late. For example, on PowerVM:
> > >
> > > # grep -n boot_aggregate
> > > /sys/kernel/security/integrity/ima/ascii_runtime_measurements
> > >
> > > 1:10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig
> > > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > > boot_aggregate
> > > 31:10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig
> > > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > > boot_aggregate_late
> > >
> > > It would be interesting to the results from a Raspberry Pi 5 as well,
> > > with/without a TPM.
> >
> > Honestly, I find this result hard to accept.
> >
> > This effectively means that there is code invoking IMA measurement during late_initcall().
> > It also implies that if, in the future, a late_initcall is added that performs
> > an IMA measurement before IMA initialization has occurred accoding to order by linker,
> > that measurement could be missed.
>
> Exactly. The results are simply from booting with the builtin "tcb" and
> "critical_data" policies.
>
> $ sudo grubby --args="ima_policy=\"tcb|critical_data\"" --update-kernel
> /boot/vmlinuz-${SUFFIX}
Thanks. but I still wonder what meaasurements there are between
boot_aggregate and boot_aggregate_late.
Might be there would be key measurements if it takes more than
5 mins before generating boot_aggregate_late but this seems rare.
If you don't mind, would you share the contents of the log between
boot_aggregate and boot_aggregate_late?
since I only get a kernel_version in my environment.
And I think we can collect missing measurements before ima_init_core()
into another separate list than ima_measurements in ima_add_template_entry() and
we can extend them after boot_aggreagate log generation at ima_init_core()
then ima initialisation could be moved to late_initcall_sync like
(just for a test and share concept):
-------&<-------
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 9a1117112fb2..737c1ac8ad77 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -67,6 +67,7 @@ extern int ima_appraise;
extern struct tpm_chip *ima_tpm_chip;
extern const char boot_aggregate_name[];
extern const char boot_aggregate_late_name[];
+extern bool ima_extend_on;
/* IMA event related data */
struct ima_event_data {
@@ -107,6 +108,7 @@ struct ima_template_desc {
:...skipping...
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 9a1117112fb2..737c1ac8ad77 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -67,6 +67,7 @@ extern int ima_appraise;
extern struct tpm_chip *ima_tpm_chip;
extern const char boot_aggregate_name[];
extern const char boot_aggregate_late_name[];
+extern bool ima_extend_on;
/* IMA event related data */
struct ima_event_data {
@@ -107,6 +108,7 @@ struct ima_template_desc {
struct ima_template_entry {
int pcr;
+ int violation;
struct tpm_digest *digests;
struct ima_template_desc *template_desc; /* template descriptor */
u32 template_data_len;
@@ -317,6 +319,7 @@ unsigned long ima_get_binary_runtime_size(void);
int ima_init_template(void);
void ima_init_template_list(void);
int __init ima_init_digests(void);
+int __init ima_extend_deferred(void);
void __init ima_init_reboot_notifier(void);
int ima_lsm_policy_change(struct notifier_block *nb, unsigned long event,
void *lsm_data);
diff --git a/security/integrity/ima/ima_init.c b/security/integrity/ima/ima_init.c
index edd063b99685..f6a2b53c1dcb 100644
--- a/security/integrity/ima/ima_init.c
+++ b/security/integrity/ima/ima_init.c
@@ -149,10 +149,22 @@ int __init ima_init_core(bool late)
rc = ima_init_digests();
if (rc != 0)
return rc;
+
+ ima_extend_on = true;
+
rc = ima_add_boot_aggregate(late); /* boot aggregate must be first entry */
if (rc != 0)
return rc;
+ /* This is just for a test. */
+ if (!late)
+ ima_extend_on = false;
+ else {
+ rc = ima_extend_deferred();
+ if (rc != 0)
+ return rc;
+ }
+
ima_init_policy();
rc = ima_fs_init();
diff --git a/security/integrity/ima/ima_queue.c b/security/integrity/ima/ima_queue.c
index 319522450854..81f2ee070fee 100644
--- a/security/integrity/ima/ima_queue.c
+++ b/security/integrity/ima/ima_queue.c
@@ -22,10 +22,13 @@
#define AUDIT_CAUSE_LEN_MAX 32
+bool ima_extend_on;
+
/* pre-allocated array of tpm_digest structures to extend a PCR */
static struct tpm_digest *digests;
LIST_HEAD(ima_measurements); /* list of all measurements */
+static LIST_HEAD(ima_extend_deferred_head);
#ifdef CONFIG_IMA_KEXEC
static unsigned long binary_runtime_size;
#else
@@ -91,6 +94,7 @@ static int get_binary_runtime_size(struct ima_template_entry *entry)
return size;
}
+
/* ima_add_template_entry helper function:
* - Add template entry to the measurement list and hash table, for
* all entries except those carried across kexec.
@@ -98,7 +102,8 @@ static int get_binary_runtime_size(struct ima_template_entry *entry)
* (Called with ima_extend_list_mutex held.)
*/
static int ima_add_digest_entry(struct ima_template_entry *entry,
- bool update_htable)
+ bool update_htable,
+ struct list_head *measurements_list)
{
struct ima_queue_entry *qe;
unsigned int key;
@@ -111,7 +116,7 @@ static int ima_add_digest_entry(struct ima_template_entry *entry,
qe->entry = entry;
INIT_LIST_HEAD(&qe->later);
- list_add_tail_rcu(&qe->later, &ima_measurements);
+ list_add_tail_rcu(&qe->later, measurements_list);
atomic_long_inc(&ima_htable.len);
if (update_htable) {
@@ -173,6 +178,7 @@ int ima_add_template_entry(struct ima_template_entry *entry, int violation,
char tpm_audit_cause[AUDIT_CAUSE_LEN_MAX];
int audit_info = 1;
int result = 0, tpmresult = 0;
+ struct list_head *measurements_list;
mutex_lock(&ima_extend_list_mutex);
@@ -195,15 +201,21 @@ int ima_add_template_entry(struct ima_template_entry *entry, int violation,
}
}
+
+ entry->violation = violation;
+ measurements_list = (ima_extend_on) ? &ima_measurements :
+ &ima_extend_deferred_head;
+
result = ima_add_digest_entry(entry,
- !IS_ENABLED(CONFIG_IMA_DISABLE_HTABLE));
+ !IS_ENABLED(CONFIG_IMA_DISABLE_HTABLE),
+ measurements_list);
if (result < 0) {
audit_cause = "ENOMEM";
audit_info = 0;
goto out;
}
- if (violation) /* invalidate pcr */
+ if (violation) /* invalidate pcr */
digests_arg = digests;
tpmresult = ima_pcr_extend(digests_arg, entry->pcr);
@@ -225,7 +237,7 @@ int ima_restore_measurement_entry(struct ima_template_entry *entry)
int result = 0;
mutex_lock(&ima_extend_list_mutex);
- result = ima_add_digest_entry(entry, 0);
+ result = ima_add_digest_entry(entry, 0, &ima_measurements);
mutex_unlock(&ima_extend_list_mutex);
return result;
}
@@ -288,3 +300,23 @@ int __init ima_init_digests(void)
return 0;
}
+
+int __init ima_extend_deferred(void)
+{
+ guard(mutex)(&ima_extend_list_mutex);
+ struct ima_queue_entry *qe;
+ struct tpm_digest *digests_arg;
+ int ret = 0;
+
+ list_for_each_entry(qe, &ima_extend_deferred_head, later) {
+ digests_arg = (qe->entry->violation) ? digests : qe->entry->digests;
+ ret = ima_pcr_extend(digests_arg, qe->entry->pcr);
+ if (ret)
+ /* TODO: audit? */
+ break;
+ }
+
+ list_splice_tail_init(&ima_extend_deferred_head, &ima_measurements);
+
+ return ret;
+}
--
Sincerely,
Yeoreum Yun
^ permalink raw reply related
* Re: [PATCH v4 0/7] landlock: Add UDP access control support
From: Günther Noack @ 2026-05-06 15:33 UTC (permalink / raw)
To: Matthieu Buffet
Cc: Mickaël Salaün, linux-security-module, Mikhail Ivanov,
konstantin.meskhidze, Tingmao Wang, netdev
In-Reply-To: <20260502124306.3975990-1-matthieu@buffet.re>
Hello!
Thanks for sending another revision!
On Sat, May 02, 2026 at 02:42:59PM +0200, Matthieu Buffet wrote:
> This is V4 of UDP access control in Landlock. Thanks to the round of
> review of v3, access rights have changed to something that seems easier
> to use and understand. It adds only two access rights, to restrict
> configuring local and remote addresses on UDP sockets. The one that
> restricts setting a remote address also controls sending datagrams to
> explicit remote addresses -ignoring any remote address preset on the
> socket-. The one that restricts binding to a local port also applies
> when the kernel auto-binds an ephemeral port.
> v1:
> Link: https://lore.kernel.org/all/20240916122230.114800-1-matthieu@buffet.re/
> v2:
> Link: https://lore.kernel.org/all/20241214184540.3835222-1-matthieu@buffet.re/
> v3:
> Link: https://lore.kernel.org/all/20251212163704.142301-1-matthieu@buffet.re/
>
> The limitation around allowing a process to send but not receive is
> still there, and could warrant another patch if there is a real user
> need.
> I'm just not super happy about the clarity of logs generated for denied
> autobinds ("domain=xxxxxx blockers=net.bind_udp"), due to the fact that
> addresses and ports are currently only logged if they are non-0. A later
> (coordinated LSM-wide) patch could improve readability by replacing != 0
> checks with new booleans in struct lsm_network_audit. I'm also not
> exactly happy with the integration in existing TCP selftests, but
> refactoring them has already been discussed earlier.
>
> Changes v1->v2
> ==============
> - recvmsg hook is gone and sendmsg hook doesn't apply when sending to a
> remote address pre-set on socket, to improve performance
> - don't add a get_addr_port() helper function, which required a weird
> "am I in IPv4 or IPv6 context"
> - reorder hook prologue for consistency: check domain, then type and
> family
>
> Changes v2->v3
> ==============
> - removed support for sending datagrams with explicit destination
> address of family AF_UNSPEC, which allowed to bypass restrictions with
> a race condition
> - rebased on linux-mic/next => add support for auditing
> - fixed mistake in selftests when using unspec_srv variables, which were
> implicitly of type SOCK_STREAM and did not actually test UDP code
> - add tests for IPPROTO_IP
> - improved docs, split off TCP-related refactoring
>
> Changes v3->v4
> ==============
> - merge LANDLOCK_ACCESS_NET_CONNECT_UDP and
> LANDLOCK_ACCESS_NET_SENDTO_UDP into
> LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP (everything that might set the
> destination of a datagram)
I wish the name could be more in-line with
LANDLOCK_ACCESS_FS_RESOLVE_UNIX, but since this does not need
resolving any more, "resolve" in the name would be confusing. I also
failed to come up with a better name for this access right.
> - make LANDLOCK_ACCESS_NET_BIND_UDP apply when kernel is about to
> auto-bind an ephemeral port for the caller. Block it if policy would
> not allow an explicit call to bind(0)
> - only deny sending AF_UNSPEC datagrams on IPv6 sockets, where there is
> a risk of the address family changing midway
>
> Patch is based on https://git.kernel.org/pub/scm/linux/kernel/git/mic/linux.git
> 3457a5ccacd3 ("landlock: Document fallocate(2) as another truncation corner case")
> All lines added are covered with selftests, except the "default: return
> 0" in current_check_autobind_udp_socket() which is not currently
> reachable (net.c goes from 92.9%->94.6% line coverage).
>
> Let me know what you think!
>
> Closes: https://github.com/landlock-lsm/linux/issues/10
>
> Matthieu Buffet (7):
> landlock: Add UDP bind() access control
> landlock: Add UDP connect() access control
> landlock: Add UDP send access control
For the final revision, I think it would be good to squash the two
commits that are about LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP. That
reduces the chances that someone backports the first but not the
second to one of the distribution kernels.
> selftests/landlock: Add UDP bind/connect tests
> selftests/landlock: Add tests for sendmsg()
> samples/landlock: Add sandboxer UDP access control
> landlock: Add documentation for UDP support
>
> Documentation/userspace-api/landlock.rst | 89 +-
> include/uapi/linux/landlock.h | 35 +-
> samples/landlock/sandboxer.c | 40 +-
> security/landlock/audit.c | 3 +
> security/landlock/limits.h | 2 +-
> security/landlock/net.c | 161 ++-
> security/landlock/syscalls.c | 2 +-
> tools/testing/selftests/landlock/base_test.c | 4 +-
> tools/testing/selftests/landlock/net_test.c | 1146 ++++++++++++++++--
> 9 files changed, 1341 insertions(+), 141 deletions(-)
>
>
> base-commit: 3457a5ccacd34fdd5ebd3a4745e721b5a1239690
> --
> 2.39.5
>
—Günther
^ permalink raw reply
* Re: [PATCH] Documentation: fix typo and formattting in security/credentials.rst
From: Randy Dunlap @ 2026-05-06 17:31 UTC (permalink / raw)
To: Mayank Gite, Paul Moore
Cc: Serge Hallyn, Jonathan Corbet, Shuah Khan, linux-security-module,
linux-doc, linux-kernel
In-Reply-To: <20260506054914.162806-1-drapl0n@protonmail.com>
Hi--
On 5/5/26 10:49 PM, Mayank Gite wrote:
> - Fixes a typo in "Keys and keyrings" section. Replaces "keying" with
> "keyring".
> - Updates formatting of keyring types.
>
> Signed-off-by: Mayank Gite <drapl0n@protonmail.com>
Something (protonmail?) split some lines of your patch so that it
cannot be applied:
patch: **** malformed patch at line 24: tials:
See https://lore.kernel.org/linux-doc/20260506054914.162806-1-drapl0n@protonmail.com/raw
You can see if Documentation/process/email-clients.rst can help you any,
or just do an web search for using Proton mail to send plain text patches,
but using Proton might be difficult (IDK).
> ---
> Documentation/security/credentials.rst | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/security/credentials.rst b/Documentation/security/credentials.rst
> index d0191c8b8060..4996838491b1 100644
> --- a/Documentation/security/credentials.rst
> +++ b/Documentation/security/credentials.rst
> @@ -189,9 +189,9 @@ The Linux kernel supports the following types of credentials:
> be searched for the desired key. Each process may subscribe to a number
> of keyrings:
>
> - Per-thread keying
> - Per-process keyring
> - Per-session keyring
> + - Per-thread keyring
> + - Per-process keyring
> + - Per-session keyring
>
> When a process accesses a key, if not already present, it will normally be
> cached on one of these keyrings for future accesses to find.
The change itself looks good - if you can find a good way to email it.
thanks.
--
~Randy
^ permalink raw reply
* [PATCH] rust: cred: add safe abstractions for capable() and ns_capable()
From: Arnav Sharma @ 2026-05-06 20:49 UTC (permalink / raw)
To: ojeda, paul
Cc: Arnav Sharma, Serge Hallyn, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, linux-security-module,
rust-for-linux, linux-kernel
The capable() function is the primary privilege gate in the Linux kernel,
used to check if the current task possesses a specific POSIX capability.
While bindings for capable() and ns_capable() exist, there are currently
no safe Rust abstractions for them.
Introduce safe Rust wrappers for capable() and ns_capable() in the
kernel::cred module. These functions validate that the requested
capability is within the valid [0, CAP_LAST_CAP] bounds before calling
into the C side, ensuring that safe Rust code cannot inadvertently
trigger a kernel BUG() on invalid inputs.
The abstractions take a `u32` parameter to ergonomically match the
generated `bindings::CAP_*` constants without requiring explicit caller
casts.
Signed-off-by: Arnav Sharma <arnav4324@gmail.com>
---
rust/kernel/cred.rs | 79 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 79 insertions(+)
diff --git a/rust/kernel/cred.rs b/rust/kernel/cred.rs
index ffa156b9df37..6525b52b81ae 100644
--- a/rust/kernel/cred.rs
+++ b/rust/kernel/cred.rs
@@ -90,3 +90,82 @@ unsafe fn dec_ref(obj: core::ptr::NonNull<Credential>) {
unsafe { bindings::put_cred(obj.cast().as_ptr()) };
}
}
+
+/// Checks whether the current task has the given capability in the init user namespace.
+///
+/// This function tests whether the current task has the specified POSIX capability available for
+/// use. The check is performed against the initial user namespace (`init_user_ns`).
+///
+/// When the check succeeds, the kernel sets the `PF_SUPERPRIV` flag on the current task. This
+/// marks the task as having used superuser privileges, which is visible in process accounting
+/// and auditing.
+///
+/// The capability constants are available as `bindings::CAP_*` values (for example,
+/// [`bindings::CAP_NET_ADMIN`], [`bindings::CAP_SYS_ADMIN`]). These constants are defined in
+/// `include/uapi/linux/capability.h`.
+///
+/// This function must be called from task (process) context only. Calling it from a context where
+/// there is no valid `current` task (such as hard interrupt context) is not permitted.
+///
+/// # Preconditions
+///
+/// `cap` must be a valid capability constant in the range `[0, CAP_LAST_CAP]`.
+/// Passing a value outside this range is a programming error and will trigger
+/// a kernel `BUG()`.
+///
+/// C header: [`include/linux/capability.h`](srctree/include/linux/capability.h)
+///
+/// # Examples
+///
+/// ```
+/// use kernel::bindings;
+/// use kernel::cred::capable;
+///
+/// if !capable(bindings::CAP_SYS_ADMIN) {
+/// return Err(EPERM);
+/// }
+/// # Ok::<(), Error>(())
+/// ```
+#[inline]
+pub fn capable(cap: u32) -> bool {
+ // SAFETY: `capable()` is safe to call from task context. It checks `current_cred()` against
+ // the init user namespace and returns whether the specified capability is granted.
+ unsafe { bindings::capable(cap as i32) }
+}
+
+/// Checks whether the current task has the given capability in the specified user namespace.
+///
+/// This is the namespace-aware variant of [`capable`]. It tests whether the current task has the
+/// specified capability in the given user namespace, rather than in the init user namespace.
+///
+/// This function is relevant for code that must respect user namespace boundaries (for example,
+/// operations inside unprivileged containers). For most driver code that is not namespace-aware,
+/// [`capable`] is the correct function to use instead.
+///
+/// Like [`capable`], this function sets `PF_SUPERPRIV` on the current task when the check
+/// succeeds, and it must be called from task context only.
+///
+/// # Preconditions
+///
+/// `cap` must be a valid capability constant in the range `[0, CAP_LAST_CAP]`.
+/// Passing a value outside this range is a programming error and will trigger
+/// a kernel `BUG()`.
+///
+/// C header: [`include/linux/capability.h`](srctree/include/linux/capability.h)
+///
+/// # Safety
+///
+/// The caller must ensure that:
+///
+/// - `ns` is a non-null pointer to a fully initialized `struct user_namespace`.
+/// - The `user_namespace` pointed to by `ns` remains valid and is not freed for
+/// the duration of this call.
+#[inline]
+pub unsafe fn ns_capable(ns: *mut bindings::user_namespace, cap: u32) -> bool {
+ // SAFETY: The caller guarantees that `ns` is a non-null, valid pointer to a fully initialized
+ // `struct user_namespace` that remains valid for the duration of this call.
+ // `ns_capable()` checks `current_cred()` against the provided namespace and returns whether
+ // the specified capability is granted.
+ unsafe { bindings::ns_capable(ns, cap as i32) }
+}
+
--
2.43.0
^ permalink raw reply related
* [PATCH] Documentation: fix typo and formattting in security/credentials.rst
From: Mayank Gite @ 2026-05-06 22:59 UTC (permalink / raw)
To: Paul Moore
Cc: Mayank Gite, Serge Hallyn, Jonathan Corbet, Shuah Khan,
linux-security-module, linux-doc, linux-kernel
- Fixes a typo in "Keys and keyrings" section. Replaces "keying" with
"keyring".
- Updates formatting of keyring types.
Signed-off-by: Mayank Gite <drapl0n.kernel@gmail.com>
---
Documentation/security/credentials.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/security/credentials.rst b/Documentation/security/credentials.rst
index d0191c8b8060..4996838491b1 100644
--- a/Documentation/security/credentials.rst
+++ b/Documentation/security/credentials.rst
@@ -189,9 +189,9 @@ The Linux kernel supports the following types of credentials:
be searched for the desired key. Each process may subscribe to a number
of keyrings:
- Per-thread keying
- Per-process keyring
- Per-session keyring
+ - Per-thread keyring
+ - Per-process keyring
+ - Per-session keyring
When a process accesses a key, if not already present, it will normally be
cached on one of these keyrings for future accesses to find.
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] Documentation: fix typo and formattting in security/credentials.rst
From: Randy Dunlap @ 2026-05-07 0:36 UTC (permalink / raw)
To: Mayank Gite, Paul Moore
Cc: Serge Hallyn, Jonathan Corbet, Shuah Khan, linux-security-module,
linux-doc, linux-kernel
In-Reply-To: <20260506225925.271163-1-drapl0n.kernel@gmail.com>
Hi,
On 5/6/26 3:59 PM, Mayank Gite wrote:
> - Fixes a typo in "Keys and keyrings" section. Replaces "keying" with
> "keyring".
> - Updates formatting of keyring types.
>
> Signed-off-by: Mayank Gite <drapl0n.kernel@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
> ---
In the future, right here, after that "---" line, it should say
something like
v2: use 'git send-email' so that that patch isn't corrupted
and in the Subject: it should say
[PATCH v2] ...
Thanks.
> Documentation/security/credentials.rst | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/security/credentials.rst b/Documentation/security/credentials.rst
> index d0191c8b8060..4996838491b1 100644
> --- a/Documentation/security/credentials.rst
> +++ b/Documentation/security/credentials.rst
> @@ -189,9 +189,9 @@ The Linux kernel supports the following types of credentials:
> be searched for the desired key. Each process may subscribe to a number
> of keyrings:
>
> - Per-thread keying
> - Per-process keyring
> - Per-session keyring
> + - Per-thread keyring
> + - Per-process keyring
> + - Per-session keyring
>
> When a process accesses a key, if not already present, it will normally be
> cached on one of these keyrings for future accesses to find.
--
~Randy
^ permalink raw reply
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Mimi Zohar @ 2026-05-07 2:25 UTC (permalink / raw)
To: Paul Moore
Cc: Yeoreum Yun, Jonathan McDowell, linux-security-module,
linux-kernel, linux-integrity, linux-arm-kernel, kvmarm, jmorris,
serge, roberto.sassu, dmitry.kasatkin, eric.snowberg, jarkko, jgg,
sudeep.holla, maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, noodles, sebastianene
In-Reply-To: <19dfb0e2730.2843.85c95baa4474aabc7814e68940a78392@paul-moore.com>
On Tue, 2026-05-05 at 22:11 -0400, Paul Moore wrote:
> On May 5, 2026 9:57:23 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > On Tue, 2026-05-05 at 18:55 -0400, Paul Moore wrote:
> > > On Tue, May 5, 2026 at 5:05 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > On Mon, 2026-05-04 at 16:51 -0400, Paul Moore wrote:
> > > > > On Mon, May 4, 2026 at 8:03 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > > On Sun, 2026-05-03 at 12:46 -0400, Paul Moore wrote:
> > > > > > > Regardless, assuming you always want IMA to leverage a TPMs when they
> > > > > > > exist, your reply suggests that using an initcall based IMA init
> > > > > > > scheme, even a late-sync initcall, may not be sufficient because
> > > > > > > deferred TPM initialization could happen later, yes?
> > > > > >
> > > > > > Well yeah. The TPM could be configured as a module, but that scenario is
> > > > > > not of
> > > > > > interest. That's way too late. The case being addressed in this patch set is
> > > > > > when the TPM driver tries to initialize at device_initcall, returns
> > > > > > EPROBE_DEFER, and is retried at deferred_probe_initcall (late_initcall). Since
> > > > > > ordering within an initcall is not supported, this patch attempts to initialize
> > > > > > IMA at late_initcall and similarly retries, in this case, at
> > > > > > late_initcall_sync.
> > > > >
> > > > > Okay, so from a TPM initialization perspective you are satisfied with
> > > > > a late-sync IMA initialization, yes?
> > > >
> > > > No. On some architectures moving IMA initialization from the late_initcall to
> > > > late_initcall_sync does not miss any measurement records. However, as
> > > > previously
> > > > mentioned, Linux running in a PowerVM LPAR the move would drop ~30 measurement
> > > > records[1]. So no, only if the TPM is not initialized by late_initcall, should
> > > > IMA retry at late_initcall_sync.
> > >
> > > What do you do in the PowerVM LPAR when the TPM is not avaiable at
> > > late initcall and you have to defer IMA initialization until
> > > late-sync?
> >
> > Your question is hypothetical ...
>
> <heavy eye roll>
>
> > ... as the TPM isn't deferred, so IMA doesn't go into
> > TPM-bypass mode. Testing on a PowerVM LPAR demonstrated that it skips ~30
> > measurement list records. So moving the initcall to late_initcall_sync would
> > cause a regression.
>
> Let me rephrase to make the question clear - how do you plan to handle a
> system where you lose measurements by waiting until late-sync, but the TPM
> is not available at the late initcall.
There have been suggestions to queue the IMA measurements, but that goes against
the "measure before use" principle. The solution is not to defer IMA
initialization for all systems, but to differentiate the boot_aggregate record
(boot_aggregate vs. boot_aggregate_late) based on when the TPM becomes available
relative to IMA's initcall. IMA's job is simply to collect and provide the
measurement list. Based on the attestation service policy, the attestation
service will decide whether a measurement list containing boot_aggregate_late is
acceptable.
Mimi
^ permalink raw reply
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Mimi Zohar @ 2026-05-07 2:32 UTC (permalink / raw)
To: Yeoreum Yun
Cc: David Safford, Jonathan McDowell, linux-security-module,
linux-kernel, linux-integrity, linux-arm-kernel, kvmarm, paul,
jmorris, serge, roberto.sassu, dmitry.kasatkin, eric.snowberg,
jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene
In-Reply-To: <aftIuPwNeuzc9nY1@e129823.arm.com>
On Wed, 2026-05-06 at 14:57 +0100, Yeoreum Yun wrote:
> > > > On both Z and PowerVM, there are ~30 measurements between boot_aggregate and
> > > > boot_aggregate_late. For example, on PowerVM:
> > > >
> > > > # grep -n boot_aggregate
> > > > /sys/kernel/security/integrity/ima/ascii_runtime_measurements
> > > >
> > > > 1:10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig
> > > > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > > > boot_aggregate
> > > > 31:10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig
> > > > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > > > boot_aggregate_late
> > > >
> > > > It would be interesting to the results from a Raspberry Pi 5 as well,
> > > > with/without a TPM.
> > >
> > > Honestly, I find this result hard to accept.
> > >
> > > This effectively means that there is code invoking IMA measurement during late_initcall().
> > > It also implies that if, in the future, a late_initcall is added that performs
> > > an IMA measurement before IMA initialization has occurred accoding to order by linker,
> > > that measurement could be missed.
> >
> > Exactly. The results are simply from booting with the builtin "tcb" and
> > "critical_data" policies.
> >
> > $ sudo grubby --args="ima_policy=\"tcb|critical_data\"" --update-kernel
> > /boot/vmlinuz-${SUFFIX}
>
> Thanks. but I still wonder what meaasurements there are between
> boot_aggregate and boot_aggregate_late.
> Might be there would be key measurements if it takes more than
> 5 mins before generating boot_aggregate_late but this seems rare.
>
> If you don't mind, would you share the contents of the log between
> boot_aggregate and boot_aggregate_late?
> since I only get a kernel_version in my environment.
1 10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig
sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
boot_aggregate
2 10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf
sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2
kernel_version 372e312e302d7263312b
3 10 92c40bfd65512d5224cddb9fb64fef0d72e1c182 ima-sig
sha256:412bae0d0e85a99971d6eda198dd2fed3c2959715e8a17a4caddc7bc605bdeeb
/usr/bin/kmod
4 10 a18f997e1e82d0ef416f93683966d7dda875d71c ima-sig
sha256:0050fcc672e03cfdc3a50c771ca9f5219478e5538980a26fd4484620712d8163
/usr/lib64/ld64.so.2
5 10 88f343618caeeed92ed8281d627f4565b0499d66 ima-sig
sha256:a0e83c084d8c227f1150a8cd94eece61f62bc1da30f98d1cf57ca7db241a9c45
/etc/ld.so.cache
6 10 e047868f01908eb95aa180693291decab82bb6be ima-sig
sha256:42ebf9cc684419de4d8a1d624102716d88fbcf957f47e50a9a08e38b338023ac
/usr/lib64/libzstd.so.1.5.5
7 10 da069bc6a44d454510a76c69d3a54c3b238ae27e ima-sig
sha256:9b7c788e75c16c8827062016cf15826e43661c4b5b56813ea07ff2635bea2710
/usr/lib64/liblzma.so.5.6.2
8 10 7ade414e736e7b449cda5ec5e0277b99548e89c6 ima-sig
sha256:d899452e8e6369e436ba1a565833d6dcf0d09c35e40ffc0979cf4de2bdb8f421
/usr/lib64/libz.so.1.3.1.zlib-ng
9 10 9a9da8326f36237a47d6ed21bdffd0e1ff855e2a ima-sig
sha256:a848f396db7ad135f851b5e9aeb32f4a3ef1439c7913b9b95ab1cda69251f6ad
/usr/lib64/libcrypto.so.3.5.1
10 10 3201d27cd4028f02fc9088ec33e2d0ceb72d2c5b ima-sig
sha256:e52dcd1850555c08d60fefe56694c1179b4eaa5796db0907606552ece8e1bab1
/usr/lib64/libgcc_s-14-20250617.so.1
11 10 3b4c6f13e52ca060b290709f737b1ff66564226f ima-sig
sha256:f2a900a5b980b289dc028dd3caab16b1b0ad037f2e875546bb3197d23ff241f0
/usr/lib64/glibc-hwcaps/power10/libc.so.6
12 10 b23b616cbd3c9dc4c5743d121c1c5a702b461a9c ima-sig
sha256:5a682022beeea9ee7f36a70f0465942bf32e9675d3f45355088e148787e02175
/usr/lib/modprobe.d/dist-alsa.conf
13 10 aec07fad18697f295d7e06796fc8dfd3b472f9c3 ima-sig
sha256:067d949bab3bb085d0936031881ff73b2ab39f34b9a90cbd01396d1987ff6658
/usr/lib/modprobe.d/dist-blacklist.conf
14 10 c402c56b66e65914148efd6e3cf0b1d616daabe6 ima-sig
sha256:120a02e9b88ba74949224eca7385825e39880f5687f739ade07d94ee22ffe325
/etc/modprobe.d/firewalld-sysctls.conf
15 10 e358ca12bd58e1ce4845e299e1aea8b81edf86f9 ima-sig
sha256:fa27abcd357a16ee1254ba38d1225b7f0724036c07ce3d0e83b29eb72d97c419
/etc/modprobe.d/l2tp_eth-blacklist.conf
16 10 4b036d41435d7df3a72b38880f5fe231904b7b66 ima-sig
sha256:ecf5f948bfbfb726879a910b3174d139c8af6b1745c88dcc1e4a1cf532c02299
/etc/modprobe.d/l2tp_ip-blacklist.conf
17 10 9c53a7a48c1b5218417c4f25c4a34c09a9f39830 ima-sig
sha256:f76c4ac232d5e96c57961a9f10194703b4df6d119530046f0b23eee70bfcb089
/etc/modprobe.d/l2tp_ip6-blacklist.conf
18 10 6c41d7b7d251c400b7e0ba76f7b386a746e8f4ec ima-sig
sha256:5cbc958f893a599ef19437014696dd7b112cf9af6a4348830177f8a8f78aa1b3
/etc/modprobe.d/l2tp_netlink-blacklist.conf
19 10 f37ef48faef5bc51e29d47531726af0bd0654655 ima-sig
sha256:7a3d63acb49e4a69b482f26624761b5778fbd6b77be8a3f36926b379b5f965ed
/etc/modprobe.d/l2tp_ppp-blacklist.conf
20 10 82ef59779acdfd6e9b35521bfa09e6ba86fd6174 ima-sig
sha256:6a8f2009d87deba7a2de46e3d0c46b114fe388d188b00b9a382fc2156aabb676
/usr/lib/modules/7.1.0-rc1+/modules.softdep
21 10 6ae994e33a6313ab4535da90f5cb6c3beaec7b86 ima-sig
sha256:268695dbf23bd0170ec9a95b10e8d596205fd7436617d10101907171bf004b7c
/etc/modprobe.d/sctp-blacklist.conf
22 10 b2c238ae66b03f56191d9955a5ad0f3110bb7e2b ima-sig
sha256:64a8ebb0a1fd712a9aeb7aa0f0ad0b72d3277034c8bfa3b66ab063e201d6527e
/etc/modprobe.d/sctp_diag-blacklist.conf
23 10 c0443f2d3c078959ae86276df23abe172234a55d ima-sig
sha256:e5a3958cbd3684b63f3cada6604469cc56f727b106d5524daf5aefa6935a48ce
/usr/lib/modprobe.d/systemd.conf
24 10 5c46e012bc7fffc3256b166282a7eaa4bea5fa33 ima-sig
sha256:6560abcdd2cdb41e1d0fe73052298d612920d5bccb4a3a7c82bc73895128e760
/etc/modprobe.d/tipc_diag-blacklist.conf
25 10 d5fb1836364732fbc4f87aa7d2c984cf30bdbfd3 ima-sig
sha256:358703c09ac2d2c653e11bbc7c65d378c8496e87ca47307f86c36b0b29640598
/etc/modprobe.d/tuned.conf
26 10 a85107163729f696f316d46c0bf3f65f713ba972 ima-sig
sha256:7410bb4cec56892e8b0010c5c8b72be532784ccf0240aa0677c5be085a530f65
/usr/lib/modules/7.1.0-rc1+/modules.dep.bin
27 10 80eb261ffb2cc3528d90c33b1c624f657a045867 ima-sig
sha256:856e0f083226f8b4fb7d1d71447fb841dae18ea9a50ea6d8505a206167288e1d
/usr/lib/modules/7.1.0-rc1+/modules.alias.bin
28 10 6af2d661da470d7a1c9909ddbc074d3d265eb1d7 ima-sig
sha256:4853ca200598c52970c380fda99484068e7db4961a4f94faac6abcfbbd52d150
/usr/lib/modules/7.1.0-rc1+/modules.symbols.bin
29 10 6f9cd405bd57d925baae6ae66c273c61c90b3bc8 ima-sig
sha256:193d1e1004848f7d391877507b69a7953e1f94ddbe70eb0e2cf6dc45fce7cd6a
/usr/lib/modules/7.1.0-rc1+/modules.builtin.alias.bin
30 10 4e20b980bf3a825a866be0c46033ed654df4aeba ima-sig
sha256:3a0e3c56d51ba98258ff13f93f82c837de22f4b707d24678f82893babf4d77ea
/usr/lib/modules/7.1.0-rc1+/modules.builtin.bin
31 10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig
sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
boot_aggregate_late
32 10 81830cd3d799e006698258dc1b11fe29a56eeef5 ima-sig
sha256:d1651dc50bb5b92c1badcab9aa4dbbca40cb704cdc707d1c536b41d7b1aa465e
/usr/lib/systemd/systemd
>
> And I think we can collect missing measurements before ima_init_core()
> into another separate list than ima_measurements in ima_add_template_entry() and
> we can extend them after boot_aggreagate log generation at ima_init_core()
> then ima initialisation could be moved to late_initcall_sync like
> (just for a test and share concept):
That breaks the "measure before use" principle.
Mimi
^ permalink raw reply
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Yeoreum Yun @ 2026-05-07 5:50 UTC (permalink / raw)
To: Mimi Zohar
Cc: David Safford, Jonathan McDowell, linux-security-module,
linux-kernel, linux-integrity, linux-arm-kernel, kvmarm, paul,
jmorris, serge, roberto.sassu, dmitry.kasatkin, eric.snowberg,
jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene
In-Reply-To: <9d1af933ef218b159762884357d127e3644dfe2c.camel@linux.ibm.com>
Hi Mimi,
> On Wed, 2026-05-06 at 14:57 +0100, Yeoreum Yun wrote:
> > > > > On both Z and PowerVM, there are ~30 measurements between boot_aggregate and
> > > > > boot_aggregate_late. For example, on PowerVM:
> > > > >
> > > > > # grep -n boot_aggregate
> > > > > /sys/kernel/security/integrity/ima/ascii_runtime_measurements
> > > > >
> > > > > 1:10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig
> > > > > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > > > > boot_aggregate
> > > > > 31:10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig
> > > > > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > > > > boot_aggregate_late
> > > > >
> > > > > It would be interesting to the results from a Raspberry Pi 5 as well,
> > > > > with/without a TPM.
> > > >
> > > > Honestly, I find this result hard to accept.
> > > >
> > > > This effectively means that there is code invoking IMA measurement during late_initcall().
> > > > It also implies that if, in the future, a late_initcall is added that performs
> > > > an IMA measurement before IMA initialization has occurred accoding to order by linker,
> > > > that measurement could be missed.
> > >
> > > Exactly. The results are simply from booting with the builtin "tcb" and
> > > "critical_data" policies.
> > >
> > > $ sudo grubby --args="ima_policy=\"tcb|critical_data\"" --update-kernel
> > > /boot/vmlinuz-${SUFFIX}
> >
> > Thanks. but I still wonder what meaasurements there are between
> > boot_aggregate and boot_aggregate_late.
> > Might be there would be key measurements if it takes more than
> > 5 mins before generating boot_aggregate_late but this seems rare.
> >
> > If you don't mind, would you share the contents of the log between
> > boot_aggregate and boot_aggregate_late?
> > since I only get a kernel_version in my environment.
>
> 1 10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig
> sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> boot_aggregate
> 2 10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf
> sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2
> kernel_version 372e312e302d7263312b
> 3 10 92c40bfd65512d5224cddb9fb64fef0d72e1c182 ima-sig
> sha256:412bae0d0e85a99971d6eda198dd2fed3c2959715e8a17a4caddc7bc605bdeeb
> /usr/bin/kmod
> 4 10 a18f997e1e82d0ef416f93683966d7dda875d71c ima-sig
> sha256:0050fcc672e03cfdc3a50c771ca9f5219478e5538980a26fd4484620712d8163
> /usr/lib64/ld64.so.2
> 5 10 88f343618caeeed92ed8281d627f4565b0499d66 ima-sig
> sha256:a0e83c084d8c227f1150a8cd94eece61f62bc1da30f98d1cf57ca7db241a9c45
> /etc/ld.so.cache
> 6 10 e047868f01908eb95aa180693291decab82bb6be ima-sig
> sha256:42ebf9cc684419de4d8a1d624102716d88fbcf957f47e50a9a08e38b338023ac
> /usr/lib64/libzstd.so.1.5.5
> 7 10 da069bc6a44d454510a76c69d3a54c3b238ae27e ima-sig
> sha256:9b7c788e75c16c8827062016cf15826e43661c4b5b56813ea07ff2635bea2710
> /usr/lib64/liblzma.so.5.6.2
> 8 10 7ade414e736e7b449cda5ec5e0277b99548e89c6 ima-sig
> sha256:d899452e8e6369e436ba1a565833d6dcf0d09c35e40ffc0979cf4de2bdb8f421
> /usr/lib64/libz.so.1.3.1.zlib-ng
> 9 10 9a9da8326f36237a47d6ed21bdffd0e1ff855e2a ima-sig
> sha256:a848f396db7ad135f851b5e9aeb32f4a3ef1439c7913b9b95ab1cda69251f6ad
> /usr/lib64/libcrypto.so.3.5.1
> 10 10 3201d27cd4028f02fc9088ec33e2d0ceb72d2c5b ima-sig
> sha256:e52dcd1850555c08d60fefe56694c1179b4eaa5796db0907606552ece8e1bab1
> /usr/lib64/libgcc_s-14-20250617.so.1
> 11 10 3b4c6f13e52ca060b290709f737b1ff66564226f ima-sig
> sha256:f2a900a5b980b289dc028dd3caab16b1b0ad037f2e875546bb3197d23ff241f0
> /usr/lib64/glibc-hwcaps/power10/libc.so.6
> 12 10 b23b616cbd3c9dc4c5743d121c1c5a702b461a9c ima-sig
> sha256:5a682022beeea9ee7f36a70f0465942bf32e9675d3f45355088e148787e02175
> /usr/lib/modprobe.d/dist-alsa.conf
> 13 10 aec07fad18697f295d7e06796fc8dfd3b472f9c3 ima-sig
> sha256:067d949bab3bb085d0936031881ff73b2ab39f34b9a90cbd01396d1987ff6658
> /usr/lib/modprobe.d/dist-blacklist.conf
> 14 10 c402c56b66e65914148efd6e3cf0b1d616daabe6 ima-sig
> sha256:120a02e9b88ba74949224eca7385825e39880f5687f739ade07d94ee22ffe325
> /etc/modprobe.d/firewalld-sysctls.conf
> 15 10 e358ca12bd58e1ce4845e299e1aea8b81edf86f9 ima-sig
> sha256:fa27abcd357a16ee1254ba38d1225b7f0724036c07ce3d0e83b29eb72d97c419
> /etc/modprobe.d/l2tp_eth-blacklist.conf
> 16 10 4b036d41435d7df3a72b38880f5fe231904b7b66 ima-sig
> sha256:ecf5f948bfbfb726879a910b3174d139c8af6b1745c88dcc1e4a1cf532c02299
> /etc/modprobe.d/l2tp_ip-blacklist.conf
> 17 10 9c53a7a48c1b5218417c4f25c4a34c09a9f39830 ima-sig
> sha256:f76c4ac232d5e96c57961a9f10194703b4df6d119530046f0b23eee70bfcb089
> /etc/modprobe.d/l2tp_ip6-blacklist.conf
> 18 10 6c41d7b7d251c400b7e0ba76f7b386a746e8f4ec ima-sig
> sha256:5cbc958f893a599ef19437014696dd7b112cf9af6a4348830177f8a8f78aa1b3
> /etc/modprobe.d/l2tp_netlink-blacklist.conf
> 19 10 f37ef48faef5bc51e29d47531726af0bd0654655 ima-sig
> sha256:7a3d63acb49e4a69b482f26624761b5778fbd6b77be8a3f36926b379b5f965ed
> /etc/modprobe.d/l2tp_ppp-blacklist.conf
> 20 10 82ef59779acdfd6e9b35521bfa09e6ba86fd6174 ima-sig
> sha256:6a8f2009d87deba7a2de46e3d0c46b114fe388d188b00b9a382fc2156aabb676
> /usr/lib/modules/7.1.0-rc1+/modules.softdep
> 21 10 6ae994e33a6313ab4535da90f5cb6c3beaec7b86 ima-sig
> sha256:268695dbf23bd0170ec9a95b10e8d596205fd7436617d10101907171bf004b7c
> /etc/modprobe.d/sctp-blacklist.conf
> 22 10 b2c238ae66b03f56191d9955a5ad0f3110bb7e2b ima-sig
> sha256:64a8ebb0a1fd712a9aeb7aa0f0ad0b72d3277034c8bfa3b66ab063e201d6527e
> /etc/modprobe.d/sctp_diag-blacklist.conf
> 23 10 c0443f2d3c078959ae86276df23abe172234a55d ima-sig
> sha256:e5a3958cbd3684b63f3cada6604469cc56f727b106d5524daf5aefa6935a48ce
> /usr/lib/modprobe.d/systemd.conf
> 24 10 5c46e012bc7fffc3256b166282a7eaa4bea5fa33 ima-sig
> sha256:6560abcdd2cdb41e1d0fe73052298d612920d5bccb4a3a7c82bc73895128e760
> /etc/modprobe.d/tipc_diag-blacklist.conf
> 25 10 d5fb1836364732fbc4f87aa7d2c984cf30bdbfd3 ima-sig
> sha256:358703c09ac2d2c653e11bbc7c65d378c8496e87ca47307f86c36b0b29640598
> /etc/modprobe.d/tuned.conf
> 26 10 a85107163729f696f316d46c0bf3f65f713ba972 ima-sig
> sha256:7410bb4cec56892e8b0010c5c8b72be532784ccf0240aa0677c5be085a530f65
> /usr/lib/modules/7.1.0-rc1+/modules.dep.bin
> 27 10 80eb261ffb2cc3528d90c33b1c624f657a045867 ima-sig
> sha256:856e0f083226f8b4fb7d1d71447fb841dae18ea9a50ea6d8505a206167288e1d
> /usr/lib/modules/7.1.0-rc1+/modules.alias.bin
> 28 10 6af2d661da470d7a1c9909ddbc074d3d265eb1d7 ima-sig
> sha256:4853ca200598c52970c380fda99484068e7db4961a4f94faac6abcfbbd52d150
> /usr/lib/modules/7.1.0-rc1+/modules.symbols.bin
> 29 10 6f9cd405bd57d925baae6ae66c273c61c90b3bc8 ima-sig
> sha256:193d1e1004848f7d391877507b69a7953e1f94ddbe70eb0e2cf6dc45fce7cd6a
> /usr/lib/modules/7.1.0-rc1+/modules.builtin.alias.bin
> 30 10 4e20b980bf3a825a866be0c46033ed654df4aeba ima-sig
> sha256:3a0e3c56d51ba98258ff13f93f82c837de22f4b707d24678f82893babf4d77ea
> /usr/lib/modules/7.1.0-rc1+/modules.builtin.bin
> 31 10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig
> sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> boot_aggregate_late
> 32 10 81830cd3d799e006698258dc1b11fe29a56eeef5 ima-sig
> sha256:d1651dc50bb5b92c1badcab9aa4dbbca40cb704cdc707d1c536b41d7b1aa465e
> /usr/lib/systemd/systemd
Hmm... Theses measurements seems to happen while populating
initramfs which triggers file_post_open as async
(and I see the RAMFS seems not part of DONT_MEASURE in IMA).
If you don't mind, Could you check whether this measurements still
happen with initramfs_async=0?
If this measurements aren't generated with above option,
there is a question whether let IMA measure initramfs which can be
measured or not depending on boot option or timing (some file measurements
could be lost all when do_populate_rootfs() executes concurrently while
running late_initcall).
[...]
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH] rust: cred: add safe abstractions for capable() and ns_capable()
From: Onur Özkan @ 2026-05-07 6:04 UTC (permalink / raw)
To: Arnav Sharma
Cc: ojeda, paul, Serge Hallyn, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, linux-security-module,
rust-for-linux, linux-kernel
In-Reply-To: <20260506204913.26022-1-arnav4324@gmail.com>
On Thu, 07 May 2026 02:19:13 +0530
Arnav Sharma <arnav4324@gmail.com> wrote:
> The capable() function is the primary privilege gate in the Linux kernel,
> used to check if the current task possesses a specific POSIX capability.
> While bindings for capable() and ns_capable() exist, there are currently
> no safe Rust abstractions for them.
>
> Introduce safe Rust wrappers for capable() and ns_capable() in the
> kernel::cred module. These functions validate that the requested
> capability is within the valid [0, CAP_LAST_CAP] bounds before calling
> into the C side, ensuring that safe Rust code cannot inadvertently
> trigger a kernel BUG() on invalid inputs.
>
> The abstractions take a `u32` parameter to ergonomically match the
> generated `bindings::CAP_*` constants without requiring explicit caller
> casts.
Do we have any users who need this? What's the use case and where will this be
used?
-Onur
>
> Signed-off-by: Arnav Sharma <arnav4324@gmail.com>
> ---
> rust/kernel/cred.rs | 79 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 79 insertions(+)
>
> diff --git a/rust/kernel/cred.rs b/rust/kernel/cred.rs
> index ffa156b9df37..6525b52b81ae 100644
> --- a/rust/kernel/cred.rs
> +++ b/rust/kernel/cred.rs
> @@ -90,3 +90,82 @@ unsafe fn dec_ref(obj: core::ptr::NonNull<Credential>) {
> unsafe { bindings::put_cred(obj.cast().as_ptr()) };
> }
> }
> +
> +/// Checks whether the current task has the given capability in the init user namespace.
> +///
> +/// This function tests whether the current task has the specified POSIX capability available for
> +/// use. The check is performed against the initial user namespace (`init_user_ns`).
> +///
> +/// When the check succeeds, the kernel sets the `PF_SUPERPRIV` flag on the current task. This
> +/// marks the task as having used superuser privileges, which is visible in process accounting
> +/// and auditing.
> +///
> +/// The capability constants are available as `bindings::CAP_*` values (for example,
> +/// [`bindings::CAP_NET_ADMIN`], [`bindings::CAP_SYS_ADMIN`]). These constants are defined in
> +/// `include/uapi/linux/capability.h`.
> +///
> +/// This function must be called from task (process) context only. Calling it from a context where
> +/// there is no valid `current` task (such as hard interrupt context) is not permitted.
> +///
> +/// # Preconditions
> +///
> +/// `cap` must be a valid capability constant in the range `[0, CAP_LAST_CAP]`.
> +/// Passing a value outside this range is a programming error and will trigger
> +/// a kernel `BUG()`.
> +///
> +/// C header: [`include/linux/capability.h`](srctree/include/linux/capability.h)
> +///
> +/// # Examples
> +///
> +/// ```
> +/// use kernel::bindings;
> +/// use kernel::cred::capable;
> +///
> +/// if !capable(bindings::CAP_SYS_ADMIN) {
> +/// return Err(EPERM);
> +/// }
> +/// # Ok::<(), Error>(())
> +/// ```
> +#[inline]
> +pub fn capable(cap: u32) -> bool {
> + // SAFETY: `capable()` is safe to call from task context. It checks `current_cred()` against
> + // the init user namespace and returns whether the specified capability is granted.
> + unsafe { bindings::capable(cap as i32) }
> +}
> +
> +/// Checks whether the current task has the given capability in the specified user namespace.
> +///
> +/// This is the namespace-aware variant of [`capable`]. It tests whether the current task has the
> +/// specified capability in the given user namespace, rather than in the init user namespace.
> +///
> +/// This function is relevant for code that must respect user namespace boundaries (for example,
> +/// operations inside unprivileged containers). For most driver code that is not namespace-aware,
> +/// [`capable`] is the correct function to use instead.
> +///
> +/// Like [`capable`], this function sets `PF_SUPERPRIV` on the current task when the check
> +/// succeeds, and it must be called from task context only.
> +///
> +/// # Preconditions
> +///
> +/// `cap` must be a valid capability constant in the range `[0, CAP_LAST_CAP]`.
> +/// Passing a value outside this range is a programming error and will trigger
> +/// a kernel `BUG()`.
> +///
> +/// C header: [`include/linux/capability.h`](srctree/include/linux/capability.h)
> +///
> +/// # Safety
> +///
> +/// The caller must ensure that:
> +///
> +/// - `ns` is a non-null pointer to a fully initialized `struct user_namespace`.
> +/// - The `user_namespace` pointed to by `ns` remains valid and is not freed for
> +/// the duration of this call.
> +#[inline]
> +pub unsafe fn ns_capable(ns: *mut bindings::user_namespace, cap: u32) -> bool {
> + // SAFETY: The caller guarantees that `ns` is a non-null, valid pointer to a fully initialized
> + // `struct user_namespace` that remains valid for the duration of this call.
> + // `ns_capable()` checks `current_cred()` against the provided namespace and returns whether
> + // the specified capability is granted.
> + unsafe { bindings::ns_capable(ns, cap as i32) }
> +}
> +
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH] rust: cred: add safe abstractions for capable() and ns_capable()
From: Alice Ryhl @ 2026-05-07 7:22 UTC (permalink / raw)
To: Arnav Sharma
Cc: ojeda, paul, Serge Hallyn, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Danilo Krummrich, linux-security-module,
rust-for-linux, linux-kernel
In-Reply-To: <20260506204913.26022-1-arnav4324@gmail.com>
On Thu, May 07, 2026 at 02:19:13AM +0530, Arnav Sharma wrote:
> The capable() function is the primary privilege gate in the Linux kernel,
> used to check if the current task possesses a specific POSIX capability.
> While bindings for capable() and ns_capable() exist, there are currently
> no safe Rust abstractions for them.
>
> Introduce safe Rust wrappers for capable() and ns_capable() in the
> kernel::cred module. These functions validate that the requested
> capability is within the valid [0, CAP_LAST_CAP] bounds before calling
> into the C side, ensuring that safe Rust code cannot inadvertently
> trigger a kernel BUG() on invalid inputs.
>
> The abstractions take a `u32` parameter to ergonomically match the
> generated `bindings::CAP_*` constants without requiring explicit caller
> casts.
>
> Signed-off-by: Arnav Sharma <arnav4324@gmail.com>
I have the same question about what the use-case for this is.
> +/// # Safety
> +///
> +/// The caller must ensure that:
> +///
> +/// - `ns` is a non-null pointer to a fully initialized `struct user_namespace`.
> +/// - The `user_namespace` pointed to by `ns` remains valid and is not freed for
> +/// the duration of this call.
> +#[inline]
> +pub unsafe fn ns_capable(ns: *mut bindings::user_namespace, cap: u32) -> bool {
I would add a UserNamespace struct so that this raw pointer could be
avoided, before I add this method.
Alice
^ permalink raw reply
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Roberto Sassu @ 2026-05-07 8:10 UTC (permalink / raw)
To: Mimi Zohar, Paul Moore
Cc: Yeoreum Yun, Jonathan McDowell, linux-security-module,
linux-kernel, linux-integrity, linux-arm-kernel, kvmarm, jmorris,
serge, roberto.sassu, dmitry.kasatkin, eric.snowberg, jarkko, jgg,
sudeep.holla, maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, noodles, sebastianene
In-Reply-To: <461ec995935e2b42a8414f6f87063ff2557bbfb4.camel@linux.ibm.com>
On Wed, 2026-05-06 at 22:25 -0400, Mimi Zohar wrote:
> On Tue, 2026-05-05 at 22:11 -0400, Paul Moore wrote:
> > On May 5, 2026 9:57:23 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > On Tue, 2026-05-05 at 18:55 -0400, Paul Moore wrote:
> > > > On Tue, May 5, 2026 at 5:05 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > On Mon, 2026-05-04 at 16:51 -0400, Paul Moore wrote:
> > > > > > On Mon, May 4, 2026 at 8:03 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > > > On Sun, 2026-05-03 at 12:46 -0400, Paul Moore wrote:
> > > > > > > > Regardless, assuming you always want IMA to leverage a TPMs when they
> > > > > > > > exist, your reply suggests that using an initcall based IMA init
> > > > > > > > scheme, even a late-sync initcall, may not be sufficient because
> > > > > > > > deferred TPM initialization could happen later, yes?
> > > > > > >
> > > > > > > Well yeah. The TPM could be configured as a module, but that scenario is
> > > > > > > not of
> > > > > > > interest. That's way too late. The case being addressed in this patch set is
> > > > > > > when the TPM driver tries to initialize at device_initcall, returns
> > > > > > > EPROBE_DEFER, and is retried at deferred_probe_initcall (late_initcall). Since
> > > > > > > ordering within an initcall is not supported, this patch attempts to initialize
> > > > > > > IMA at late_initcall and similarly retries, in this case, at
> > > > > > > late_initcall_sync.
> > > > > >
> > > > > > Okay, so from a TPM initialization perspective you are satisfied with
> > > > > > a late-sync IMA initialization, yes?
> > > > >
> > > > > No. On some architectures moving IMA initialization from the late_initcall to
> > > > > late_initcall_sync does not miss any measurement records. However, as
> > > > > previously
> > > > > mentioned, Linux running in a PowerVM LPAR the move would drop ~30 measurement
> > > > > records[1]. So no, only if the TPM is not initialized by late_initcall, should
> > > > > IMA retry at late_initcall_sync.
> > > >
> > > > What do you do in the PowerVM LPAR when the TPM is not avaiable at
> > > > late initcall and you have to defer IMA initialization until
> > > > late-sync?
> > >
> > > Your question is hypothetical ...
> >
> > <heavy eye roll>
> >
> > > ... as the TPM isn't deferred, so IMA doesn't go into
> > > TPM-bypass mode. Testing on a PowerVM LPAR demonstrated that it skips ~30
> > > measurement list records. So moving the initcall to late_initcall_sync would
> > > cause a regression.
> >
> > Let me rephrase to make the question clear - how do you plan to handle a
> > system where you lose measurements by waiting until late-sync, but the TPM
> > is not available at the late initcall.
>
> There have been suggestions to queue the IMA measurements, but that goes against
> the "measure before use" principle. The solution is not to defer IMA
> initialization for all systems, but to differentiate the boot_aggregate record
> (boot_aggregate vs. boot_aggregate_late) based on when the TPM becomes available
> relative to IMA's initcall. IMA's job is simply to collect and provide the
> measurement list. Based on the attestation service policy, the attestation
> service will decide whether a measurement list containing boot_aggregate_late is
> acceptable.
Agreed on no violation of the measure and load principle.
But also the two boot_aggregate solution does not work. If there are
measurements before boot_aggregate_late, they can corrupt the system
without noticing, and the corrupted system would emit the
boot_aggregate measurement (non-late) to pass verification.
Roberto
^ permalink raw reply
* Re: [PATCH] lockdown: remove useless decrement operation
From: Xiu Jianfeng @ 2026-05-07 9:38 UTC (permalink / raw)
To: Nicolas Bouchinet, Kalevi Kolttonen; +Cc: linux-security-module, xiujianfeng
In-Reply-To: <afm9F_neup5eiD5z@archlinux>
On 5/5/2026 5:51 PM, Nicolas Bouchinet wrote:
> Hi Kalevi, thanks for your contribution,
>
> While it is true the len variable decrementing is not used anywhere and
> that it would be cleaner to remove it, ideally we should go through a
> more in depth Lockdown code cleaning.
> I'll include it with Cai's one[1] when a more consequent patch will be
> ready. I'll thus keep it somewhere with the patch until then.
>
> I have a two week holiday starting this Friday and will thus not be available
> until the 26th of may. Xiu, and Cai, if you want to work on it I'll gladly
> review the patch set.
Hi Nicolas,
Have a nice holiday!
I'm in favor of a cleanup where it makes sense, but I don't see any
code that specifically needs it at the moment. Feel free to point out
any areas of concern when you have a moment.
>
> [1]: https://lore.kernel.org/all/20260119091226.3195309-1-caixinchen1@huawei.com/
>
> Best regards,
>
> Nicolas
^ permalink raw reply
* [PATCH v3 0/2] Delete task_euid()
From: Alice Ryhl @ 2026-05-07 9:48 UTC (permalink / raw)
To: Paul Moore, Serge Hallyn, Jonathan Corbet, Greg Kroah-Hartman,
Shuah Khan, Alex Shi, Yanteng Si, Dongliang Mu
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Jann Horn, linux-security-module, linux-doc, linux-kernel,
rust-for-linux, Alice Ryhl
The task_euid() method is a very weird method, and Binder was the only
user. As of commit 65b672152289 ("binder: use current_euid() for
transaction sender identity") Binder doesn't use task_euid() anymore,
so we can delete this method.
My suggestion would be to merge this through the LSM tree.
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
Changes in v3:
- Include 'task' clarification commit in series.
- Rebase and resend.
- Link to v2: https://lore.kernel.org/r/20260227-remove-task-euid-v2-1-9a9c80a82eb6@google.com
Changes in v2:
- Update translation as per Alex Shi.
- Pick up Reviewed-by Gary.
- Update commit title to use cred: prefix.
- Link to v1: https://lore.kernel.org/r/20260219-remove-task-euid-v1-1-904060826e07@google.com
---
Alice Ryhl (1):
cred: delete task_euid()
Jann Horn (1):
rust: task: clarify comments on task UID accessors
Documentation/security/credentials.rst | 6 ++----
Documentation/translations/zh_CN/security/credentials.rst | 4 +---
include/linux/cred.h | 1 -
rust/helpers/task.c | 5 -----
rust/kernel/task.rs | 11 ++---------
5 files changed, 5 insertions(+), 22 deletions(-)
---
base-commit: 7fd2df204f342fc17d1a0bfcd474b24232fb0f32
change-id: 20260219-remove-task-euid-19e4b00beebe
Best regards,
--
Alice Ryhl <aliceryhl@google.com>
^ permalink raw reply
* [PATCH v3 1/2] rust: task: clarify comments on task UID accessors
From: Alice Ryhl @ 2026-05-07 9:48 UTC (permalink / raw)
To: Paul Moore, Serge Hallyn, Jonathan Corbet, Greg Kroah-Hartman,
Shuah Khan, Alex Shi, Yanteng Si, Dongliang Mu
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Jann Horn, linux-security-module, linux-doc, linux-kernel,
rust-for-linux, Alice Ryhl
In-Reply-To: <20260507-remove-task-euid-v3-0-27f22f335c2c@google.com>
From: Jann Horn <jannh@google.com>
Linux has separate subjective and objective task credentials, see the
comment above `struct cred`. Clarify which accessor functions operate on
which set of credentials.
Also document that Task::euid() is a very weird operation. You can see how
weird it is by grepping for task_euid() - binder is its only user.
Task::euid() obtains the objective effective UID - it looks at the
credentials of the task for purposes of acting on it as an object, but then
accesses the effective UID (which the credentials.7 man page describes as
"[...] used by the kernel to determine the permissions that the process
will have when accessing shared resources [...]").
For context:
Arguably, binder's use of task_euid() is a theoretical security problem,
which only has no impact on Android because Android has no setuid binaries
executable by apps.
commit 29bc22ac5e5b ("binder: use euid from cred instead of using task")
fixed that by removing that only user of task_euid(), but the fix got
reverted in commit c21a80ca0684 ("binder: fix test regression due to
sender_euid change") because some Android test started failing.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
Originally sent as:
https://lore.kernel.org/r/20260212-rust-uid-v1-1-deff4214c766@google.com
---
rust/kernel/task.rs | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/rust/kernel/task.rs b/rust/kernel/task.rs
index 38273f4eedb5..7950c3a3950d 100644
--- a/rust/kernel/task.rs
+++ b/rust/kernel/task.rs
@@ -210,14 +210,17 @@ pub fn pid(&self) -> Pid {
unsafe { *ptr::addr_of!((*self.as_ptr()).pid) }
}
- /// Returns the UID of the given task.
+ /// Returns the objective real UID of the given task.
#[inline]
pub fn uid(&self) -> Kuid {
// SAFETY: It's always safe to call `task_uid` on a valid task.
Kuid::from_raw(unsafe { bindings::task_uid(self.as_ptr()) })
}
- /// Returns the effective UID of the given task.
+ /// Returns the objective effective UID of the given task.
+ ///
+ /// You should probably not be using this; the effective UID is normally
+ /// only relevant in subjective credentials.
#[inline]
pub fn euid(&self) -> Kuid {
// SAFETY: It's always safe to call `task_euid` on a valid task.
@@ -371,7 +374,7 @@ fn eq(&self, other: &Self) -> bool {
impl Eq for Task {}
impl Kuid {
- /// Get the current euid.
+ /// Get the current subjective euid.
#[inline]
pub fn current_euid() -> Kuid {
// SAFETY: Just an FFI call.
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v3 2/2] cred: delete task_euid()
From: Alice Ryhl @ 2026-05-07 9:48 UTC (permalink / raw)
To: Paul Moore, Serge Hallyn, Jonathan Corbet, Greg Kroah-Hartman,
Shuah Khan, Alex Shi, Yanteng Si, Dongliang Mu
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Jann Horn, linux-security-module, linux-doc, linux-kernel,
rust-for-linux, Alice Ryhl
In-Reply-To: <20260507-remove-task-euid-v3-0-27f22f335c2c@google.com>
task_euid() is a very weird operation. You can see how weird it is by
grepping for task_euid() - binder is its only user. task_euid() obtains
the objective effective UID - it looks at the credentials of the task
for purposes of acting on it as an object, but then accesses the
effective UID (which the credentials.7 man page describes as "[...] used
by the kernel to determine the permissions that the process will have
when accessing shared resources [...]").
Since usage in Binder has now been removed, get rid of the resulting
dead code.
Changes to the zh_CN translation was carried out with the help of
Gemini and Google Translate, and since adjusted as per Alex Shi's
feedback.
Suggested-by: Jann Horn <jannh@google.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
Documentation/security/credentials.rst | 6 ++----
Documentation/translations/zh_CN/security/credentials.rst | 4 +---
include/linux/cred.h | 1 -
rust/helpers/task.c | 5 -----
rust/kernel/task.rs | 10 ----------
5 files changed, 3 insertions(+), 23 deletions(-)
diff --git a/Documentation/security/credentials.rst b/Documentation/security/credentials.rst
index d0191c8b8060..81d3b5737d85 100644
--- a/Documentation/security/credentials.rst
+++ b/Documentation/security/credentials.rst
@@ -393,16 +393,14 @@ the credentials so obtained when they're finished with.
The result of ``__task_cred()`` should not be passed directly to
``get_cred()`` as this may race with ``commit_cred()``.
-There are a couple of convenience functions to access bits of another task's
-credentials, hiding the RCU magic from the caller::
+There is a convenience function to access bits of another task's credentials,
+hiding the RCU magic from the caller::
uid_t task_uid(task) Task's real UID
- uid_t task_euid(task) Task's effective UID
If the caller is holding the RCU read lock at the time anyway, then::
__task_cred(task)->uid
- __task_cred(task)->euid
should be used instead. Similarly, if multiple aspects of a task's credentials
need to be accessed, RCU read lock should be used, ``__task_cred()`` called,
diff --git a/Documentation/translations/zh_CN/security/credentials.rst b/Documentation/translations/zh_CN/security/credentials.rst
index 88fcd9152ffe..20c8696f8198 100644
--- a/Documentation/translations/zh_CN/security/credentials.rst
+++ b/Documentation/translations/zh_CN/security/credentials.rst
@@ -337,15 +337,13 @@ const指针上操作，因此不需要进行类型转换，但需要临时放弃
``__task_cred()`` 的结果不应直接传递给 ``get_cred()`` ，
因为这可能与 ``commit_cred()`` 发生竞争条件。
-还有一些方便的函数可以访问另一个任务凭据的特定部分，将RCU操作对调用方隐藏起来::
+有一个方便的函数可用于访问另一个任务凭据的特定部分，从而对调用方隐藏RCU机制::
uid_t task_uid(task) Task's real UID
- uid_t task_euid(task) Task's effective UID
如果调用方在此时已经持有RCU读锁，则应使用::
__task_cred(task)->uid
- __task_cred(task)->euid
类似地，如果需要访问任务凭据的多个方面，应使用RCU读锁，调用 ``__task_cred()``
函数，将结果存储在临时指针中，然后从临时指针中调用凭据的各个方面，最后释放锁。
diff --git a/include/linux/cred.h b/include/linux/cred.h
index c6676265a985..6ef1750c93e2 100644
--- a/include/linux/cred.h
+++ b/include/linux/cred.h
@@ -371,7 +371,6 @@ DEFINE_FREE(put_cred, struct cred *, if (!IS_ERR_OR_NULL(_T)) put_cred(_T))
})
#define task_uid(task) (task_cred_xxx((task), uid))
-#define task_euid(task) (task_cred_xxx((task), euid))
#define task_ucounts(task) (task_cred_xxx((task), ucounts))
#define current_cred_xxx(xxx) \
diff --git a/rust/helpers/task.c b/rust/helpers/task.c
index c0e1a06ede78..b46b1433a67e 100644
--- a/rust/helpers/task.c
+++ b/rust/helpers/task.c
@@ -28,11 +28,6 @@ __rust_helper kuid_t rust_helper_task_uid(struct task_struct *task)
return task_uid(task);
}
-__rust_helper kuid_t rust_helper_task_euid(struct task_struct *task)
-{
- return task_euid(task);
-}
-
#ifndef CONFIG_USER_NS
__rust_helper uid_t rust_helper_from_kuid(struct user_namespace *to, kuid_t uid)
{
diff --git a/rust/kernel/task.rs b/rust/kernel/task.rs
index 7950c3a3950d..e568dfab93c4 100644
--- a/rust/kernel/task.rs
+++ b/rust/kernel/task.rs
@@ -217,16 +217,6 @@ pub fn uid(&self) -> Kuid {
Kuid::from_raw(unsafe { bindings::task_uid(self.as_ptr()) })
}
- /// Returns the objective effective UID of the given task.
- ///
- /// You should probably not be using this; the effective UID is normally
- /// only relevant in subjective credentials.
- #[inline]
- pub fn euid(&self) -> Kuid {
- // SAFETY: It's always safe to call `task_euid` on a valid task.
- Kuid::from_raw(unsafe { bindings::task_euid(self.as_ptr()) })
- }
-
/// Determines whether the given task has pending signals.
#[inline]
pub fn signal_pending(&self) -> bool {
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* Re: [PATCH v3 1/2] rust: task: clarify comments on task UID accessors
From: Gary Guo @ 2026-05-07 11:08 UTC (permalink / raw)
To: Alice Ryhl, Paul Moore, Serge Hallyn, Jonathan Corbet,
Greg Kroah-Hartman, Shuah Khan, Alex Shi, Yanteng Si,
Dongliang Mu
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Jann Horn, linux-security-module, linux-doc, linux-kernel,
rust-for-linux
In-Reply-To: <20260507-remove-task-euid-v3-1-27f22f335c2c@google.com>
On Thu May 7, 2026 at 10:48 AM BST, Alice Ryhl wrote:
> From: Jann Horn <jannh@google.com>
>
> Linux has separate subjective and objective task credentials, see the
> comment above `struct cred`. Clarify which accessor functions operate on
> which set of credentials.
>
> Also document that Task::euid() is a very weird operation. You can see how
> weird it is by grepping for task_euid() - binder is its only user.
> Task::euid() obtains the objective effective UID - it looks at the
> credentials of the task for purposes of acting on it as an object, but then
> accesses the effective UID (which the credentials.7 man page describes as
> "[...] used by the kernel to determine the permissions that the process
> will have when accessing shared resources [...]").
>
> For context:
> Arguably, binder's use of task_euid() is a theoretical security problem,
> which only has no impact on Android because Android has no setuid binaries
> executable by apps.
> commit 29bc22ac5e5b ("binder: use euid from cred instead of using task")
> fixed that by removing that only user of task_euid(), but the fix got
> reverted in commit c21a80ca0684 ("binder: fix test regression due to
> sender_euid change") because some Android test started failing.
>
> Signed-off-by: Jann Horn <jannh@google.com>
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
> Originally sent as:
> https://lore.kernel.org/r/20260212-rust-uid-v1-1-deff4214c766@google.com
> ---
> rust/kernel/task.rs | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/rust/kernel/task.rs b/rust/kernel/task.rs
> index 38273f4eedb5..7950c3a3950d 100644
> --- a/rust/kernel/task.rs
> +++ b/rust/kernel/task.rs
> @@ -210,14 +210,17 @@ pub fn pid(&self) -> Pid {
> unsafe { *ptr::addr_of!((*self.as_ptr()).pid) }
> }
>
> - /// Returns the UID of the given task.
> + /// Returns the objective real UID of the given task.
> #[inline]
> pub fn uid(&self) -> Kuid {
> // SAFETY: It's always safe to call `task_uid` on a valid task.
> Kuid::from_raw(unsafe { bindings::task_uid(self.as_ptr()) })
> }
>
> - /// Returns the effective UID of the given task.
> + /// Returns the objective effective UID of the given task.
> + ///
> + /// You should probably not be using this; the effective UID is normally
> + /// only relevant in subjective credentials.
> #[inline]
> pub fn euid(&self) -> Kuid {
> // SAFETY: It's always safe to call `task_euid` on a valid task.
> @@ -371,7 +374,7 @@ fn eq(&self, other: &Self) -> bool {
> impl Eq for Task {}
>
> impl Kuid {
> - /// Get the current euid.
> + /// Get the current subjective euid.
For consistency this should be "subjective effective UID".
Best,
Gary
> #[inline]
> pub fn current_euid() -> Kuid {
> // SAFETY: Just an FFI call.
^ permalink raw reply
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Mimi Zohar @ 2026-05-07 11:28 UTC (permalink / raw)
To: Yeoreum Yun
Cc: David Safford, Jonathan McDowell, linux-security-module,
linux-kernel, linux-integrity, linux-arm-kernel, kvmarm, paul,
jmorris, serge, roberto.sassu, dmitry.kasatkin, eric.snowberg,
jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene
In-Reply-To: <afwoDgaJxmKwOhXp@e129823.arm.com>
On Thu, 2026-05-07 at 06:50 +0100, Yeoreum Yun wrote:
> Hi Mimi,
>
> > On Wed, 2026-05-06 at 14:57 +0100, Yeoreum Yun wrote:
> > > > > > On both Z and PowerVM, there are ~30 measurements between boot_aggregate and
> > > > > > boot_aggregate_late. For example, on PowerVM:
> > > > > >
> > > > > > # grep -n boot_aggregate
> > > > > > /sys/kernel/security/integrity/ima/ascii_runtime_measurements
> > > > > >
> > > > > > 1:10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig
> > > > > > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > > > > > boot_aggregate
> > > > > > 31:10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig
> > > > > > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > > > > > boot_aggregate_late
> > > > > >
> > > > > > It would be interesting to the results from a Raspberry Pi 5 as well,
> > > > > > with/without a TPM.
> > > > >
> > > > > Honestly, I find this result hard to accept.
> > > > >
> > > > > This effectively means that there is code invoking IMA measurement during late_initcall().
> > > > > It also implies that if, in the future, a late_initcall is added that performs
> > > > > an IMA measurement before IMA initialization has occurred accoding to order by linker,
> > > > > that measurement could be missed.
> > > >
> > > > Exactly. The results are simply from booting with the builtin "tcb" and
> > > > "critical_data" policies.
> > > >
> > > > $ sudo grubby --args="ima_policy=\"tcb|critical_data\"" --update-kernel
> > > > /boot/vmlinuz-${SUFFIX}
> > >
> > > Thanks. but I still wonder what meaasurements there are between
> > > boot_aggregate and boot_aggregate_late.
> > > Might be there would be key measurements if it takes more than
> > > 5 mins before generating boot_aggregate_late but this seems rare.
> > >
> > > If you don't mind, would you share the contents of the log between
> > > boot_aggregate and boot_aggregate_late?
> > > since I only get a kernel_version in my environment.
> >
> > 1 10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig
> > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > boot_aggregate
> > 2 10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf
> > sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2
> > kernel_version 372e312e302d7263312b
> > 3 10 92c40bfd65512d5224cddb9fb64fef0d72e1c182 ima-sig
> > sha256:412bae0d0e85a99971d6eda198dd2fed3c2959715e8a17a4caddc7bc605bdeeb
> > /usr/bin/kmod
> > 4 10 a18f997e1e82d0ef416f93683966d7dda875d71c ima-sig
> > sha256:0050fcc672e03cfdc3a50c771ca9f5219478e5538980a26fd4484620712d8163
> > /usr/lib64/ld64.so.2
> > 5 10 88f343618caeeed92ed8281d627f4565b0499d66 ima-sig
> > sha256:a0e83c084d8c227f1150a8cd94eece61f62bc1da30f98d1cf57ca7db241a9c45
> > /etc/ld.so.cache
> > 6 10 e047868f01908eb95aa180693291decab82bb6be ima-sig
> > sha256:42ebf9cc684419de4d8a1d624102716d88fbcf957f47e50a9a08e38b338023ac
> > /usr/lib64/libzstd.so.1.5.5
> > 7 10 da069bc6a44d454510a76c69d3a54c3b238ae27e ima-sig
> > sha256:9b7c788e75c16c8827062016cf15826e43661c4b5b56813ea07ff2635bea2710
> > /usr/lib64/liblzma.so.5.6.2
> > 8 10 7ade414e736e7b449cda5ec5e0277b99548e89c6 ima-sig
> > sha256:d899452e8e6369e436ba1a565833d6dcf0d09c35e40ffc0979cf4de2bdb8f421
> > /usr/lib64/libz.so.1.3.1.zlib-ng
> > 9 10 9a9da8326f36237a47d6ed21bdffd0e1ff855e2a ima-sig
> > sha256:a848f396db7ad135f851b5e9aeb32f4a3ef1439c7913b9b95ab1cda69251f6ad
> > /usr/lib64/libcrypto.so.3.5.1
> > 10 10 3201d27cd4028f02fc9088ec33e2d0ceb72d2c5b ima-sig
> > sha256:e52dcd1850555c08d60fefe56694c1179b4eaa5796db0907606552ece8e1bab1
> > /usr/lib64/libgcc_s-14-20250617.so.1
> > 11 10 3b4c6f13e52ca060b290709f737b1ff66564226f ima-sig
> > sha256:f2a900a5b980b289dc028dd3caab16b1b0ad037f2e875546bb3197d23ff241f0
> > /usr/lib64/glibc-hwcaps/power10/libc.so.6
> > 12 10 b23b616cbd3c9dc4c5743d121c1c5a702b461a9c ima-sig
> > sha256:5a682022beeea9ee7f36a70f0465942bf32e9675d3f45355088e148787e02175
> > /usr/lib/modprobe.d/dist-alsa.conf
> > 13 10 aec07fad18697f295d7e06796fc8dfd3b472f9c3 ima-sig
> > sha256:067d949bab3bb085d0936031881ff73b2ab39f34b9a90cbd01396d1987ff6658
> > /usr/lib/modprobe.d/dist-blacklist.conf
> > 14 10 c402c56b66e65914148efd6e3cf0b1d616daabe6 ima-sig
> > sha256:120a02e9b88ba74949224eca7385825e39880f5687f739ade07d94ee22ffe325
> > /etc/modprobe.d/firewalld-sysctls.conf
> > 15 10 e358ca12bd58e1ce4845e299e1aea8b81edf86f9 ima-sig
> > sha256:fa27abcd357a16ee1254ba38d1225b7f0724036c07ce3d0e83b29eb72d97c419
> > /etc/modprobe.d/l2tp_eth-blacklist.conf
> > 16 10 4b036d41435d7df3a72b38880f5fe231904b7b66 ima-sig
> > sha256:ecf5f948bfbfb726879a910b3174d139c8af6b1745c88dcc1e4a1cf532c02299
> > /etc/modprobe.d/l2tp_ip-blacklist.conf
> > 17 10 9c53a7a48c1b5218417c4f25c4a34c09a9f39830 ima-sig
> > sha256:f76c4ac232d5e96c57961a9f10194703b4df6d119530046f0b23eee70bfcb089
> > /etc/modprobe.d/l2tp_ip6-blacklist.conf
> > 18 10 6c41d7b7d251c400b7e0ba76f7b386a746e8f4ec ima-sig
> > sha256:5cbc958f893a599ef19437014696dd7b112cf9af6a4348830177f8a8f78aa1b3
> > /etc/modprobe.d/l2tp_netlink-blacklist.conf
> > 19 10 f37ef48faef5bc51e29d47531726af0bd0654655 ima-sig
> > sha256:7a3d63acb49e4a69b482f26624761b5778fbd6b77be8a3f36926b379b5f965ed
> > /etc/modprobe.d/l2tp_ppp-blacklist.conf
> > 20 10 82ef59779acdfd6e9b35521bfa09e6ba86fd6174 ima-sig
> > sha256:6a8f2009d87deba7a2de46e3d0c46b114fe388d188b00b9a382fc2156aabb676
> > /usr/lib/modules/7.1.0-rc1+/modules.softdep
> > 21 10 6ae994e33a6313ab4535da90f5cb6c3beaec7b86 ima-sig
> > sha256:268695dbf23bd0170ec9a95b10e8d596205fd7436617d10101907171bf004b7c
> > /etc/modprobe.d/sctp-blacklist.conf
> > 22 10 b2c238ae66b03f56191d9955a5ad0f3110bb7e2b ima-sig
> > sha256:64a8ebb0a1fd712a9aeb7aa0f0ad0b72d3277034c8bfa3b66ab063e201d6527e
> > /etc/modprobe.d/sctp_diag-blacklist.conf
> > 23 10 c0443f2d3c078959ae86276df23abe172234a55d ima-sig
> > sha256:e5a3958cbd3684b63f3cada6604469cc56f727b106d5524daf5aefa6935a48ce
> > /usr/lib/modprobe.d/systemd.conf
> > 24 10 5c46e012bc7fffc3256b166282a7eaa4bea5fa33 ima-sig
> > sha256:6560abcdd2cdb41e1d0fe73052298d612920d5bccb4a3a7c82bc73895128e760
> > /etc/modprobe.d/tipc_diag-blacklist.conf
> > 25 10 d5fb1836364732fbc4f87aa7d2c984cf30bdbfd3 ima-sig
> > sha256:358703c09ac2d2c653e11bbc7c65d378c8496e87ca47307f86c36b0b29640598
> > /etc/modprobe.d/tuned.conf
> > 26 10 a85107163729f696f316d46c0bf3f65f713ba972 ima-sig
> > sha256:7410bb4cec56892e8b0010c5c8b72be532784ccf0240aa0677c5be085a530f65
> > /usr/lib/modules/7.1.0-rc1+/modules.dep.bin
> > 27 10 80eb261ffb2cc3528d90c33b1c624f657a045867 ima-sig
> > sha256:856e0f083226f8b4fb7d1d71447fb841dae18ea9a50ea6d8505a206167288e1d
> > /usr/lib/modules/7.1.0-rc1+/modules.alias.bin
> > 28 10 6af2d661da470d7a1c9909ddbc074d3d265eb1d7 ima-sig
> > sha256:4853ca200598c52970c380fda99484068e7db4961a4f94faac6abcfbbd52d150
> > /usr/lib/modules/7.1.0-rc1+/modules.symbols.bin
> > 29 10 6f9cd405bd57d925baae6ae66c273c61c90b3bc8 ima-sig
> > sha256:193d1e1004848f7d391877507b69a7953e1f94ddbe70eb0e2cf6dc45fce7cd6a
> > /usr/lib/modules/7.1.0-rc1+/modules.builtin.alias.bin
> > 30 10 4e20b980bf3a825a866be0c46033ed654df4aeba ima-sig
> > sha256:3a0e3c56d51ba98258ff13f93f82c837de22f4b707d24678f82893babf4d77ea
> > /usr/lib/modules/7.1.0-rc1+/modules.builtin.bin
> > 31 10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig
> > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > boot_aggregate_late
> > 32 10 81830cd3d799e006698258dc1b11fe29a56eeef5 ima-sig
> > sha256:d1651dc50bb5b92c1badcab9aa4dbbca40cb704cdc707d1c536b41d7b1aa465e
> > /usr/lib/systemd/systemd
>
> Hmm... Theses measurements seems to happen while populating
> initramfs which triggers file_post_open as async
> (and I see the RAMFS seems not part of DONT_MEASURE in IMA).
>
> If you don't mind, Could you check whether this measurements still
> happen with initramfs_async=0?
>
> If this measurements aren't generated with above option,
> there is a question whether let IMA measure initramfs which can be
> measured or not depending on boot option or timing (some file measurements
> could be lost all when do_populate_rootfs() executes concurrently while
> running late_initcall).
There's no difference when adding the "initramfs_async=0" boot command line
argument. The measurement list between boot_aggregate and boot_aggregate_late is
exactly the same.
Mimi
^ permalink raw reply
* Re: [PATCH v3 1/2] rust: task: clarify comments on task UID accessors
From: Alice Ryhl @ 2026-05-07 12:03 UTC (permalink / raw)
To: Gary Guo
Cc: Paul Moore, Serge Hallyn, Jonathan Corbet, Greg Kroah-Hartman,
Shuah Khan, Alex Shi, Yanteng Si, Dongliang Mu, Miguel Ojeda,
Boqun Feng, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Danilo Krummrich, Jann Horn, linux-security-module,
linux-doc, linux-kernel, rust-for-linux
In-Reply-To: <DICEBGUAU4OT.244JDJIKXRHBS@garyguo.net>
On Thu, May 07, 2026 at 12:08:35PM +0100, Gary Guo wrote:
> On Thu May 7, 2026 at 10:48 AM BST, Alice Ryhl wrote:
> > - /// Returns the UID of the given task.
> > + /// Returns the objective real UID of the given task.
> > #[inline]
> > pub fn uid(&self) -> Kuid {
> > // SAFETY: It's always safe to call `task_uid` on a valid task.
> > Kuid::from_raw(unsafe { bindings::task_uid(self.as_ptr()) })
> > }
> >
> > - /// Returns the effective UID of the given task.
> > + /// Returns the objective effective UID of the given task.
> > + ///
> > + /// You should probably not be using this; the effective UID is normally
> > + /// only relevant in subjective credentials.
> > #[inline]
> > pub fn euid(&self) -> Kuid {
> > // SAFETY: It's always safe to call `task_euid` on a valid task.
> > @@ -371,7 +374,7 @@ fn eq(&self, other: &Self) -> bool {
> > impl Eq for Task {}
> >
> > impl Kuid {
> > - /// Get the current euid.
> > + /// Get the current subjective euid.
>
> For consistency this should be "subjective effective UID".
I can update this for the next version.
Alice
^ permalink raw reply
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Yeoreum Yun @ 2026-05-07 12:41 UTC (permalink / raw)
To: Mimi Zohar
Cc: David Safford, Jonathan McDowell, linux-security-module,
linux-kernel, linux-integrity, linux-arm-kernel, kvmarm, paul,
jmorris, serge, roberto.sassu, dmitry.kasatkin, eric.snowberg,
jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene
In-Reply-To: <f19081f1eda19d6d1ae133d8ec93e779ab1a25e5.camel@linux.ibm.com>
Hi Mimi,
> On Thu, 2026-05-07 at 06:50 +0100, Yeoreum Yun wrote:
> > Hi Mimi,
> >
> > > On Wed, 2026-05-06 at 14:57 +0100, Yeoreum Yun wrote:
> > > > > > > On both Z and PowerVM, there are ~30 measurements between boot_aggregate and
> > > > > > > boot_aggregate_late. For example, on PowerVM:
> > > > > > >
> > > > > > > # grep -n boot_aggregate
> > > > > > > /sys/kernel/security/integrity/ima/ascii_runtime_measurements
> > > > > > >
> > > > > > > 1:10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig
> > > > > > > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > > > > > > boot_aggregate
> > > > > > > 31:10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig
> > > > > > > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > > > > > > boot_aggregate_late
> > > > > > >
> > > > > > > It would be interesting to the results from a Raspberry Pi 5 as well,
> > > > > > > with/without a TPM.
> > > > > >
> > > > > > Honestly, I find this result hard to accept.
> > > > > >
> > > > > > This effectively means that there is code invoking IMA measurement during late_initcall().
> > > > > > It also implies that if, in the future, a late_initcall is added that performs
> > > > > > an IMA measurement before IMA initialization has occurred accoding to order by linker,
> > > > > > that measurement could be missed.
> > > > >
> > > > > Exactly. The results are simply from booting with the builtin "tcb" and
> > > > > "critical_data" policies.
> > > > >
> > > > > $ sudo grubby --args="ima_policy=\"tcb|critical_data\"" --update-kernel
> > > > > /boot/vmlinuz-${SUFFIX}
> > > >
> > > > Thanks. but I still wonder what meaasurements there are between
> > > > boot_aggregate and boot_aggregate_late.
> > > > Might be there would be key measurements if it takes more than
> > > > 5 mins before generating boot_aggregate_late but this seems rare.
> > > >
> > > > If you don't mind, would you share the contents of the log between
> > > > boot_aggregate and boot_aggregate_late?
> > > > since I only get a kernel_version in my environment.
> > >
> > > 1 10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig
> > > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > > boot_aggregate
> > > 2 10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf
> > > sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2
> > > kernel_version 372e312e302d7263312b
> > > 3 10 92c40bfd65512d5224cddb9fb64fef0d72e1c182 ima-sig
> > > sha256:412bae0d0e85a99971d6eda198dd2fed3c2959715e8a17a4caddc7bc605bdeeb
> > > /usr/bin/kmod
> > > 4 10 a18f997e1e82d0ef416f93683966d7dda875d71c ima-sig
> > > sha256:0050fcc672e03cfdc3a50c771ca9f5219478e5538980a26fd4484620712d8163
> > > /usr/lib64/ld64.so.2
> > > 5 10 88f343618caeeed92ed8281d627f4565b0499d66 ima-sig
> > > sha256:a0e83c084d8c227f1150a8cd94eece61f62bc1da30f98d1cf57ca7db241a9c45
> > > /etc/ld.so.cache
> > > 6 10 e047868f01908eb95aa180693291decab82bb6be ima-sig
> > > sha256:42ebf9cc684419de4d8a1d624102716d88fbcf957f47e50a9a08e38b338023ac
> > > /usr/lib64/libzstd.so.1.5.5
> > > 7 10 da069bc6a44d454510a76c69d3a54c3b238ae27e ima-sig
> > > sha256:9b7c788e75c16c8827062016cf15826e43661c4b5b56813ea07ff2635bea2710
> > > /usr/lib64/liblzma.so.5.6.2
> > > 8 10 7ade414e736e7b449cda5ec5e0277b99548e89c6 ima-sig
> > > sha256:d899452e8e6369e436ba1a565833d6dcf0d09c35e40ffc0979cf4de2bdb8f421
> > > /usr/lib64/libz.so.1.3.1.zlib-ng
> > > 9 10 9a9da8326f36237a47d6ed21bdffd0e1ff855e2a ima-sig
> > > sha256:a848f396db7ad135f851b5e9aeb32f4a3ef1439c7913b9b95ab1cda69251f6ad
> > > /usr/lib64/libcrypto.so.3.5.1
> > > 10 10 3201d27cd4028f02fc9088ec33e2d0ceb72d2c5b ima-sig
> > > sha256:e52dcd1850555c08d60fefe56694c1179b4eaa5796db0907606552ece8e1bab1
> > > /usr/lib64/libgcc_s-14-20250617.so.1
> > > 11 10 3b4c6f13e52ca060b290709f737b1ff66564226f ima-sig
> > > sha256:f2a900a5b980b289dc028dd3caab16b1b0ad037f2e875546bb3197d23ff241f0
> > > /usr/lib64/glibc-hwcaps/power10/libc.so.6
> > > 12 10 b23b616cbd3c9dc4c5743d121c1c5a702b461a9c ima-sig
> > > sha256:5a682022beeea9ee7f36a70f0465942bf32e9675d3f45355088e148787e02175
> > > /usr/lib/modprobe.d/dist-alsa.conf
> > > 13 10 aec07fad18697f295d7e06796fc8dfd3b472f9c3 ima-sig
> > > sha256:067d949bab3bb085d0936031881ff73b2ab39f34b9a90cbd01396d1987ff6658
> > > /usr/lib/modprobe.d/dist-blacklist.conf
> > > 14 10 c402c56b66e65914148efd6e3cf0b1d616daabe6 ima-sig
> > > sha256:120a02e9b88ba74949224eca7385825e39880f5687f739ade07d94ee22ffe325
> > > /etc/modprobe.d/firewalld-sysctls.conf
> > > 15 10 e358ca12bd58e1ce4845e299e1aea8b81edf86f9 ima-sig
> > > sha256:fa27abcd357a16ee1254ba38d1225b7f0724036c07ce3d0e83b29eb72d97c419
> > > /etc/modprobe.d/l2tp_eth-blacklist.conf
> > > 16 10 4b036d41435d7df3a72b38880f5fe231904b7b66 ima-sig
> > > sha256:ecf5f948bfbfb726879a910b3174d139c8af6b1745c88dcc1e4a1cf532c02299
> > > /etc/modprobe.d/l2tp_ip-blacklist.conf
> > > 17 10 9c53a7a48c1b5218417c4f25c4a34c09a9f39830 ima-sig
> > > sha256:f76c4ac232d5e96c57961a9f10194703b4df6d119530046f0b23eee70bfcb089
> > > /etc/modprobe.d/l2tp_ip6-blacklist.conf
> > > 18 10 6c41d7b7d251c400b7e0ba76f7b386a746e8f4ec ima-sig
> > > sha256:5cbc958f893a599ef19437014696dd7b112cf9af6a4348830177f8a8f78aa1b3
> > > /etc/modprobe.d/l2tp_netlink-blacklist.conf
> > > 19 10 f37ef48faef5bc51e29d47531726af0bd0654655 ima-sig
> > > sha256:7a3d63acb49e4a69b482f26624761b5778fbd6b77be8a3f36926b379b5f965ed
> > > /etc/modprobe.d/l2tp_ppp-blacklist.conf
> > > 20 10 82ef59779acdfd6e9b35521bfa09e6ba86fd6174 ima-sig
> > > sha256:6a8f2009d87deba7a2de46e3d0c46b114fe388d188b00b9a382fc2156aabb676
> > > /usr/lib/modules/7.1.0-rc1+/modules.softdep
> > > 21 10 6ae994e33a6313ab4535da90f5cb6c3beaec7b86 ima-sig
> > > sha256:268695dbf23bd0170ec9a95b10e8d596205fd7436617d10101907171bf004b7c
> > > /etc/modprobe.d/sctp-blacklist.conf
> > > 22 10 b2c238ae66b03f56191d9955a5ad0f3110bb7e2b ima-sig
> > > sha256:64a8ebb0a1fd712a9aeb7aa0f0ad0b72d3277034c8bfa3b66ab063e201d6527e
> > > /etc/modprobe.d/sctp_diag-blacklist.conf
> > > 23 10 c0443f2d3c078959ae86276df23abe172234a55d ima-sig
> > > sha256:e5a3958cbd3684b63f3cada6604469cc56f727b106d5524daf5aefa6935a48ce
> > > /usr/lib/modprobe.d/systemd.conf
> > > 24 10 5c46e012bc7fffc3256b166282a7eaa4bea5fa33 ima-sig
> > > sha256:6560abcdd2cdb41e1d0fe73052298d612920d5bccb4a3a7c82bc73895128e760
> > > /etc/modprobe.d/tipc_diag-blacklist.conf
> > > 25 10 d5fb1836364732fbc4f87aa7d2c984cf30bdbfd3 ima-sig
> > > sha256:358703c09ac2d2c653e11bbc7c65d378c8496e87ca47307f86c36b0b29640598
> > > /etc/modprobe.d/tuned.conf
> > > 26 10 a85107163729f696f316d46c0bf3f65f713ba972 ima-sig
> > > sha256:7410bb4cec56892e8b0010c5c8b72be532784ccf0240aa0677c5be085a530f65
> > > /usr/lib/modules/7.1.0-rc1+/modules.dep.bin
> > > 27 10 80eb261ffb2cc3528d90c33b1c624f657a045867 ima-sig
> > > sha256:856e0f083226f8b4fb7d1d71447fb841dae18ea9a50ea6d8505a206167288e1d
> > > /usr/lib/modules/7.1.0-rc1+/modules.alias.bin
> > > 28 10 6af2d661da470d7a1c9909ddbc074d3d265eb1d7 ima-sig
> > > sha256:4853ca200598c52970c380fda99484068e7db4961a4f94faac6abcfbbd52d150
> > > /usr/lib/modules/7.1.0-rc1+/modules.symbols.bin
> > > 29 10 6f9cd405bd57d925baae6ae66c273c61c90b3bc8 ima-sig
> > > sha256:193d1e1004848f7d391877507b69a7953e1f94ddbe70eb0e2cf6dc45fce7cd6a
> > > /usr/lib/modules/7.1.0-rc1+/modules.builtin.alias.bin
> > > 30 10 4e20b980bf3a825a866be0c46033ed654df4aeba ima-sig
> > > sha256:3a0e3c56d51ba98258ff13f93f82c837de22f4b707d24678f82893babf4d77ea
> > > /usr/lib/modules/7.1.0-rc1+/modules.builtin.bin
> > > 31 10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig
> > > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > > boot_aggregate_late
> > > 32 10 81830cd3d799e006698258dc1b11fe29a56eeef5 ima-sig
> > > sha256:d1651dc50bb5b92c1badcab9aa4dbbca40cb704cdc707d1c536b41d7b1aa465e
> > > /usr/lib/systemd/systemd
> >
> > Hmm... Theses measurements seems to happen while populating
> > initramfs which triggers file_post_open as async
> > (and I see the RAMFS seems not part of DONT_MEASURE in IMA).
> >
> > If you don't mind, Could you check whether this measurements still
> > happen with initramfs_async=0?
> >
> > If this measurements aren't generated with above option,
> > there is a question whether let IMA measure initramfs which can be
> > measured or not depending on boot option or timing (some file measurements
> > could be lost all when do_populate_rootfs() executes concurrently while
> > running late_initcall).
>
> There's no difference when adding the "initramfs_async=0" boot command line
> argument. The measurement list between boot_aggregate and boot_aggregate_late is
> exactly the same.
>
That's quite interesting. This means there're some file operation
between late_initcall and late_initcall_sync
even before run_init_process() except initramfs population.
Since initramfs population flush all fputs() it generates and
boot_aggregate_late is generated before init process is loaded,
I honestly have no idea who triggers above file operations.
And it seems a little bit weird that it opens the /usr/bin/kmod
and its configuration from kernel not by init_process or other user
process...
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Mimi Zohar @ 2026-05-07 14:00 UTC (permalink / raw)
To: Roberto Sassu, Paul Moore
Cc: Yeoreum Yun, Jonathan McDowell, linux-security-module,
linux-kernel, linux-integrity, linux-arm-kernel, kvmarm, jmorris,
serge, roberto.sassu, dmitry.kasatkin, eric.snowberg, jarkko, jgg,
sudeep.holla, maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, noodles, sebastianene
In-Reply-To: <8c99263d8e63100e0b5e6c8cf739f7f6e7e79f6b.camel@huaweicloud.com>
On Thu, 2026-05-07 at 10:10 +0200, Roberto Sassu wrote:
> On Wed, 2026-05-06 at 22:25 -0400, Mimi Zohar wrote:
> > On Tue, 2026-05-05 at 22:11 -0400, Paul Moore wrote:
> > > On May 5, 2026 9:57:23 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > On Tue, 2026-05-05 at 18:55 -0400, Paul Moore wrote:
> > > > > On Tue, May 5, 2026 at 5:05 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > > On Mon, 2026-05-04 at 16:51 -0400, Paul Moore wrote:
> > > > > > > On Mon, May 4, 2026 at 8:03 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > > > > On Sun, 2026-05-03 at 12:46 -0400, Paul Moore wrote:
> > > > > > > > > Regardless, assuming you always want IMA to leverage a TPMs when they
> > > > > > > > > exist, your reply suggests that using an initcall based IMA init
> > > > > > > > > scheme, even a late-sync initcall, may not be sufficient because
> > > > > > > > > deferred TPM initialization could happen later, yes?
> > > > > > > >
> > > > > > > > Well yeah. The TPM could be configured as a module, but that scenario is
> > > > > > > > not of
> > > > > > > > interest. That's way too late. The case being addressed in this patch set is
> > > > > > > > when the TPM driver tries to initialize at device_initcall, returns
> > > > > > > > EPROBE_DEFER, and is retried at deferred_probe_initcall (late_initcall). Since
> > > > > > > > ordering within an initcall is not supported, this patch attempts to initialize
> > > > > > > > IMA at late_initcall and similarly retries, in this case, at
> > > > > > > > late_initcall_sync.
> > > > > > >
> > > > > > > Okay, so from a TPM initialization perspective you are satisfied with
> > > > > > > a late-sync IMA initialization, yes?
> > > > > >
> > > > > > No. On some architectures moving IMA initialization from the late_initcall to
> > > > > > late_initcall_sync does not miss any measurement records. However, as
> > > > > > previously
> > > > > > mentioned, Linux running in a PowerVM LPAR the move would drop ~30 measurement
> > > > > > records[1]. So no, only if the TPM is not initialized by late_initcall, should
> > > > > > IMA retry at late_initcall_sync.
> > > > >
> > > > > What do you do in the PowerVM LPAR when the TPM is not avaiable at
> > > > > late initcall and you have to defer IMA initialization until
> > > > > late-sync?
> > > >
> > > > Your question is hypothetical ...
> > >
> > > <heavy eye roll>
> > >
> > > > ... as the TPM isn't deferred, so IMA doesn't go into
> > > > TPM-bypass mode. Testing on a PowerVM LPAR demonstrated that it skips ~30
> > > > measurement list records. So moving the initcall to late_initcall_sync would
> > > > cause a regression.
> > >
> > > Let me rephrase to make the question clear - how do you plan to handle a
> > > system where you lose measurements by waiting until late-sync, but the TPM
> > > is not available at the late initcall.
> >
> > There have been suggestions to queue the IMA measurements, but that goes against
> > the "measure before use" principle. The solution is not to defer IMA
> > initialization for all systems, but to differentiate the boot_aggregate record
> > (boot_aggregate vs. boot_aggregate_late) based on when the TPM becomes available
> > relative to IMA's initcall. IMA's job is simply to collect and provide the
> > measurement list. Based on the attestation service policy, the attestation
> > service will decide whether a measurement list containing boot_aggregate_late is
> > acceptable.
>
> Agreed on no violation of the measure and load principle.
>
> But also the two boot_aggregate solution does not work. If there are
> measurements before boot_aggregate_late, they can corrupt the system
> without noticing, and the corrupted system would emit the
> boot_aggregate measurement (non-late) to pass verification.
This is a risk management issue. The conservative option is to continue
initializing IMA only at late_initcall, as we have been doing, and accept the
late TPM initialization limitation. The alternative is to also allow IMA to
initialize at late_initcall_sync, controlled by a Kconfig option, so that
existing systems are unaffected while systems with late TPM initialization can
opt in to boot_aggregate_late support.
Mimi
^ permalink raw reply
* Re: [PATCH v5 00/13] ima: Introduce staging mechanism
From: steven chen @ 2026-05-07 16:47 UTC (permalink / raw)
To: Roberto Sassu, corbet, skhan, zohar, dmitry.kasatkin,
eric.snowberg, paul, jmorris, serge
Cc: linux-doc, linux-kernel, linux-integrity, linux-security-module,
gregorylumen, nramas, Roberto Sassu, steven chen
In-Reply-To: <20260429160319.4162918-1-roberto.sassu@huaweicloud.com>
On 4/29/2026 9:03 AM, Roberto Sassu wrote:
> From: Roberto Sassu <roberto.sassu@huawei.com>
>
> Introduction
> ============
>
> The IMA measurements list is currently stored in the kernel memory.
> Memory occupation grows linearly with the number of entries, and can
> become a problem especially in environments with reduced resources.
>
> While there is an advantage in keeping the IMA measurements list in
> kernel memory, so that it is always available for reading from the
> securityfs interfaces, storing it elsewhere would make it possible to
> free precious memory for other kernel components.
>
> Storing the IMA measurements list outside the kernel does not introduce
> security issues, since its integrity is anyway protected by the TPM.
>
> Hence, the new IMA staging mechanism is introduced to allow user space
> to remove the desired portion of the measurements list from the kernel.
>
>
> Usage
> =====
>
> The IMA staging mechanism can be enabled from the kernel configuration
> with the CONFIG_IMA_STAGING option.
>
> If it is enabled, IMA duplicates the current measurements interfaces
> (both binary and ASCII), by adding the _staged file suffix. Both the
> original and the staging interfaces gain the write permission for the
> root user and group, but require the process to have CAP_SYS_ADMIN set.
>
> The staging mechanism supports two flavors.
>
> Staging with prompt
> ~~~~~~~~~~~~~~~~~~~
>
> The current measurements list is moved to a temporary staging area, and
> staged measurements are deleted upon confirmation.
>
> This staging process is achieved with the following steps.
>
> 1. echo A > <original interface>: the user requests IMA to stage the
> entire measurements list;
> 2. cat <_staged interface>: the user reads the staged measurements;
> 3. echo D > <_staged interface>: the user requests IMA to delete
> staged measurements.
>
> Staging and deleting
> ~~~~~~~~~~~~~~~~~~~~
>
> N measurements are staged to a temporary staging area, and immediately
> deleted without further confirmation.
>
> This staging process is achieved with the following steps.
>
> 1. cat <original interface>: the user reads the current measurements
> list and determines what the value N for staging should be;
> 2. echo N > <original interface>: the user requests IMA to delete N
> measurements from the current measurements list.
This submission proposes two ways for log trimming:
*Favour 1:* Staging with prompt
*Favour 2:* stage and delete N
Functionally, both approaches address the same problem, but *Favour 2
*is the
stronger design and should be preferred. There is no good reason to keep
*Favour 1.*
From a kernel implementation perspective, *Favour 2 *is more efficient
because it
minimizes the time spent holding the list lock (can’t be shorter). It
also substantially
reduces the amount of kernel-side logic, removing nearly half of the
code required
by the alternative approach.
From a user-space perspective, *Favour 2 *results in a much cleaner
model. It avoids
the need to track and reconcile both old and staged lists in user space
as well as
two lists (cur and staged) in the kernel space, which simplifies log
trimming logic
and reduces maintenance overhead. In addition, it preserves the existing
external
behavior by not exposing any staged list to user space.
Overall, *Favour 2 *provides the same functional result with lower
kernel complexity,
shorter kernel list lock hold time, and a simpler user-space interface.
For those
reasons, it is the preferable approach and *Favour 1* does not appear to
offer sufficient
justification to keep both implementations.
Steven
>
> Management of Staged Measurements
> =================================
>
> Since with the staging mechanism measurement entries are removed from
> the kernel, the user needs to save the staged ones in a storage and
> concatenate them together, so that it can present them to remote
> attestation agents as if staging was never done.
>
>
> Patch set content
> =================
>
> Patches 1-8 are preparatory patches to quickly replace the hash table,
> maintain separate counters for the different measurements list types,
> mediate access to the measurements list interface, and simplify the staging
> patches.
>
> Patch 9 introduces the staging with prompt flavor. Patch 10 makes it
> possible to flush the hash table when deleting all the staged measurements.
> Patch 11 introduces the staging and deleting flavor. Patch 12 avoids
> measurements entries to be stored twice if there is contention between the
> measurements interfaces and kexec. Patch 13 adds the documentation of the
> staging mechanism.
>
>
> Changelog
> =========
>
> v4:
> - Add write permission to the original measurement interface, and move
> the A and N staging commands to that interface
> - Explain better the two staging flavors and highlight that the staging
> and delete only stages measurements internally
> - Rename ima_queue_staged_delete_partial() to ima_queue_delete_partial()
> - Replace ima_staged_measurements_prepended with per measurements list
> flag to avoid copying staged and active list measurements twice
> - Optimize the staging and deleting flavor by locklessly determining the
> cut position in the active list, and immediately deleting entries
> without explicit staging and splicing (suggested by Steven Chen)
>
> v3:
> - Add Kconfig option to enable the staging mechanism (suggested by Mimi)
> - Change the meaning of BINARY_STAGED to be just the staged measurements
> - Separate the two staging flavors in two different functions:
> ima_queue_staged_delete_all() for staging with prompt,
> ima_queue_staged_delete_partial() for staging and deleting
> - Delete N entries without staging first (suggested by Mimi)
> - Avoid duplicate staged entries if there is contention between the
> measurements list interfaces and kexec
>
> v2:
> - New patch to move measurements and violation counters outside the
> ima_h_table structure
> - New patch to quickly replace the hash table
> - Forbid partial deletion when flushing hash table (suggested by Mimi)
> - Ignore ima_flush_htable if CONFIG_IMA_DISABLE_HTABLE is enabled
> - BINARY_SIZE_* renamed to BINARY_* for better clarity
> - Removed ima_measurements_staged_exist and testing list empty instead
> - ima_queue_stage_trim() and ima_queue_delete_staged_trimmed() renamed to
> ima_queue_stage() and ima_queue_delete_staged()
> - New delete interval [1, ULONG_MAX - 1]
> - Rename ima_measure_lock to ima_measure_mutex
> - Move seq_open() and seq_release() outside the ima_measure_mutex lock
> - Drop ima_measurements_staged_read() and use seq_read() instead
> - Optimize create_securityfs_measurement_lists() changes
> - New file name format with _staged suffix at the end of the file name
> - Use _rcu list variant in ima_dump_measurement_list()
> - Remove support for direct trimming and splice the remaining entries to
> the active list (suggested by Mimi)
> - Hot swap the hash table if flushing is requested
>
> v1:
> - Support for direct trimming without staging
> - Support unstaging on kexec (requested by Gregory Lumen)
>
> Roberto Sassu (13):
> ima: Remove ima_h_table structure
> ima: Replace static htable queue with dynamically allocated array
> ima: Introduce per binary measurements list type ima_num_entries
> counter
> ima: Introduce per binary measurements list type binary_runtime_size
> value
> ima: Introduce _ima_measurements_start() and _ima_measurements_next()
> ima: Mediate open/release method of the measurements list
> ima: Use snprintf() in create_securityfs_measurement_lists
> ima: Introduce ima_dump_measurement()
> ima: Add support for staging measurements with prompt
> ima: Add support for flushing the hash table when staging measurements
> ima: Support staging and deleting N measurements entries
> ima: Return error on deleting measurements already copied during kexec
> doc: security: Add documentation of the IMA staging mechanism
>
> .../admin-guide/kernel-parameters.txt | 4 +
> Documentation/security/IMA-staging.rst | 163 +++++++++
> Documentation/security/index.rst | 1 +
> MAINTAINERS | 2 +
> security/integrity/ima/Kconfig | 16 +
> security/integrity/ima/ima.h | 32 +-
> security/integrity/ima/ima_api.c | 2 +-
> security/integrity/ima/ima_fs.c | 315 ++++++++++++++++--
> security/integrity/ima/ima_init.c | 5 +
> security/integrity/ima/ima_kexec.c | 53 ++-
> security/integrity/ima/ima_queue.c | 283 ++++++++++++++--
> 11 files changed, 803 insertions(+), 73 deletions(-)
> create mode 100644 Documentation/security/IMA-staging.rst
>
^ permalink raw reply
* Re: [PATCH] Documentation: fix typo and formattting in security/credentials.rst
From: John Doe @ 2026-05-07 17:48 UTC (permalink / raw)
To: Randy Dunlap
Cc: Paul Moore, Serge Hallyn, Jonathan Corbet, Shuah Khan,
linux-security-module, linux-doc, linux-kernel
In-Reply-To: <cbe6e145-9d2f-47bb-8d22-1599cfd1a9d4@infradead.org>
On Wed, May 06, 2026 at 05:36:53PM -0700, Randy Dunlap wrote:
> Hi,
>
> On 5/6/26 3:59 PM, Mayank Gite wrote:
> > - Fixes a typo in "Keys and keyrings" section. Replaces "keying" with
> > "keyring".
> > - Updates formatting of keyring types.
> >
> > Signed-off-by: Mayank Gite <drapl0n.kernel@gmail.com>
>
> Acked-by: Randy Dunlap <rdunlap@infradead.org>
> Tested-by: Randy Dunlap <rdunlap@infradead.org>
>
> > ---
> In the future, right here, after that "---" line, it should say
> something like
>
> v2: use 'git send-email' so that that patch isn't corrupted
>
> and in the Subject: it should say
> [PATCH v2] ...
>
> Thanks.
>
> > Documentation/security/credentials.rst | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/security/credentials.rst b/Documentation/security/credentials.rst
> > index d0191c8b8060..4996838491b1 100644
> > --- a/Documentation/security/credentials.rst
> > +++ b/Documentation/security/credentials.rst
> > @@ -189,9 +189,9 @@ The Linux kernel supports the following types of credentials:
> > be searched for the desired key. Each process may subscribe to a number
> > of keyrings:
> >
> > - Per-thread keying
> > - Per-process keyring
> > - Per-session keyring
> > + - Per-thread keyring
> > + - Per-process keyring
> > + - Per-session keyring
> >
> > When a process accesses a key, if not already present, it will normally be
> > cached on one of these keyrings for future accesses to find.
>
> --
> ~Randy
Hi,
Thank you for the feedback and acknowledgment. I thought that since my
earlier patch was invalid/corrupted, I should submit a new one rather than
version 2.
I understand the procedure now and will ensure that future revisions follow
the guidelines.
Thanks.
^ permalink raw reply
* Re: [PATCH] Documentation: fix typo and formattting in security/credentials.rst
From: Jonathan Corbet @ 2026-05-07 18:31 UTC (permalink / raw)
To: John Doe, Randy Dunlap
Cc: Paul Moore, Serge Hallyn, Shuah Khan, linux-security-module,
linux-doc, linux-kernel
In-Reply-To: <afzQVIv4-Up24VNM@gmail.com>
John Doe <drapl0n.kernel@gmail.com> writes:
> Thank you for the feedback and acknowledgment. I thought that since my
> earlier patch was invalid/corrupted, I should submit a new one rather than
> version 2.
>
> I understand the procedure now and will ensure that future revisions follow
> the guidelines.
Along those lines, seeing multiple names associated with the same email
account is a bit disconcerting. We are not generally interested in
taking patches submitted under pseudonyms...
jon
^ permalink raw reply
* [PATCH v7 00/10] Reintroduce Hornet LSM
From: Blaise Boscaccy @ 2026-05-07 19:13 UTC (permalink / raw)
To: Blaise Boscaccy, Jonathan Corbet, Paul Moore, James Morris,
Serge E. Hallyn, Mickaël Salaün, Günther Noack,
Dr. David Alan Gilbert, Andrew Morton, James.Bottomley, dhowells,
Fan Wu, Ryan Foster, Randy Dunlap, linux-security-module,
linux-doc, linux-kernel, bpf, Song Liu
This patch series introduces the next iteration of the Hornet LSM.
Hornet’s goal is to provide a secure and extensible in-kernel
signature verification mechanism for eBPF programs.
Hornet addresses concerns from users who require strict audit trails and
verification guarantees for eBPF programs, especially in
security-sensitive environments. Many production systems need assurance
that only authorized, unmodified eBPF programs are loaded into the
kernel. Hornet provides this assurance through cryptographic signature
verification.
The currently accepted loader-plus-map signature verification scheme,
mandated by Alexei and KP, is simple to implement and generally
acceptable if users and administrators are satisfied with it. However,
verifying both the loader and the maps offers additional benefits
beyond verifying the loader alone:
1. Security and Audit Integrity
A key advantage is that the LSM hook for authorizing BPF program loads
can operate after signature verification. This ensures:
* Access control decisions are based on verified signature status.
* Accurate system state measurement and logging.
* Log entries claiming a verified signature are truthful, avoiding
misleading records where only the loader was verified while the actual
BPF program verification occurs later without logging.
2. TOCTOU Attack Prevention
The current map hash implementation may be vulnerable to a TOCTOU
attack because it allows unfrozen maps to cache a previously
calculated hash. The accepted “trusted loader” scheme cannot detect
this and may permit loading altered maps.
3. Supply Chain Integrity
Verify that eBPF programs and their associated map data have not been
modified since they were built and signed, in the kernel proper, may
aid in protecting against supply chain attacks.
This approach addresses concerns from users who require strict audit
trails and verification guarantees, especially in security-sensitive
environments. Map hashes for extended verification are passed via the
existing PKCS#7 UAPI and verified by the crypto subsystem. Hornet then
calculates the program’s verification state. Hornet itself does not
enforce a policy on whether unsigned or partially signed programs
should be rejected. It delegates that decision to downstream LSMs
hook, making it a composable building block in a larger security
architecture.
Changes in V7:
- minor IPE fixes
- tooling fixes in gen_sig
- checkpatch fixes
Link to V6: https://lore.kernel.org/linux-security-module/20260429191431.2345448-1-bboscaccy@linux.microsoft.com/
Changes in V6:
- Doc cleanup
- Error handling improvements
- Support for shareable maps
Link to V5: https://lore.kernel.org/linux-security-module/20260420212653.438685-1-bboscaccy@linux.microsoft.com/
Changes in V5:
- Added IPE documentation
Link to V4: https://lore.kernel.org/linux-security-module/20260416173500.176716-1-bboscaccy@linux.microsoft.com/
Changes in V4:
- IPE integration
- Arbitrary keyring support
Link to V3: https://lore.kernel.org/linux-security-module/20260326060655.2550595-1-bboscaccy@linux.microsoft.com/
Changes in V3:
- Updated for signed attribute patch series changes
- Added some new result enum values
- Minor documentation clarification
- Misc style fixes
- Added missing signed-off-by tags
Link to V2: https://lore.kernel.org/linux-security-module/20260227233930.2418522-1-bboscaccy@linux.microsoft.com/
Changes in V2:
- Addressed possible TocTou races in hash verification
- Improved documentation and tooling
- Added Alexie's nack
Link to RFC: https://lore.kernel.org/linux-security-module/20251211021257.1208712-1-bboscaccy@linux.microsoft.com/
Blaise Boscaccy (6):
lsm: security: Add additional enum values for bpf integrity checks
security: Hornet LSM
hornet: Introduce gen_sig
hornet: Add a light skeleton data extractor scripts
selftests/hornet: Add a selftest for the Hornet LSM
ipe: Add BPF program load policy enforcement via Hornet integration
James Bottomley (3):
crypto: pkcs7: add flag for validated trust on a signed info block
crypto: pkcs7: add ability to extract signed attributes by OID
crypto: pkcs7: add tests for pkcs7_get_authattr
Paul Moore (1):
lsm: framework for BPF integrity verification
Documentation/admin-guide/LSM/Hornet.rst | 323 +++++++++++++++
Documentation/admin-guide/LSM/index.rst | 1 +
Documentation/admin-guide/LSM/ipe.rst | 162 +++++++-
Documentation/security/ipe.rst | 68 ++++
MAINTAINERS | 9 +
certs/system_keyring.c | 1 +
crypto/asymmetric_keys/Makefile | 4 +-
crypto/asymmetric_keys/pkcs7_aa.asn1 | 18 +
crypto/asymmetric_keys/pkcs7_key_type.c | 44 +-
crypto/asymmetric_keys/pkcs7_parser.c | 81 ++++
crypto/asymmetric_keys/pkcs7_parser.h | 1 +
crypto/asymmetric_keys/pkcs7_trust.c | 1 +
include/crypto/pkcs7.h | 4 +
include/linux/lsm_hook_defs.h | 5 +
include/linux/oid_registry.h | 3 +
include/linux/security.h | 28 ++
include/uapi/linux/lsm.h | 1 +
scripts/Makefile | 1 +
scripts/hornet/Makefile | 5 +
scripts/hornet/extract-insn.sh | 27 ++
scripts/hornet/extract-map.sh | 27 ++
scripts/hornet/extract-skel.sh | 27 ++
scripts/hornet/gen_sig.c | 401 +++++++++++++++++++
scripts/hornet/write-sig.sh | 27 ++
security/Kconfig | 3 +-
security/Makefile | 1 +
security/hornet/Kconfig | 13 +
security/hornet/Makefile | 7 +
security/hornet/hornet.asn1 | 12 +
security/hornet/hornet_lsm.c | 352 ++++++++++++++++
security/ipe/Kconfig | 15 +
security/ipe/audit.c | 15 +
security/ipe/eval.c | 93 ++++-
security/ipe/eval.h | 11 +
security/ipe/hooks.c | 63 +++
security/ipe/hooks.h | 15 +
security/ipe/ipe.c | 14 +
security/ipe/ipe.h | 3 +
security/ipe/policy.h | 14 +
security/ipe/policy_parser.c | 27 ++
security/security.c | 75 +++-
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/hornet/Makefile | 63 +++
tools/testing/selftests/hornet/loader.c | 21 +
tools/testing/selftests/hornet/trivial.bpf.c | 33 ++
45 files changed, 2112 insertions(+), 8 deletions(-)
create mode 100644 Documentation/admin-guide/LSM/Hornet.rst
create mode 100644 crypto/asymmetric_keys/pkcs7_aa.asn1
create mode 100644 scripts/hornet/Makefile
create mode 100755 scripts/hornet/extract-insn.sh
create mode 100755 scripts/hornet/extract-map.sh
create mode 100755 scripts/hornet/extract-skel.sh
create mode 100644 scripts/hornet/gen_sig.c
create mode 100755 scripts/hornet/write-sig.sh
create mode 100644 security/hornet/Kconfig
create mode 100644 security/hornet/Makefile
create mode 100644 security/hornet/hornet.asn1
create mode 100644 security/hornet/hornet_lsm.c
create mode 100644 tools/testing/selftests/hornet/Makefile
create mode 100644 tools/testing/selftests/hornet/loader.c
create mode 100644 tools/testing/selftests/hornet/trivial.bpf.c
--
2.53.0
^ 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