[RFC] IMA Log Snapshotting Design Proposal

[Paul Moore]

On Thu, Aug 31, 2023 at 10:07 AM Mimi Zohar <zohar at linux.ibm.com> wrote:
> On Wed, 2023-08-30 at 19:22 -0400, Paul Moore wrote:
> > On Wed, Aug 30, 2023 at 7:07 PM Mimi Zohar <zohar at linux.ibm.com> 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 at paul-moore.com> wrote:
> > > > > On Wed, Aug 30, 2023 at 5:50 PM Mimi Zohar <zohar at linux.ibm.com> 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 at linux.ibm.com> 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?

I haven't really looked into that so I'm not comfortable commenting on
that.  I can say that in off-list discussions with Sush, Tushar, and
others the issue we are facing is general memory pressure so using any
type of memory backed filesystem doesn't really resolve our problem.

> > 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.

That feels like a normal part of the design, review, and iterate cycle
to me.  Sush and Tushar are following along and I'm sure they will
take all of that into account in the next revision of the design
document.

-- 
paul-moore.com