[RFC] IMA Log Snapshotting Design Proposal

Paul Moore paul at paul-moore.com
Wed Aug 30 13:47:40 PDT 2023


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.

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

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

-- 
paul-moore.com



More information about the kexec mailing list