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, and your > continued avoidance is getting me increasingly annoyed. Speaking of being annoyed, I'm fixing Tushar's email as the bounces are also driving me nuts. -- paul-moore.com