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
