Linux Integrity Measurement development
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: ltp@lists.linux.it, linux-integrity@vger.kernel.org
Subject: Re: [PATCH] ima_tpm.sh: update test2 to detect integrity violations
Date: Tue, 18 Aug 2026 10:20:23 +0200	[thread overview]
Message-ID: <20260818082023.GA2038472@pevik> (raw)
In-Reply-To: <2fb152d374a14a0e30b20de73d74a90b195e0793.camel@linux.ibm.com>

Hi Mimi,

> Hi Petr,

> On Mon, 2026-08-17 at 12:55 +0200, Petr Vorel wrote:
> > Hi Mimi,

> > > <securityfs>/integrity/ima/violations reflects the number of
> > > integrity violations.  Include the "--ignore-violations" option,
> > > if there are any violations, on the initial IMA measurement list
> > > verification.

> > Thanks for your patch!

> > LGTM and it should be fixed. But there are some potential problems
> > (see bellow).

> And here I thought this was a simple performance improvement to execute evmctl
> with/without the --ignore-violations option once.

FYI back then I did not worry that much about performance (i.e. running evmctl
once or twice does not matter to me), I wanted to keep test coverage on vast
majority of distro versions (old and new). Maybe it's not that important.

> > > Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
> > > ---
> > >  .../security/integrity/ima/tests/ima_tpm.sh   | 20 ++++++++++++-------
> > >  1 file changed, 13 insertions(+), 7 deletions(-)

> > > diff --git a/testcases/kernel/security/integrity/ima/tests/ima_tpm.sh b/testcases/kernel/security/integrity/ima/tests/ima_tpm.sh
> > > index 5d34d8679..acd8b6d30 100755
> > > --- a/testcases/kernel/security/integrity/ima/tests/ima_tpm.sh
> > > +++ b/testcases/kernel/security/integrity/ima/tests/ima_tpm.sh
> > > @@ -142,6 +142,8 @@ read_pcr_tpm2()
> > >  get_pcr10_aggregate()
> > >  {
> > >  	local cmd="evmctl -vv ima_measurement $BINARY_MEASUREMENTS"
> > > +	local violations="$IMA_DIR/violations"
> > > +	local num_violations=0
> > >  	local msg="$ERRMSG_EVMCTL"
> > >  	local res=TCONF
> > >  	local pcr ret
> > > @@ -151,16 +153,20 @@ get_pcr10_aggregate()
> > >  		res=TFAIL
> > >  	fi

> > > -	$cmd > hash.txt 2>&1
> > > -	ret=$?
> > > -	if [ $ret -ne 0 -a -z "$MISSING_EVMCTL" ]; then
> > > -		tst_res TFAIL "evmctl failed, trying with --ignore-violations"
> > You removed TFAIL (potential problem, see later).

> > > +	if [ ! -f "$violations" ]; then
> > > +		tst_res TINFO "missing $violations"
> > > +	else
> > > +		num_violations=$(cat "$violations")
> > > +	fi
> > > +
> > > +	if [ "$num_violations" -eq 0 ]; then
> > > +		$cmd > hash.txt 2>&1
> > > +		ret=$?
> > > +	else
> > > +		tst_res TINFO "ignoring $num_violations violations"
> > >  		cmd="$cmd --ignore-violations"
> > >  		$cmd > hash.txt 2>&1
> > >  		ret=$?
> > > -	elif [ $ret -ne 0 -a "$MISSING_EVMCTL" = 1 ]; then
> > > -		tst_res TFAIL "evmctl failed $msg"
> > And here again removed TFAIL (see later).

> > The main problem is that you removed the code when evmctl is not installed.

> If I'm understanding the code correctly, the original code executed evmctl
> whether it existed or not.  Let's fix that first.  My question is whether the
IMHO no.

> test should fail or be skipped?

The original intention in 7fd7c9febd [1] was to run without --ignore-violations
on any evmctl and if test fails (recorded always as TFAIL) and evmctl is new
enough rerun it with --ignore-violations.  (Simply not run for the second time
and just fail on missing evmctl or evmctl being too old to support
--ignore-violations.) Quoting the kernel commit for the reason:

	For old kernels which use SHA1/MD5, any evmctl version is required (evmctl
	ima_measurement was introduced in very old v0.7), but:
	* newer sysctl path /sys/class/tpm/tpm0/device/pcrs requires evmctl 1.1
	* using ima_policy=tcb requires 1.3.1 due --ignore-violations

	For evmctl >= 1.3.1 on failure we try to retest with --ignore-violations.

Is it a wrong approach? Looking on your patch it probably is wrong approach
(not taking /sys/kernel/security/ima/violations into account).

Also, as $MISSING_EVMCTL is taking into account in the results, it should be
safe.

[1] https://github.com/linux-test-project/ltp/commit/7fd7c9febdd7ed48ae3563923074bcabdfec3923

> > Therefore trying to rerun evmctl on failure on older release (e.g. 1.3) it will
> > fail due option have different name or not exist at all in evmctl < 1.2).
> > -a "$MISSING_EVMCTL" = 1 check had meaning "don't rerun with --ignore-violations
> > on old evmctl which does not have the option.

