On Tue, 2023-08-29 at 19:15 -0400, Paul Moore wrote: > On Tue, Aug 29, 2023 at 5:54 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > On Tue, 2023-08-29 at 17:30 -0400, Paul Moore wrote: > > > On Tue, Aug 29, 2023 at 5:05 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > > > On Tue, 2023-08-29 at 15:34 -0400, Paul Moore wrote: > > > > > On Mon, Aug 21, 2023 at 7:08 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > > > > > On Mon, 2023-08-21 at 15:05 -0700, Sush Shringarputale wrote: > > > > > > > On 8/14/2023 3:02 PM, Mimi Zohar wrote: > > > > > > > > On Mon, 2023-08-14 at 14:42 -0700, Sush Shringarputale wrote: > > > > > > > >>> 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@xxxxxxxxxxxxxx/#t > > > > > > , userspace provides the kernel with the file descriptor of the opened > > > > > > file. > > > > > > > > > > > > > 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 _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
