kernel/git/next/linux-next.git/security/integrity/ima, branch master

ima: measure userspace policy writes before parsing

2026-07-13T12:49:04+00:00

When a signed policy is not mandatory, userspace can write IMA policy rules directly to the securityfs policy file: echo -e "measure func=BPRM_CHECK mask=MAY_EXEC\n" \ "audit func=BPRM_CHECK mask=MAY_EXEC\n" \ > /sys/kernel/security/ima/policy or by cat'ing the entire IMA custom policy file: cat ima-policy-file > /sys/kernel/security/ima/policy Because these rules originate from userspace and cross the userspace/kernel trust boundary, measure the raw write buffer before parsing, regardless of whether the new policy will be accepted or not. This can be caught when 'measure func=POLICY_CHECK' is enabled (e.g., ima_policy=tcb). The measurement template is forced to ima-buf. This follows the "measure & load" paradigm, exposing potential bugs in the policy code and detecting attempts to corrupt IMA. It also completes the POLICY_CHECK hook, which already measures partial policy load by file. To verify the template data hash value, convert the buffer policy data to binary: grep "ima_policy_written" \ /sys/kernel/security/integrity/ima/ascii_runtime_measurements | \ tail -1 | cut -d' ' -f 6 | xxd -r -p | sha256sum Suggested-by: Roberto Sassu Signed-off-by: Enrico Bravi Signed-off-by: Mimi Zohar

ima: add critical data measurement for loaded policy

2026-07-13T12:49:04+00:00

IMA policy can be written multiple times in the securityfs policy file at runtime if CONFIG_IMA_WRITE_POLICY=y. When IMA_APPRAISE_POLICY is required, the policy needs to be signed to be loaded, writing the absolute path of the file containing the new policy: echo /path/of/custom_ima_policy > /sys/kernel/security/ima/policy When this is not required, policy can be written directly, rule by rule: echo -e "measure func=BPRM_CHECK mask=MAY_EXEC\n" \ "audit func=BPRM_CHECK mask=MAY_EXEC\n" \ > /sys/kernel/security/ima/policy In this case, a new policy can be loaded without being measured or appraised. Add a new critical data record to measure the textual policy representation when it becomes effective. Include in the architecture-specific policy the new critical data record only when it is not mandatory to load a signed policy. Additionally, enable the policy serialization code even when CONFIG_IMA_READ_POLICY=n. To verify the template data hash value, convert the buffer policy data to binary: grep "ima_policy_loaded" \ /sys/kernel/security/integrity/ima/ascii_runtime_measurements | \ tail -1 | cut -d' ' -f 6 | xxd -r -p | sha256sum Signed-off-by: Enrico Bravi Signed-off-by: Mimi Zohar

security: ima: rename boot_aggregate when ima is initialised at late_sync

2026-07-06T19:32:34+00:00

The Linux IMA (Integrity Measurement Architecture) subsystem used for secure boot, file integrity, or remote attestation cannot be a loadable module for few reasons listed below: o Boot-Time Integrity: IMA’s main role is to measure and appraise files before they are used. This includes measuring critical system files during early boot (e.g., init, init scripts, login binaries). If IMA were a module, it would be loaded too late to cover those. o TPM Dependency: IMA integrates tightly with the TPM to record measurements into PCRs. The TPM must be initialized early (ideally before init_ima()), which aligns with IMA being built-in. o Security Model: IMA is part of a Trusted Computing Base (TCB). Making it a module would weaken the security model, as a potentially compromised system could delay or tamper with its initialization. IMA must be built-in to ensure it starts measuring from the earliest possible point in boot which inturn implies TPM must be initialised and ready to use before IMA. Unfortunately some TPM drivers (such as Arm FF-A, or SPI attached TPM devices) are not reliably available during the initcall_late stage, resulting in a log error: ima: No TPM chip found, activating TPM-bypass! To address this issue, IMA_INIT_LATE_SYNC is introduced. However, a remote attestation service cannot determine when IMA has been initialized because the boot_aggregate measurement name remains unchanged, even though IMA is initialized later at late_initcall_sync when IMA_INIT_LATE_SYNC is enabled. Therefore, use a distinct boot_aggregate name when IMA_INIT_LATE_SYNC is enabled, allowing the remote attestation service to identify when IMA has been initialized. Signed-off-by: Jonathan McDowell [yeoreum.yun@arm.com: modified to align with the IMA_INIT_LATE_SYNC change] Signed-off-by: Yeoreum Yun Signed-off-by: Mimi Zohar

