On Wed, Aug 30, 2023 at 4:25 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > 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 your reply that I had responded to you had mentioned that the kernel was simply being passed a fd and taking ownership of it, the fd could either be a tmpfs backed file or some form of persistent storage as both were discussed in this thread. I imagine a tmpfs filesystem could still be forcibly unmounted, resulting in problems, but I can't say that for certain. However, there are definitely cases where a fd backed against an arbitrary filesystem could run into problems: storage device issues for local filesystems, networking issues for network filesystems, and good old fashioned user/admin intervention in both cases. > In the > "snapshotting" design this problem becomes a userspace issue. Yes, exactly. Userspace is almost always going to have an easier time recovering from these types of errors ... or at least I believe so, perhaps you have a clever solution for how the kernel can handle the file/filesystem disappearing from under the fd? > 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." ... As I'm still looking for an answer to my question, let's stay focused on that before we start worrying too much about the phrasing of the design proposal that was submitted. -- paul-moore.com _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
