From: Mimi Zohar <zohar@kernel.org>
To: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
linux-integrity@vger.kernel.org
Cc: Tyler Hicks <tyhicks@linux.microsoft.com>
Subject: Re: Measure data again even when it has not changed
Date: Thu, 30 Jul 2020 08:05:53 -0400 [thread overview]
Message-ID: <1596110753.25003.3.camel@kernel.org> (raw)
In-Reply-To: <a83fdf87-d98e-b5cd-2557-2fae88b09a13@linux.microsoft.com>
On Wed, 2020-07-29 at 20:41 -0700, Lakshmi Ramasubramanian wrote:
> On 7/29/20 8:23 PM, Mimi Zohar wrote:
>
> > On Wed, 2020-07-29 at 10:17 -0700, Lakshmi Ramasubramanian wrote:
> >> Hi Mimi,
> >>
> >> I have a query related to measuring data (by IMA subsystem) when that
> >> data has been already been measured.
> >>
> >> Consider the following sequence of events:
> >>
> >> => At time T0 IMA hook is called by another subsystem to measure data
> >> "foo". IMA measures it.
> >>
> >> => At time T1 data is "bar". IMA measures it.
> >>
> >> => At time T2 data is "foo" again. But IMA doesn't measure it since it
> >> is already in the measured list.
> >>
> >> But for the subsystem making the call to IMA, the state has changed and
> >> "foo" has to be measured again.
> >>
> >> One way to address the above is to use unique "event name" in each call
> >> so that IMA measures the given data every time.
> >>
> >> Is there a better way to address the above?
> >
> > Most likely the file is being re-measured, but the new value already exists in
> > the hash table so it isn't being added to the IMA measurement list or extending
> > the TPM. When IMA was upstreamed, there was concern about TPM performance and
> > the number of measurements being extended. We've improved TPM performance quite
> > a bit. If you're not concerned about TPM performance, I would define a new
> > template data field based on i_version.
>
> In the use case I am considering the entity being measured is not a
> file, but a memory buffer - it is for measuring an LSM's data
> constructs. So i_version is not available in this case.
>
> When LSM's data changes from A to B and then back to A, hash(A) already
> exists in IMA's hash table. So A is not measured again.
>
> Since LSM state change is not expected to be frequent, TPM performance
> shouldn't be a concern.
Wouldn't a unique event name result in a new measurement every time?
Mimi
next prev parent reply other threads:[~2020-07-30 12:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-29 17:17 Measure data again even when it has not changed Lakshmi Ramasubramanian
2020-07-30 3:23 ` Mimi Zohar
2020-07-30 3:41 ` Lakshmi Ramasubramanian
2020-07-30 12:05 ` Mimi Zohar [this message]
2020-07-30 13:12 ` Lakshmi Ramasubramanian
2020-07-30 14:05 ` Stephen Smalley
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=1596110753.25003.3.camel@kernel.org \
--to=zohar@kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=nramas@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.