security: ima: introduce IMA_INIT_LATE_SYNC option

2026-07-06T19:32:33+00:00

To generate the boot_aggregate log in the IMA subsystem with TPM PCR values, the TPM driver must be built as built-in and must be probed before the IMA subsystem is initialized. However, when the TPM device operates over the FF-A protocol using the CRB interface, probing fails and returns -EPROBE_DEFER if the tpm_crb_ffa device — an FF-A device that provides the communication interface to the tpm_crb driver — has not yet been probed. To ensure the TPM device operating over the FF-A protocol with the CRB interface is probed before IMA initialization, the following conditions must be met: 1. The corresponding ffa_device must be registered, which is done via ffa_init(). 2. The tpm_crb_driver must successfully probe this device via tpm_crb_ffa_init(). 3. The tpm_crb driver using CRB over FF-A can then be probed successfully. (See crb_acpi_add() and tpm_crb_ffa_init() for reference.) Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are all registered with device_initcall, which means crb_acpi_driver_init() may be invoked before ffa_init() and tpm_crb_ffa_init() are completed. When this occurs, probing the TPM device is deferred. However, the deferred probe can happen after the IMA subsystem has already been initialized, since IMA initialization is performed during late_initcall, and deferred_probe_initcall() is performed at the same level. And the similar situation is reported on TPM devices attached on SPI bus[0]. To resolve this, introduce IMA_INIT_LATE_SYNC option to initialise IMA at late_inicall_sync so that IMA is initialized with the TPM device probed deferred. When this option is enabled, modules that access files in the initramfs through usermode helper calls such as request_module() during initcall must not be built-in. Otherwise, IMA may miss measuring those files [1]. Link: https://lore.kernel.org/all/aYXEepLhUouN5f99@earth.li/ [0] Link: https://lore.kernel.org/all/2b3782398cc17ce9d355490a0c42ebce9120a9ae.camel@linux.ibm.com/ [1] Suggested-by: Mimi Zohar Signed-off-by: Yeoreum Yun [zohar@linux.ibm.com: Fixed Kconfig merge conflict] Signed-off-by: Mimi Zohar

ima: Support staging and deleting N measurements records

2026-06-08T15:43:34+00:00

Add support for sending a value N between 1 and ULONG_MAX to the IMA original measurement interface. This value represents the number of measurements that should be deleted from the current measurements list. In this case, measurements are staged in an internal non-user visible list, and immediately deleted. This staging method allows the remote attestation agents to easily separate the measurements that were verified (staged and deleted) from those that weren't due to the race between taking a TPM quote and reading the measurements list. In order to minimize the locking time of ima_extend_list_mutex, deleting N records is realized by doing a lockless walk in the current measurements list to determine the N-th entry to cut, to cut the current measurements list under the lock, and by deleting the excess records after releasing the lock. Flushing the hash table is not supported for N records, since it would require removing the N records one by one from the hash table under the ima_extend_list_mutex lock, which would increase the locking time. Link: https://github.com/linux-integrity/linux/issues/1 Co-developed-by: Steven Chen Signed-off-by: Steven Chen Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar

ima: Add support for flushing the hash table when staging measurements

2026-06-08T15:43:30+00:00

During staging and delete, measurements are not completely deallocated. Their entry digest portion is kept and is still reachable with the hash table to detect duplicate records. If the number of records is significant, this reduces the memory saving benefit of staging. Some users might be interested in achieving the best memory saving (the measurements are completely deallocated) at the cost of having duplicate records across the staged measurement lists. Duplicate records are still avoided within the current measurement list. Introduce the new kernel option ima_flush_htable to decide whether or not the digests of staged measurement records are flushed from the hash table, when they are deleted, to achieve the maximum memory saving. When the option is enabled, replace the old hash table with a new one, by calling ima_alloc_replace_htable(), and completely delete the measurements records. Note: This code derives from the Alt-IMA Huawei project, whose license is GPL-2.0 OR MIT. Link: https://github.com/linux-integrity/linux/issues/1 Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar

