linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Raphael Gianotti <raphgi@linux.microsoft.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: Thu, 07 Jan 2021 10:06:31 -0500	[thread overview]
Message-ID: <87127d502bcb9707dd4e7a43475ab6bed2fdd421.camel@linux.ibm.com> (raw)
In-Reply-To: <20210105195742.2629-1-raphgi@linux.microsoft.com>

[Cc: Amir Goldstein]

On Tue, 2021-01-05 at 11:57 -0800, Raphael Gianotti wrote:
> IMA measures files and buffer data and some systems may end up
> generating lots of entries in the IMA measurement list. This list is
> kept in kernel memoryc and as it grows in size it could end up taking
> too many resources, causing the system to run out of available
> memory. During kexec, the IMA measurement list can be carried over in
> memory, but it's possible for the list to become too large for that
> to happen.
> 
> The Kconfig introduced in this series enables admins to configure a
> maximum number of entries and a file to export the IMA measurement
> list to whenever the set limit is reached.
> 
> The list is written out in append mode, so the system will keep
> writing new entries as long as it stays running or runs out of
> space. Whenever the export file is set, it's truncated. If writing
> to the export list fails, a flag is set to prevent further exports,
> as the file is likely in a bad state. Setting a new export file
> resets this flag, allowing exports to resume and giving admins a way
> to recover from this state if necessary.
> 
> In the case of kexec, if the list is too large too be carried over in
> memory and an export file is configured, the list will be exported,
> preventing the measurements from being lost during kexec.
> 
> This code is based off of a previous RFC sent by Janne Karhunen[1],
> and is intended to pick up where that was left off.
> 
> In a thread with Janne Karhunen[2], it was mentioned that another
> approach, using mm had been considered. Upon some investigation the
> approach used in this RFC still seemed adequate for solving this
> problem.
> 
> [1] https://patchwork.kernel.org/project/linux-integrity/patch/201912
> 20074929.8191-1-janne.karhunen@gmail.com/
> [2] https://lore.kernel.org/linux-integrity/CAE=NcrbdS-3gVvnnEwdNSOLO
> vTenLjyppDz2aJACGRgBYSh=Gw@mail.gmail.com/
> 
> Signed-off-by: Raphael Gianotti <raphgi@linux.microsoft.com>

My original concerns of truncating the IMA measurement list have not
been addressed.  Once the IMA measurement list has been truncated,
quoting and then verifying any of the PCRs contained in the measurement
list will fail, unless the measurements have been preserved and are
readily accessible.

Amir's suggestion addresses kernel memory constraints without
truncating the IMA measurement list.

Mimi


  reply	other threads:[~2021-01-07 15:10 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 [this message]
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
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=87127d502bcb9707dd4e7a43475ab6bed2fdd421.camel@linux.ibm.com \
    --to=zohar@linux.ibm.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=raphgi@linux.microsoft.com \
    --cc=tusharsu@linux.microsoft.com \
    --cc=tyhicks@linux.microsoft.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).