On Mon, Aug 21, 2023 at 7:08 PM Mimi Zohar [off-list ref] wrote:

On Mon, 2023-08-21 at 15:05 -0700, Sush Shringarputale wrote:

quoted

On 8/14/2023 3:02 PM, Mimi Zohar wrote:

quoted

On Mon, 2023-08-14 at 14:42 -0700, Sush Shringarputale wrote:

quoted

quoted

This design seems overly complex and requires synchronization between
the "snapshot" record and exporting the records from the measurement
list.  None of this would be necessary if the measurements were copied
from kernel memory to a backing file (e.g. tmpfs), as described in [1].

Even if the Kernel maintains the link between a tmpfs exported and an
in-memory IMA log - it still has to copy the tmpfs portion to the
Kernel memory during kexec soft boot.  tmpfs is cleared during kexec,
so this copying of tmpfs back to kernel memory is necessary to preserve
the integrity of the log during kexec.  But the copying would add back
the memory pressure on the node during kexec (which may result in
out-of-memory), defeating the purpose of the overall effort/feature.
Copying to a regular *persistent* protected file seems a cleaner
approach, compared to tmpfs.

From a kernel perspective, it doesn't make a difference if userspace
provides a tmpfs or persistent file.  As per the discussion
https://lore.kernel.org/linux-integrity/CAOQ4uxj4Pv2Wr1wgvBCDR-tnA5dsZT3rvdDzKgAH1aEV_-r9Qg@mail.gmail.com/#t (local)
, userspace provides the kernel with the file descriptor of the opened
file.

quoted

We prototyped this solution, however it
does not seem to be a common pattern within the Kernel to write state
directly to files on disk file systems.  We considered two potential
options:

If no file descriptor is provided, then the measurements aren't copied
and removed from the securityfs file.  If there are write errors, the
measurements aren't removed from the securityfs file until the write
errors are resolved.

It sounds like this approach would require the file/filesystem to be
continuously available for the life of the system once the log was
snapshotted/overflowed to persistent storage, yes?  Assuming that is
the case, what happens if the file/filesystem becomes inaccessible at
some point and an attestation client attempts to read the entire log?

-- 
paul-moore.com