And $MISSING_EVMCTL is a bit misleading name, because 1 means either "evmctl not
installed at all" or "installed old evmctl version" (MISSING_SUITABLE_EVMCTL or
something would be more obvious).

> Thank you for the explanation.

+1, thank you too for your explanation.

> Before appending the "--ignore-violations" we should make sure it is supported.
Yes. And I hoped that code in the setup() resulting in $MISSING_EVMCTL did it
correctly.

> I guess for backwards compatibility we still want to verify the measurement
> list, knowing it will fail.

Yes.

> Hopefully with these two changes this patch will work properly.

Reviewed-by: Petr Vorel <pvorel@suse.cz>
(plan to merge tomorrow, in case there is any feedback)

BTW when run on new system (recent Tumbleweed) without evmctl the second TCONF
message is misleading a bit but let's ignore it:

ima_tpm 1 TINFO: TPM hardware support not enabled in kernel or no TPM chip found, testing TPM-bypass
ima_tpm 1 TCONF: 'evmctl' not found
ima_tpm 1 TCONF: algorithm not sha1 (sha256) => install evmctl >= 1.3.1

And other issue is that parsing kernel config in setup() should be replaced with
API function tst_check_kconfigs (less error-prone, it can ballback to
/proc/config.gz, etc). That's my TODO.

Kind regards,
Petr

> Mimi


> > FYI the code is a bit complicated, because here on TPM2 we require evmctl 1.3.1
> > to have --ignore-violations (renamed from --validate), which was released in
> > 2020 - too new for old enterprise distros to ignore; also TPM1 we require only
> > 1.1 from 2018, probably still too new. Once SLE12-SP3 EOL (in 1 year we may just
> > expect 1.3.1 to simplify).

> > > -		return
> > >  	fi

> > >  	[ $ret -ne 0 ] && tst_res TWARN "evmctl failed, trying to continue $msg"
> > Back to removed TFAIL. While this is OK as TWARN (some problem, but not related
> > to testing) we might end up to TBROK "Test didn't report any results" error in
> > tst_test.sh which quits test with TBROK "Test didn't report any results" if
> > there is no TPASS/TFAIL/TCONF message.

> > _tst_resstr()
> > {
> > 	echo "$TST_PASS$TST_FAIL$TST_CONF"
> > }

> > _tst_rescmp()
> > {
> > 	local res=$(_tst_resstr)

> > 	if [ "$1" = "$res" ]; then
> > 		tst_brk TBROK "Test didn't report any results"
> > 	fi
> > }

> > And this happen later in test2():
> > 	get_pcr10_aggregate > tmp.txt
> > 	pcr_aggregate="$(cat tmp.txt)"
> > 	if [ -z "$pcr_aggregate" ]; then
> > 		return
> > 	fi

> > Other option would be to print TFAIL message in test2():

> > 	get_pcr10_aggregate > tmp.txt
> > 	pcr_aggregate="$(cat tmp.txt)"
> > 	if [ -z "$pcr_aggregate" ]; then
> > 		tst_res TBROK "failed to get aggregate PCR-10"
> > 		return
> > 	fi

> > Lol, I'm disappointed how complicated and error prone I wrote back then.
> > Part of the problem is that quit with tst_brk does not work, when code which
> > does it is run in a subshell (via $(...) or `...) ), which quits subshell but
> > not the parent shell.

      reply	other threads:[~2026-08-18  8:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-14 13:57 [PATCH] ima_tpm.sh: update test2 to detect integrity violations Mimi Zohar
2026-08-17 10:55 ` Petr Vorel
2026-08-17 22:13   ` Mimi Zohar
2026-08-18  8:20     ` Petr Vorel [this message]

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=20260818082023.GA2038472@pevik \
    --to=pvorel@suse.cz \
    --cc=linux-integrity@vger.kernel.org \
    --cc=ltp@lists.linux.it \
    --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