On Wed, 2023-08-30 at 19:22 -0400, Paul Moore wrote: > On Wed, Aug 30, 2023 at 7:07 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > On Wed, 2023-08-30 at 18:23 -0400, Paul Moore wrote: > > > On Wed, Aug 30, 2023 at 6:21 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > > On Wed, Aug 30, 2023 at 5:50 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > > > > 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. > > > > > > > > Okay, can you answer the question for an arbitrary persistent > > > > filesystem? That was always the more important question, ... > > > > The original proposal, not mine, suggested using a tmpfs file. The > > idea of writing the measurements to a file on a persistent filesystem > > wasn't mine either. Sush/Tushar were pushing for writing to a > > persistent file(s). No argument from me that writing to a file on an > > arbitrary persistent filesystem is not a good idea. > > ... Okay, so we all now agree that the kernel writing to an > arbitrary filesystem is not a good idea, and using tmpfs doesn't solve > the problem of general memory pressure (from previously in this > thread), that's all helpful and good to clarify. Do we also agree that the "tmpfs" solution would address the existing design motivation - kernel memory pressure? > > Assuming Sush and Tushar rework the document to clarify the > motivation/purpose for the work, as you suggested earlier, I'm > assuming we can revisit this problem and solutions? In addition to the mismatch between the motivation and the design, the design has some major flaws that first need to be addressed. Assuming the design issues are addressed, please make sure the document is written clearly and concisely. -- thanks, Mimi
