On Wed, 2023-08-30 at 16:47 -0400, Paul Moore wrote: > 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. "I imagine tmpfs filesystem could still be forcibly unmounted" sounds like an attack. Not being able to verify the measurement list against a quote is probably a good thing. > > > 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? Nothing changes. New measurements are initially stored in kernel memory, until they are successfully copied. > > 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. It's more than just phrasing, but the purpose/motivation of the proposed changes. -- thanks, Mimi _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
