Add support for simplified IMA measurement list snapshots

[robertosassu]

Goals:

Provide a new interface for managing (create/read/delete) snapshots of the measurement list.

Why:

Allow system administrators to relieve the system from kernel memory pressure by moving the IMA measurement list to a different storage (use case-defined). For example, an user space service can periodically create snapshots of the measurement lists, and append them together to build a global measurement list that can be sent to remote verifiers for attestation.

How:

Create a secondary measurement list. Implement the create method as a list replace from the current IMA measurement list to the secondary. Implement the read method similar to the original measurement list method (but on the secondary list). Implement the delete method by removing all the elements in the secondary measurement list.

At the same time, add a kernel option to let system administrators decide if they want or not to flush the kernel hash table too (used for detecting measurement collisions).

Locking: the regular measurement list lock is taken only when a snapshot is created (to protect the list replace and the hash table flush); atomic bit operations protect access to the regular measurement list and the new snapshot interfaces (only one can be accessed at time by one process).

[robertosassu]

Previous work:

• Proposal by Sush Shringarputale and Tushar Sugandhi (https://lists.infradead.org/pipermail/kexec/2023-August/027657.html)

[mimizohar]

Currently the entire measurement list was stored in memory for the good and bad. Good - the measurement list would always verify. Bad - the kernel memory pressure.

Questions:

1. Can we guarantee the snapshot isn't simply being dropped? Is this the responsibility of the kernel?
2. Should any privileged user (e.g. root) be allowed to trigger the snapshot?

We've discussed over the years introducing a new capability for integrity. Perhaps this new feature should be dependent on an integrity capability.

[safforddr]

Roberto's approach of duplicate - read - delete looks like a good combination of performance and safety.
I see no need for aggregate marker events as done in previous work.

Even in the existing design, the kernel has to trust the attesting application to send the events correctly to
the verifier, and moving the events from kernel memory to disk only makes that trust a bit more explicit.

While it would be nice to have an integrity capability to gate this feature, getting a new capability will take
a long time, and I would not delay this important feature for that.

If/when there is an implementation, I would love to test it.

[robertosassu]

Thanks David for the feedback! I plan to have it ready in the following months.

[robertosassu]

First draft: https://github.com/robertosassu/linux/tree/ima-snapshots-v1-devel-v1.

[robertosassu]

There is one problem to solve: when restoring the measurement list after kexec, the hash table will be incomplete because the entry digests of the snapshots are not marshaled/unmarshaled. To synchronize the hash table completely, it would be necessary to have cooperation between the primary and the secondary kernel, in a way that the former signals which entries should be processed just for adding the digest in the hash table, and the latter does not add those entries to the measurement list.

[mimizohar]

A kexec after trimming the IMA measurement list will result in the "runtime_measurements_count" number not containing the total number of records in the full measurement list. Similarly, is the violation count retained?

[robertosassu]

New version:

• Using staging terminology instead of snapshot (suggested by Mimi)
• Maintaining two measurements list counters (without trim/with trim)
• Don't use ima_measure_sem because it causes lockdep warning
• Better guard accesses to the measurements list with ima_extend_list_mutex
• Add support for staging N entries instead of the entire measurements list (requested by Microsoft)
• Better parsing of the staging request

Cannot fix:

• Cannot restore the hash table after kexec(); we don't have template data anymore to recalculate all the digests; one option would be to support the Crypto Agile format, and dump the measurements list with that format.