On Tue, 2023-08-29 at 19:15 -0400, Paul Moore wrote:

On Tue, Aug 29, 2023 at 5:54 PM Mimi Zohar [off-list ref] wrote:

quoted

On Tue, 2023-08-29 at 17:30 -0400, Paul Moore wrote:

quoted

On Tue, Aug 29, 2023 at 5:05 PM Mimi Zohar [off-list ref] wrote:

quoted

On Tue, 2023-08-29 at 15:34 -0400, Paul Moore wrote:

quoted

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

quoted

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?

The main purpose of the change is to addres kernel memory pressure.
Two designs are being discussed: Sush's "snapshotting" design and
Amir's original suggestion of continously exporting the measurement
records to a tmpfs or regular file.  Both designs require verifying the
initial attestation quote by walking the entire measurement list,
calculating the expected TPM PCR value(s).  That doesn't change.

Sure, but my question is about what happens if portions of the
measurement list disappear due to file/filesystem problems?  How is
that handled?

With the "snapshotting" solution there could be multiple files, so
portions could be missing.  The other solution, the preferred solution,
would be one file.

With the snapshotting approach the kernel doesn't need to maintain
ongoing access to a file, that is left up to the user process
performing the attestation (or simply inspecting the logs).  I have to
ask, for the third time now in as many hours, how does the proposed
kernel-holds-an-fd-open solution handle the case where the
file/filesystem is no longer accessible?  The snapshotting approach
should be much more resilient here as the error recovery paths can be
much more involved than what we would have available in the kernel,
not to mention the flexibility of allowing a user process to determine
how to store and manage the snapshotted log.

Considering that the snapshotting approach is opt-in (userspace has to
initiate the snapshot), I'm not sure the concern over log offsets is a
significant objection: existing userspace will never trigger a
snapshot, and new userspace that could potentially trigger a snapshot
should be written to take that into account.

Your initial question was "what happens if the file/filesystem becomes
inaccessible at some point and an attestation client attempts to read
the entire log?".  For what reason would it be inaccessible?  For the
original single tmpfs file, what would make it inaccessible?  In the
"snapshotting" design this problem becomes a userspace issue.

The first sentence of the cover letter is "Depending on the IMA policy,
the IMA log can consume a lot of Kernel memory on the device." 
Copying/exporting the measurements from kernel memory to a single
(tmpfs) file resolves the kernel memory pressure issue.  The entire
measurement list would remain accessible via the securityfs file.  As
previously mentioned in this thread, it wouldn't resolve the kexec
issue of allocating a buffer large enough for really large measurement
lists.

If the real motivation for this patch set is trimming the measurement
list, the cover letter needs to say that.  The existing "snapshotting"
design requires locking of the entire measurement list while copying
and trimming it.  The "snapshotting" design needs to be simplified. 
Perhaps a trusted userspace process could copy the measurements and
then trigger trimming of the in kernel memory/tmpfs measurement list.

-- 
thanks,

Mimi