* 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] 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] 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] 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] 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: 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] 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
* [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
* [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
* 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
* 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] 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] ima: debugging late_initcall_sync measurements
From: Mimi Zohar @ 2026-05-06 11:47 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: <afrXmRiq7XvSe6yN@e129823.arm.com>
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}
>
> Could you please check how the index (1, 31) was added to either
> ima_template_entry or ima_queue_entry to produce this result?
The grep "-n" option includes line numbers. It doesn't have anything to do with
the kernel.
Mimi
^ permalink raw reply
* Re: [RFC PATCH 2/3] firmware: arm_ffa: initialise ff-a after finalising pKVM initialisation
From: Sudeep Holla @ 2026-05-06 9:58 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-integrity, keyrings, linux-security-module, linux-kernel,
Sudeep Holla, linux-arm-kernel, kvmarm, jarkko, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, paul, jmorris,
serge, maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
In-Reply-To: <afsCs56KfpoMhPH9@e129823.arm.com>
On Wed, May 06, 2026 at 09:58:27AM +0100, Yeoreum Yun wrote:
> > On Wed, May 06, 2026 at 08:49:20AM +0100, Yeoreum Yun wrote:
> > > Hi,
> > >
> > > I mean like DT node, it seems to add some "FF-A" device for this.
> > > Anyway, right now as your suggestion, let me respin with platform device
> > > again.
> > >
> >
> > Please check my branch ffa_plat_dev [1] as I noted in the last email.
> >
> > --
> > Regards,
> > Sudeep
> >
> > [1] https://git.kernel.org/sudeep.holla/l/ffa_plat_dev
>
> Sorry, I've seen this email after I sent former mail.
>
> And since platform_driver_probe() prevents deferred probe.
> I think it need to change jsut platform_driver_register()
> for ffa_driver.
>
Thanks for pointing that out. Forgot about that as I was focussing on keeping
it as simple as possible. I have updated the branch now.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [RFC PATCH 2/3] firmware: arm_ffa: initialise ff-a after finalising pKVM initialisation
From: Yeoreum Yun @ 2026-05-06 9:11 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-integrity, keyrings, linux-security-module, linux-kernel,
linux-arm-kernel, kvmarm, jarkko, zohar, roberto.sassu,
dmitry.kasatkin, eric.snowberg, paul, jmorris, serge, maz, oupton,
joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas, will
In-Reply-To: <afsCs56KfpoMhPH9@e129823.arm.com>
On Wed, May 06, 2026 at 09:58:27AM +0100, Yeoreum Yun wrote:
> > On Wed, May 06, 2026 at 08:49:20AM +0100, Yeoreum Yun wrote:
> > > Hi,
> > >
> > > I mean like DT node, it seems to add some "FF-A" device for this.
> > > Anyway, right now as your suggestion, let me respin with platform device
> > > again.
> > >
> >
> > Please check my branch ffa_plat_dev [1] as I noted in the last email.
> >
> > --
> > Regards,
> > Sudeep
> >
> > [1] https://git.kernel.org/sudeep.holla/l/ffa_plat_dev
>
> Sorry, I've seen this email after I sent former mail.
>
> And since platform_driver_probe() prevents deferred probe.
> I think it need to change jsut platform_driver_register()
> for ffa_driver.
>
> Thanks!
With above change, everything is good.
Thanks again!
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [RFC PATCH 2/3] firmware: arm_ffa: initialise ff-a after finalising pKVM initialisation
From: Yeoreum Yun @ 2026-05-06 8:58 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-integrity, keyrings, linux-security-module, linux-kernel,
linux-arm-kernel, kvmarm, jarkko, zohar, roberto.sassu,
dmitry.kasatkin, eric.snowberg, paul, jmorris, serge, maz, oupton,
joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas, will
In-Reply-To: <20260506-colossal-bee-of-discussion-08ac76@sudeepholla>
> On Wed, May 06, 2026 at 08:49:20AM +0100, Yeoreum Yun wrote:
> > Hi,
> >
> > I mean like DT node, it seems to add some "FF-A" device for this.
> > Anyway, right now as your suggestion, let me respin with platform device
> > again.
> >
>
> Please check my branch ffa_plat_dev [1] as I noted in the last email.
>
> --
> Regards,
> Sudeep
>
> [1] https://git.kernel.org/sudeep.holla/l/ffa_plat_dev
Sorry, I've seen this email after I sent former mail.
And since platform_driver_probe() prevents deferred probe.
I think it need to change jsut platform_driver_register()
for ffa_driver.
Thanks!
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [RFC PATCH 2/3] firmware: arm_ffa: initialise ff-a after finalising pKVM initialisation
From: Sudeep Holla @ 2026-05-06 8:14 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-integrity, keyrings, linux-security-module, linux-kernel,
Sudeep Holla, linux-arm-kernel, kvmarm, jarkko, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, paul, jmorris,
serge, maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
In-Reply-To: <afrygFx4OoCbbr+a@e129823.arm.com>
On Wed, May 06, 2026 at 08:49:20AM +0100, Yeoreum Yun wrote:
> Hi,
>
> I mean like DT node, it seems to add some "FF-A" device for this.
> Anyway, right now as your suggestion, let me respin with platform device
> again.
>
Please check my branch ffa_plat_dev [1] as I noted in the last email.
--
Regards,
Sudeep
[1] https://git.kernel.org/sudeep.holla/l/ffa_plat_dev
^ permalink raw reply
* Re: [RFC PATCH 1/3] arm64: KVM: defer kvm_init() to finalise_pkvm() when pKVM is enabled
From: Sudeep Holla @ 2026-05-06 7:50 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-integrity, keyrings, linux-security-module, linux-kernel,
Sudeep Holla, linux-arm-kernel, kvmarm, jarkko, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, paul, jmorris,
serge, maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
In-Reply-To: <20260505095409.1948371-2-yeoreum.yun@arm.com>
On Tue, May 05, 2026 at 10:54:07AM +0100, Yeoreum Yun wrote:
> This patch is a preparatory change to address dependency issues
> between the FF-A driver and pKVM.
>
> kvm_init() should be invoked from finalise_pkvm(),
> as this is the point where pKVM initialisation is finalised and
> the system transitions into the protected mode.
>
> Deferring kvm_init() ensures that KVM is initialised only after pKVM has
> fully established its protected environment.
>
> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> ---
> arch/arm64/kvm/arm.c | 8 +++++---
> arch/arm64/kvm/pkvm.c | 15 ++++++++++++++-
> 2 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 8bb2c7422cc8..663b1d447a9b 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -3025,9 +3025,11 @@ static __init int kvm_arm_init(void)
> * FIXME: Do something reasonable if kvm_init() fails after pKVM
> * hypervisor protection is finalized.
> */
> - err = kvm_init(sizeof(struct kvm_vcpu), 0, THIS_MODULE);
> - if (err)
> - goto out_subs;
> + if (!is_protected_kvm_enabled()) {
> + err = kvm_init(sizeof(struct kvm_vcpu), 0, THIS_MODULE);
> + if (err)
> + goto out_subs;
> + }
>
> /*
> * This should be called after initialization is done and failure isn't
> diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> index 053e4f733e4b..48b06d384570 100644
> --- a/arch/arm64/kvm/pkvm.c
> +++ b/arch/arm64/kvm/pkvm.c
> @@ -17,6 +17,7 @@
> #include "hyp_constants.h"
>
> DEFINE_STATIC_KEY_FALSE(kvm_protected_mode_initialized);
> +EXPORT_SYMBOL_GPL(kvm_protected_mode_initialized);
>
I am not sure if this is needed when FF-A is built as module. If others
are OK with it, I am fine. But I am thinking if we need to use this in
FF-A driver which can be built-in or a module, we can add
IS_BUILTIN(CONFIG_ARM_FFA_*)
--
Regards,
Sudeep
^ permalink raw reply
* Re: [RFC PATCH 2/3] firmware: arm_ffa: initialise ff-a after finalising pKVM initialisation
From: Yeoreum Yun @ 2026-05-06 7:49 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-integrity, keyrings, linux-security-module, linux-kernel,
linux-arm-kernel, kvmarm, jarkko, zohar, roberto.sassu,
dmitry.kasatkin, eric.snowberg, paul, jmorris, serge, maz, oupton,
joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas, will
In-Reply-To: <20260506-warm-deer-of-energy-522bfa@sudeepholla>
Hi,
> On Tue, May 05, 2026 at 05:58:32PM +0100, Yeoreum Yun wrote:
> > Hi Sudeep,
> >
> > > On Tue, May 05, 2026 at 04:06:51PM +0100, Yeoreum Yun wrote:
> > > > Hi Sudeep,
> > > >
> > > > > On Tue, May 05, 2026 at 10:54:08AM +0100, Yeoreum Yun wrote:
> > > > > > When pKVM is enabled, the FF-A driver must be initialised after pKVM.
> > > > > > Otherwise, pKVM cannot negotiate the FF-A version or obtain the RX/TX
> > > > > > buffer information, leading to failures in FF-A calls.
> > > > > >
> > > > > > Currently, pKVM initialisation completes at device_initcall_sync,
> > > > > > while ffa_init() runs at the device_initcall level.
> > > > > >
> > > > > > So far, linker deployes kvm_arm_init() before ffa_init(), and SMCs can
> > > > > > still be trapped even before finalise_pkvm() is invoked.
> > > > > > As a result, this issue has not been observed.
> > > > > >
> > > > > > However, relying on above stuff is fragile.
> > > > > > Therefore, when pKVM is enabled, the FF-A infrastructure should be
> > > > > > initialised only after pKVM initialisation has been fully finalised.
> > > > > >
> > > > > > To achieve this, introduce an ffa_root_dev ("arm-ffa") and
> > > > > > a corresponding driver to defer initialisation of the FF-A infrastructure
> > > > > > until pKVM initialisation is complete, and to defer probing of all FF-A devices until then
> > > > > > when pKVM is enabled.
> > > > > >
> > > > >
> > > > > I don't like this whole ffa root device design.
> > > > > Two question for now:
> > > > > 1. Can FF-A be a module on systems with pKVM which removes the need for all
> > > > > this dance done here ?
> > > >
> > > > But this means we reduce the other feature e.x) IMA with TPM over
> > > > FF-A and pKVM feature. Since IMA must be a built-in, we couldn't avoid
> > > > to build FF-A driver with built-in.
> > > >
> > > > > 2. If it is a requirement to have this built-in, I prefer to add a probe
> > > > > and defer it instead of this root ffa device.
> > > >
> > > > But, How? anyway all of FF-A device & driver couldn't be probed unless
> > > > FF-A initialisation is finished and How can we trigger FF-A initailise
> > > > after pKVM finish its initialisation?
> > > >
> > > > The problem is ff-a intiailisation happens before pKVM finish its
> > > > initailasation and to do defer probe, it should use dd-model and
> > > > As we discussed in other thread, notifier couldn't be a soluation.
> > > >
> > > > Could you let me share other way I'm missing?
> > > >
> > >
> > > Will something like below work ?
> >
> > It might work and when I write the code I thougt about whether to
> > use add platform device but I didn't find why this is better than
> > to create root device of FF-A (anyway creating a simple platform device
> > for FF-A seems similar to create root device)
>
> First, you tried to force the FF-A core to be treated as an FF-A device, then
> added several bus-code changes to handle it as a "special root" device while
> skipping all FF-A device functionality. Please consider the purpose of
> creating it as an FF-A device if additional code is then required to bypass
> the functionality it provides.
Okay. I'll do with platform device then.
>
> > If you don't mind why it would be better than to create FF-A root
> > device in FF-A bus?
> >
> > > If we add DT bindings, then we can add
> > > of_match_table and drop the platform device creation. Also we can adjust
> > > the parent device the way you have done by a simple change(not done in
> > > this untested/not compiled change).
> >
> > Might for a DT, but do we need to platform device creation for ACPI case
> > anyway?
> >
> >
>
> Just acpi_match_table instead of of_match_table.
I mean like DT node, it seems to add some "FF-A" device for this.
Anyway, right now as your suggestion, let me respin with platform device
again.
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [RFC PATCH 2/3] firmware: arm_ffa: initialise ff-a after finalising pKVM initialisation
From: Sudeep Holla @ 2026-05-06 7:46 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-integrity, keyrings, linux-security-module, linux-kernel,
linux-arm-kernel, kvmarm, Sudeep Holla, jarkko, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, paul, jmorris,
serge, maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
In-Reply-To: <20260505-adaptable-mussel-of-virtuosity-2751db@sudeepholla>
On Tue, May 05, 2026 at 05:32:15PM +0100, Sudeep Holla wrote:
> On Tue, May 05, 2026 at 04:06:51PM +0100, Yeoreum Yun wrote:
> > Hi Sudeep,
> >
> > > On Tue, May 05, 2026 at 10:54:08AM +0100, Yeoreum Yun wrote:
> > > > When pKVM is enabled, the FF-A driver must be initialised after pKVM.
> > > > Otherwise, pKVM cannot negotiate the FF-A version or obtain the RX/TX
> > > > buffer information, leading to failures in FF-A calls.
> > > >
> > > > Currently, pKVM initialisation completes at device_initcall_sync,
> > > > while ffa_init() runs at the device_initcall level.
> > > >
> > > > So far, linker deployes kvm_arm_init() before ffa_init(), and SMCs can
> > > > still be trapped even before finalise_pkvm() is invoked.
> > > > As a result, this issue has not been observed.
> > > >
> > > > However, relying on above stuff is fragile.
> > > > Therefore, when pKVM is enabled, the FF-A infrastructure should be
> > > > initialised only after pKVM initialisation has been fully finalised.
> > > >
> > > > To achieve this, introduce an ffa_root_dev ("arm-ffa") and
> > > > a corresponding driver to defer initialisation of the FF-A infrastructure
> > > > until pKVM initialisation is complete, and to defer probing of all FF-A devices until then
> > > > when pKVM is enabled.
> > > >
> > >
> > > I don't like this whole ffa root device design.
> > > Two question for now:
> > > 1. Can FF-A be a module on systems with pKVM which removes the need for all
> > > this dance done here ?
> >
> > But this means we reduce the other feature e.x) IMA with TPM over
> > FF-A and pKVM feature. Since IMA must be a built-in, we couldn't avoid
> > to build FF-A driver with built-in.
> >
> > > 2. If it is a requirement to have this built-in, I prefer to add a probe
> > > and defer it instead of this root ffa device.
> >
> > But, How? anyway all of FF-A device & driver couldn't be probed unless
> > FF-A initialisation is finished and How can we trigger FF-A initailise
> > after pKVM finish its initialisation?
> >
> > The problem is ff-a intiailisation happens before pKVM finish its
> > initailasation and to do defer probe, it should use dd-model and
> > As we discussed in other thread, notifier couldn't be a soluation.
> >
> > Could you let me share other way I'm missing?
> >
>
> Will something like below work ? If we add DT bindings, then we can add
> of_match_table and drop the platform device creation. Also we can adjust
> the parent device the way you have done by a simple change(not done in
> this untested/not compiled change).
>
I have pushed the changes[1], will post once tested and you confirm your
use-case also works.
--
Regards,
Sudeep
[1] https://git.kernel.org/sudeep.holla/l/ffa_plat_dev
^ permalink raw reply
* Re: [RFC PATCH 2/3] firmware: arm_ffa: initialise ff-a after finalising pKVM initialisation
From: Sudeep Holla @ 2026-05-06 7:27 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-integrity, keyrings, linux-security-module, linux-kernel,
Sudeep Holla, linux-arm-kernel, kvmarm, jarkko, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, paul, jmorris,
serge, maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
In-Reply-To: <afohuFhVBIyUFEMT@e129823.arm.com>
On Tue, May 05, 2026 at 05:58:32PM +0100, Yeoreum Yun wrote:
> Hi Sudeep,
>
> > On Tue, May 05, 2026 at 04:06:51PM +0100, Yeoreum Yun wrote:
> > > Hi Sudeep,
> > >
> > > > On Tue, May 05, 2026 at 10:54:08AM +0100, Yeoreum Yun wrote:
> > > > > When pKVM is enabled, the FF-A driver must be initialised after pKVM.
> > > > > Otherwise, pKVM cannot negotiate the FF-A version or obtain the RX/TX
> > > > > buffer information, leading to failures in FF-A calls.
> > > > >
> > > > > Currently, pKVM initialisation completes at device_initcall_sync,
> > > > > while ffa_init() runs at the device_initcall level.
> > > > >
> > > > > So far, linker deployes kvm_arm_init() before ffa_init(), and SMCs can
> > > > > still be trapped even before finalise_pkvm() is invoked.
> > > > > As a result, this issue has not been observed.
> > > > >
> > > > > However, relying on above stuff is fragile.
> > > > > Therefore, when pKVM is enabled, the FF-A infrastructure should be
> > > > > initialised only after pKVM initialisation has been fully finalised.
> > > > >
> > > > > To achieve this, introduce an ffa_root_dev ("arm-ffa") and
> > > > > a corresponding driver to defer initialisation of the FF-A infrastructure
> > > > > until pKVM initialisation is complete, and to defer probing of all FF-A devices until then
> > > > > when pKVM is enabled.
> > > > >
> > > >
> > > > I don't like this whole ffa root device design.
> > > > Two question for now:
> > > > 1. Can FF-A be a module on systems with pKVM which removes the need for all
> > > > this dance done here ?
> > >
> > > But this means we reduce the other feature e.x) IMA with TPM over
> > > FF-A and pKVM feature. Since IMA must be a built-in, we couldn't avoid
> > > to build FF-A driver with built-in.
> > >
> > > > 2. If it is a requirement to have this built-in, I prefer to add a probe
> > > > and defer it instead of this root ffa device.
> > >
> > > But, How? anyway all of FF-A device & driver couldn't be probed unless
> > > FF-A initialisation is finished and How can we trigger FF-A initailise
> > > after pKVM finish its initialisation?
> > >
> > > The problem is ff-a intiailisation happens before pKVM finish its
> > > initailasation and to do defer probe, it should use dd-model and
> > > As we discussed in other thread, notifier couldn't be a soluation.
> > >
> > > Could you let me share other way I'm missing?
> > >
> >
> > Will something like below work ?
>
> It might work and when I write the code I thougt about whether to
> use add platform device but I didn't find why this is better than
> to create root device of FF-A (anyway creating a simple platform device
> for FF-A seems similar to create root device)
First, you tried to force the FF-A core to be treated as an FF-A device, then
added several bus-code changes to handle it as a "special root" device while
skipping all FF-A device functionality. Please consider the purpose of
creating it as an FF-A device if additional code is then required to bypass
the functionality it provides.
> If you don't mind why it would be better than to create FF-A root
> device in FF-A bus?
>
> > If we add DT bindings, then we can add
> > of_match_table and drop the platform device creation. Also we can adjust
> > the parent device the way you have done by a simple change(not done in
> > this untested/not compiled change).
>
> Might for a DT, but do we need to platform device creation for ACPI case
> anyway?
>
>
Just acpi_match_table instead of of_match_table.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Yeoreum Yun @ 2026-05-06 7:23 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: <afrXmRiq7XvSe6yN@e129823.arm.com>
> > 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.
>
> Could you please check how the index (1, 31) was added to either
> ima_template_entry or ima_queue_entry to produce this result?
And since most IMA measurements occur during module, file, or bprm operations,
I’m really curious about where such operations take place
before the init process is loaded, since init is started only after all
initcalls have completed.
Personally, I find it hard to believe that this kind of critical data
measurement comes from dm or SELinux, as those typically operate via
ioctl or load policies after userspace becomes available.
If you don’t mind, could you share your test code for the index,
as well as some stack traces? That would help me understand
where these measurements are coming from.
Thanks!
>
> --
> Sincerely,
> Yeoreum Yun
>
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Yeoreum Yun @ 2026-05-06 5:54 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: <201b9172ac47c6766443c1f2343cab3548f33c29.camel@linux.ibm.com>
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.
Could you please check how the index (1, 31) was added to either
ima_template_entry or ima_queue_entry to produce this result?
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* [PATCH] Documentation: fix typo and formattting in security/credentials.rst
From: Mayank Gite @ 2026-05-06 5:49 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@protonmail.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] ima: debugging late_initcall_sync measurements
From: Paul Moore @ 2026-05-06 2:11 UTC (permalink / raw)
To: Mimi Zohar
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: <5debff82dc758d9c91223e4f1f5b9e39a3fcd4f5.camel@linux.ibm.com>
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.
--
paul-moore.com
^ 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