On Thu, 2023-10-19 at 11:49 -0700, Tushar Sugandhi wrote:
[...]
> -----------------------------------------------------------------------
> | C.1 Solution Summary |
> -----------------------------------------------------------------------
> To achieve the goals described in the section above, we propose the
> following changes to the IMA subsystem.
>
> a. The IMA log from Kernel memory will be offloaded to some
> persistent storage disk to keep the system running reliably
> without facing memory pressure.
> More details, alternate approaches considered etc. are present
> in section "D.3 Choices for Storing Snapshots" below.
>
> b. The IMA log will be divided into multiple chunks (snapshots).
> Each snapshot would be a delta between the two instances when
> the log was offloaded from memory to the persistent storage
> disk.
>
> c. Some UM process (like a remote-attestation-client) will be
> responsible for writing the IMA log snapshot to the disk.
>
> d. The same UM process would be responsible for triggering the IMA
> log snapshot.
>
> e. There will be a well-known location for storing the IMA log
> snapshots on the disk. It will be non-trivial for UM processes
> to change that location after booting into the Kernel.
>
> f. A new event, "snapshot_aggregate", will be computed and measured
> in the IMA log as part of this feature. It should help the
> remote-attestation client/service to benefit from the IMA log
> snapshot feature.
> The "snapshot_aggregate" event is described in more details in
> section "D.1 Snapshot Aggregate Event" below.
>
> g. If the existing remote-attestation client/services do not change
> to benefit from this feature or do not trigger the snapshot,
> the Kernel will continue to have it's current functionality of
> maintaining an in-memory full IMA log.
>
> Additionally, the remote-attestation client/services need to be updated
> to benefit from the IMA log snapshot feature. These proposed changes
>
> are described in section "D.4 Remote-Attestation Client/Service Side
> Changes" below, but their implementation is out of scope for this
> proposal.
As previously said on v1,
This design seems overly complex and requires synchronization between the
"snapshot" record and exporting the records from the measurement list. [...]
Concerns:
- Pausing extending the measurement list.
Nothing has changed in terms of the complexity or in terms of pausing
the measurement list. Pausing the measurement list is a non starter.
Userspace can already export the IMA measurement list(s) via the
securityfs {ascii,binary}_runtime_measurements file(s) and do whatever
it wants with it. All that is missing in the kernel is the ability to
trim the measurement list, which doesn't seem all that complicated.
Mimi
