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. -- thanks, Mimi
