On Fri, 2026-06-05 at 19:22 +0200, Roberto Sassu wrote: > From: Roberto Sassu <[email protected]> > > Introduction > ============ > > The IMA measurements list is currently stored in the kernel memory. > Memory occupation grows linearly with the number of records, and can > become a problem especially in environments with reduced resources. > > While there is an advantage in keeping the IMA measurements list in > kernel memory, so that it is always available for reading from the > securityfs interfaces, storing it elsewhere would make it possible to > free precious memory for other kernel usage. > > The IMA measurements list needs to be retained and safely stored for new > attestation servers to validate it. Assuming the IMA measurements list > is properly saved, storing it outside the kernel does not introduce > security issues, since its integrity is anyway protected by the TPM. > > Hence, the new IMA staging mechanism is introduced to export IMA > measurements to user space and delete them from kernel space. > > Staging consists in atomically moving the current measurements list to a > temporary list, so that measurements can be deleted afterwards. The > staging operation locks the hot path (racing with addition of new > measurements) for a very short time, only for swapping the list > pointers. Deletion of the measurements instead is done locklessly, away > from the hot path. > > There are two flavors of the staging mechanism. In the staging with > prompt, all current measurements are staged, read and deleted upon > confirmation. In the staging and deleting flavor, N measurements are > staged from the beginning of the current measurements list and > immediately deleted without confirmation. > > > Usage > ===== > > The IMA staging mechanism can be enabled from the kernel configuration > with the CONFIG_IMA_STAGING option. This option prevents inadvertently > removing the IMA measurement list on systems which do not properly save > it. > > If the option is enabled, IMA duplicates the current securityfs > 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 measurement list is moved to a temporary staging area, > allowing it to be saved to external storage, before being deleted upon > confirmation. > > This staging process is achieved with the following steps. > > 1. echo A > <_staged 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. > > > Management of Staged Measurements > ================================= > > Since with the staging mechanism measurement records are removed from > the kernel, the staged measurements need to be saved in a storage and > concatenated together, so that they can be presented during remote > attestation as if staging was never done. This task can be accomplished > by a remote attestation agent modified to support staging, or a system > service. > > > Patch set content > ================= > > Patches 1-8 are preparatory patches to quickly replace the hash table, > maintain separate counters for the different measurements list types, > mediate access to the measurements list interface, and simplify the staging > patches. > > Patch 9 introduces the staging with prompt flavor. Patch 10 makes it > possible to flush the hash table when deleting all the staged measurements. > Patch 11 introduces the staging and deleting flavor. Patch 12 adds the > documentation of the staging mechanism. > > > Changelog > ========= > > v6: > - Make ima_extend_list_mutex as static since it is not needed anymore by > ima_dump_measurement_list() (suggested by Mimi) > - Export ima_flush_htable in patch 11 instead of 10 (suggested by Mimi) > - Add clarification in the documentation regarding a proactive remote > attestation agent, and storing all the measurements in the storage > (suggested by Mimi)
Roberto, thank you for making these and all the other changes. The patch set is now queued in next-integrity. Mimi