ima: Add support for staging measurements with prompt

2026-06-08T15:43:21+00:00

Introduce the ability of staging the IMA measurement list and deleting them with a prompt. Staging means moving the current measurement list records to a separate location, and allowing users to read and delete it. This causes the current measurement list to be emptied (since records were moved) and new measurements to be added on the empty list. Staging can be done only once at a time. In the event of kexec(), staging is aborted and staged records will be carried over to the new kernel. Introduce ascii_runtime_measurements__staged and binary_runtime_measurements__staged interfaces to access and delete the measurements. Use 'echo A > ' and 'echo D > ' to respectively stage and delete the entire measurements list. Locking of these interfaces is also mediated with a call to _ima_measurements_open() and with ima_measurements_release(). Implement the staging functionality by introducing the new global measurements list ima_measurements_staged, and ima_queue_stage() and ima_queue_staged_delete_all() to respectively move measurements from the current measurements list to the staged one, and to move staged measurements to the ima_measurements_trim list for deletion. Introduce ima_queue_delete() to delete the measurements. Staging is forbidden after measurement is suspended, and between staging and deleting, so that walking the staged and current measurements list can be done locklessly in ima_dump_measurement_list(). Strict ordering of suspending and dumping is enforced by two reboot notifiers with different priority. Refusing to delete staged measurements also signals to user space that those measurements are already carried over to the secondary kernel, so that it does not save them twice. Finally, introduce the BINARY_STAGED and BINARY_FULL binary measurements list types, to maintain the counters and the binary size of staged measurements and the full measurements list (including records that were staged). BINARY still represents the current binary measurements list. Use the binary size for the BINARY + BINARY_STAGED types in ima_add_kexec_buffer(), since both measurements list types are copied to the secondary kernel during kexec. Use BINARY_FULL in ima_measure_kexec_event(), to generate a critical data record. It should be noted that the BINARY_FULL counter is not passed through kexec. Thus, the number of records included in the kexec critical data records refers to the records since the critical data records generated from the previous kexec event. Note: This code derives from the Alt-IMA Huawei project, whose license is GPL-2.0 OR MIT. Link: https://github.com/linux-integrity/linux/issues/1 Suggested-by: Gregory Lumen (staging revert) Signed-off-by: Roberto Sassu Tested-by: Stefan Berger Signed-off-by: Mimi Zohar

ima: Introduce ima_dump_measurement()

2026-06-08T15:43:15+00:00

Introduce ima_dump_measurement() to simplify the code of ima_dump_measurement_list() and to avoid repeating the ima_dump_measurement() code block if iteration occurs on multiple lists. No functional change: only code moved to a separate function. Link: https://github.com/linux-integrity/linux/issues/1 Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar

ima: Use snprintf() in create_securityfs_measurement_lists

2026-06-08T15:43:11+00:00

Use the more secure snprintf() function (accepting the buffer size) in create_securityfs_measurement_lists(). No functional change: sprintf() and snprintf() have the same behavior. Link: https://github.com/linux-integrity/linux/issues/1 Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar

ima: Mediate open/release method of the measurements list

2026-06-08T15:43:07+00:00

Introduce the ima_measure_users counter, to implement a semaphore-like locking scheme where the binary and ASCII measurements list interfaces can be concurrently opened by multiple readers, or alternatively by a single writer. In addition, allow the same writer to open the other interfaces for write or read/write, so that it can see the same measurement state across all the interfaces. A semaphore cannot be used because the kernel cannot return to user space with a lock held. Introduce the ima_measure_lock() and ima_measure_unlock() primitives, to respectively lock/unlock the interfaces (safely with the ima_measure_users counter, without holding a lock). Finally, introduce _ima_measurements_open() to lock the interface before seq_open(), and call it from ima_measurements_open() and ima_ascii_measurements_open(). And, introduce ima_measurements_release(), to unlock the interface. Require CAP_SYS_ADMIN if the interface is opened for write (not possible for the current measurements interfaces, since they only have read permission). No functional changes: multiple readers are allowed as before. Link: https://github.com/linux-integrity/linux/issues/1 Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar