linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Raphael Gianotti <raphgi@linux.microsoft.com>
To: Mimi Zohar <zohar@linux.ibm.com>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	janne.karhunen@gmail.com
Cc: linux-integrity@vger.kernel.org, tusharsu@linux.microsoft.com,
	tyhicks@linux.microsoft.com, nramas@linux.microsoft.com,
	balajib@linux.microsoft.com, Amir Goldstein <amir73il@gmail.com>
Subject: Re: [RFC] Persist ima logs to disk
Date: Fri, 8 Jan 2021 09:58:33 -0800	[thread overview]
Message-ID: <fc9a5d48-dc29-0d5d-55dd-bacac346da10@linux.microsoft.com> (raw)
In-Reply-To: <8c78437d0e9a4968996b834030661b6f567f87eb.camel@linux.ibm.com>


On 1/8/2021 4:38 AM, Mimi Zohar wrote:
> On Thu, 2021-01-07 at 14:57 -0800, Raphael Gianotti wrote:
>>>>>> But this doesn't address where the offloaded measurement list
>>>>>> will be stored, how long the list will be retained, nor who
>>>>>> guarantees the integrity of the offloaded list.  In addition,
>>>>>> different form factors will have different requirements.
>> For how long the list would be retained, or in the case of a log segments, it
>> might make sense to have that be an admin decision, something that can be
>> configured to satisfy the needs of a specific system, as mentioned below by
>> James, does that seem correct?
> For the discussion on exporting and truncating the IMA measurement
> list, refer to:
> https://lore.kernel.org/linux-integrity/1580998432.5585.411.camel@linux.ibm.com/
>
>> Given the possibility of keeping the logs around for an indefinite amount of
>> time, would using an expansion of the method present in this RFC be more
>> appropriate than going down the vfs_tmpfile route? Forgive my lack on expertise
>> on mm, but would the vfs_tmpfile approach work for keeping several log segments
>> across multiple kexecs?
> With the "vfs_tmpfile" mechanism, breaking up and saving the log in
> segments isn't needed.  The existing mechanism for carrying the
> measurement list across kexec would still be used.  Currently, if the
> kernel cannot allocate the memory needed for carrying the measurement
> across kexec, it simply emits an error message, but continues with the
> kexec.

In this change I had introduced "exporting" the log to disk when the size
of the measurement list was too large. Given part of the motivation behind
moving the measurement list is the possibility of it growing too large
and taking up too much of the kernel memory, that case would likely lead
to kexec not being able to carry over the logs. Do you believe it's better
to use the "vfs_tmpfile" mechanism for moving the logs to disk and worry
about potential issues with kexec not being able to carry over the logs
separately, given the "vfs_tempfile" approach seems to be preferred and
also simplifies worries regarding truncating the logs?

>
> Mimi

  reply	other threads:[~2021-01-08 17:59 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-05 19:57 [RFC] Persist ima logs to disk Raphael Gianotti
2021-01-07 15:06 ` Mimi Zohar
2021-01-07 16:42   ` James Bottomley
2021-01-07 20:02     ` Mimi Zohar
2021-01-07 20:37       ` James Bottomley
2021-01-07 20:51         ` Mimi Zohar
2021-01-07 21:48           ` James Bottomley
2021-01-07 22:57             ` Raphael Gianotti
2021-01-08 12:38               ` Mimi Zohar
2021-01-08 17:58                 ` Raphael Gianotti [this message]
2021-02-01 22:53                   ` Raphael Gianotti
2021-02-02  5:54                     ` Amir Goldstein
2021-02-02 13:07                       ` Mimi Zohar
2021-02-02 18:14                         ` Raphael Gianotti
2021-02-03  1:02                           ` Mimi Zohar
2021-02-03  7:24                             ` Amir Goldstein
2021-02-03 18:45                               ` Mimi Zohar
2021-02-09 17:20                                 ` Raphael Gianotti
2021-02-09 18:08                                   ` Mimi Zohar
2021-01-07 23:00             ` Mimi Zohar
2021-01-07 18:32   ` Raphael Gianotti
2021-01-07 15:45 ` Janne Karhunen
2021-01-07 18:35   ` Raphael Gianotti

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fc9a5d48-dc29-0d5d-55dd-bacac346da10@linux.microsoft.com \
    --to=raphgi@linux.microsoft.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=amir73il@gmail.com \
    --cc=balajib@linux.microsoft.com \
    --cc=janne.karhunen@gmail.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=nramas@linux.microsoft.com \
    --cc=tusharsu@linux.microsoft.com \
    --cc=tyhicks@linux.microsoft.com \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).