On 5/7/2026 9:47 AM, steven chen wrote:
Usage
=====
The IMA staging mechanism can be enabled from the kernel configuration
with the CONFIG_IMA_STAGING option.
If it is enabled, IMA duplicates the current measurements interfaces
(both binary and ASCII), by adding the _staged file suffix. Both the
original and the staging interfaces gain the write permission for the
root user and group, but require the process to have CAP_SYS_ADMIN set.
The staging mechanism supports two flavors.
Staging with prompt
~~~~~~~~~~~~~~~~~~~
The current measurements list is moved to a temporary staging area, and
staged measurements are deleted upon confirmation.
This staging process is achieved with the following steps.
1. echo A > <original interface>: the user requests IMA to stage the
entire measurements list;
2. cat <_staged interface>: the user reads the staged measurements;
3. echo D > <_staged interface>: the user requests IMA to delete
staged measurements.
Staging and deleting
~~~~~~~~~~~~~~~~~~~~
N measurements are staged to a temporary staging area, and immediately
deleted without further confirmation.
This staging process is achieved with the following steps.
1. cat <original interface>: the user reads the current measurements
list and determines what the value N for staging should be;
2. echo N > <original interface>: the user requests IMA to delete N
measurements from the current measurements list.
This submission proposes two ways for log trimming:
*Flavor 1:* Staging with prompt
*Flavor 2:* stage and delete N
Functionally, both approaches address the same problem, but *Favour 2
*is the
stronger design and should be preferred. There is no good reason to keep
*Flavor 1.*
From a kernel implementation perspective, *Flavor 2 *is more efficient
because it
minimizes the time spent holding the list lock (can’t be shorter). It
also substantially
reduces the amount of kernel-side logic, removing nearly half of the
code required
by the alternative approach.
From a user-space perspective, *Flavor 2 *results in a much cleaner
model. It avoids
the need to track and reconcile both old and staged lists in user space
as well as
two lists (cur and staged) in the kernel space, which simplifies log
trimming logic
and reduces maintenance overhead. In addition, it preserves the existing
external
behavior by not exposing any staged list to user space.
Overall, *Flavor 2 *provides the same functional result with lower
kernel complexity,
shorter kernel list lock hold time, and a simpler user-space interface.
For those
reasons, it is the preferable approach and *Favour 1* does not appear to
offer sufficient
justification to keep both implementations.
Steven
Roberto, Mimi:
I want to add on to the point Steven has brought up.
With "Stage and Delete N" approach, we have the following sequence of
tasks for trimming the IMA log:
1. User mode locks the IMA measurement list through the "write
interface".
a. While this prevents any other user mode process from updating the
IMA log, kernel can still add new IMA events to the measurement log
2. User mode reads the TPM Quote and the IMA measurement events and
sends it to the remote attestation service
3. Once the remote service has successfully processed the IMA events,
the user mode determines the number of IMA events "N" to be removed from
the measurement list maintained in the kernel
4. User mode provides the value "N" to the kernel
5. Kernel now determines the point at which to snap the IMA measurement
list using "N" - without holding a lock
6. Then, the kernel lock is held and the list is snapped at the point
determined in the previous step thus keeping the kernel lock time to the
minimum.
7. Now, user mode removes the "write" lock on the IMA measurement list
With the above, we believe "Stage and Delete N" alone is sufficient to
trim IMA log.
-lakshmi
.../admin-guide/kernel-parameters.txt | 4 +
Documentation/security/IMA-staging.rst | 163 +++++++++
Documentation/security/index.rst | 1 +
MAINTAINERS | 2 +
security/integrity/ima/Kconfig | 16 +
security/integrity/ima/ima.h | 32 +-
security/integrity/ima/ima_api.c | 2 +-
security/integrity/ima/ima_fs.c | 315 ++++++++++++++++--
security/integrity/ima/ima_init.c | 5 +
security/integrity/ima/ima_kexec.c | 53 ++-
security/integrity/ima/ima_queue.c | 283 ++++++++++++++--
11 files changed, 803 insertions(+), 73 deletions(-)
create mode 100644 Documentation/security/IMA-staging.rst
