All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Petr Vorel <pvorel@suse.cz>
Cc: ltp@lists.linux.it, Mimi Zohar <zohar@linux.vnet.ibm.com>,
	Petr Cervinka <pcervinka@suse.com>,
	Cyril Hrubis <chrubis@suse.cz>,
	linux-integrity@vger.kernel.org,
	Vitaly Chikunov <vt@altlinux.org>
Subject: Re: [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
Date: Thu, 28 May 2020 11:19:05 -0400	[thread overview]
Message-ID: <1590679145.4457.39.camel@linux.ibm.com> (raw)
In-Reply-To: <20200528140747.GA8401@dell5510>

On Thu, 2020-05-28 at 16:07 +0200, Petr Vorel wrote:
> Hi Mimi,
> 
> thanks a lot for testing!
> 
> > On Wed, 2020-05-27 at 09:14 +0200, Petr Vorel wrote:
> > > Fixes test for kernel commit: 6f1a1d103b48 ima: ("Switch to
> > > ima_hash_algo for boot aggregate") from current linux-integrity tree.
> 
> > > Tests was failing, because it expect SHA1 hash, but for TPM 2.0 is
> > > now used IMA default hash algorithm (by default default SHA256).
> > > This is similar for entries in IMA measurement list so we can reuse
> > > already existing code.
> 
> > > Signed-off-by: Petr Vorel <pvorel@suse.cz>
> > > ---
> > > changes v1->v2:
> > > * removing global variables from get_algorithm_digest (hopefully it's
> > > less ugly)
> 
> > > Tested only on VM. Can anybody test it on real HW?
> 
> > With just this change, the ima_tpm.sh test is failing.  I assume it is
> > failing because it is reading the SHA1 TPM bank, not the SHA256 bank
> > to calculate the boot_aggregate hash.
> First question: is it correct to take sha256? Because on my test below it's
> reading sha1, because that's the content of /sys/kernel/security/ima/ascii_runtime_measurements
> 
> I thought just kernel commit: 6f1a1d103b48 ima: ("Switch to ima_hash_algo for
> boot aggregate") from current linux-integrity tree is needed, but I tested it on
> b59fda449cf0 ("ima: Set again build_ima_appraise variable") (i.e. having all
> Robeto's ima patches,  missing just last 2 commits from next-integrity head).
> What is needed to get your setup?

This isn't a configuration problem, but an issue of reading PCRs and
calculating the TPM bank appropriate boot_aggregate.  If you're
calculating a sha256 boot_aggregate, then the test needs to read and
calculate the boot_aggregate by reading the SHA256 TPM bank.

> We both have CONFIG_IMA_DEFAULT_HASH_SHA256=y and CONFIG_IMA_DEFAULT_HASH="sha256".
> 
> > ima_tpm 1 TINFO: timeout per run is 0h 5m 0s
> > ima_tpm 1 TINFO: IMA kernel config:
> > ima_tpm 1 TINFO: CONFIG_IMA=y
> > ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10
> > ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y
> > ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y
> > ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
> > ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y
> > ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256"
> > ima_tpm 1 TINFO: CONFIG_IMA_WRITE_POLICY=y
> > ima_tpm 1 TINFO: CONFIG_IMA_READ_POLICY=y
> > ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y
> > ima_tpm 1 TINFO: CONFIG_IMA_ARCH_POLICY=y
> > ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y
> > ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS=y
> > ima_tpm 1 TINFO: CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS=y
> > ima_tpm 1 TINFO: CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT=y
> > ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.6.0-rc3+.signed root=UUID=119f1a79-c391-4e37-905d-3a503284cadb ro quiet splash ima-policy=tcb
> > ima_tpm 1 TINFO: verify boot aggregate
> > ima_tpm 1 TINFO: used algorithm: sha256
> > ima_tpm 1 TINFO: IMA boot aggregate: 'b2341e4ccea25be7fa750830fb5fdf4bef1c44a4'
> > ima_tpm 1 TFAIL: bios boot aggregate does not match IMA boot aggregate (3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5b)
> > ima_tpm 2 TINFO: verify PCR values
> > ima_tpm 2 TINFO: evmctl version: evmctl 1.2
> > ima_tpm 2 TCONF: TPM Hardware Support not enabled in kernel or no TPM chip found
> > ima_tpm 3 TINFO: AppArmor enabled, this may affect test results
> > ima_tpm 3 TINFO: it can be disabled with TST_DISABLE_APPARMOR=1 (requires super/root)
> > ima_tpm 3 TINFO: loaded AppArmor profiles: none
> 
> > Summary:
> > passed   0
> > failed   1
> > skipped  1
> > warnings 0
> 
> 
> BTW my results on custom kernel:
> ima_tpm 1 TINFO: timeout per run is 0h 5m 0s
> ima_tpm 1 TINFO: IMA kernel config:
> ima_tpm 1 TINFO: CONFIG_IMA=y
> ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10
> ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y
> ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256"
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_BOOTPARAM=y
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_MODSIG=y
> ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y
> ima_tpm 1 TINFO: CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY=y
> ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.3.18-20-default root=/dev/mapper/system-root crashkernel=121M,high crashkernel=72M,low isofrom=/dev/disk/by-uuid/3271-1AD6:/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso isofrom_device=/dev/disk/by-uuid/3271-1AD6 isofrom_system=/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso loader=syslinux quiet resume=/dev/system/swap splash=silent quiet showopts
> ima_tpm 1 TINFO: IMA kernel config:
> ima_tpm 1 TINFO: CONFIG_IMA=y
> ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10
> ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y
> ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256"
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_BOOTPARAM=y
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_MODSIG=y
> ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y
> ima_tpm 1 TINFO: CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY=y
> ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.3.18-20-default root=/dev/mapper/system-root crashkernel=121M,high crashkernel=72M,low isofrom=/dev/disk/by-uuid/3271-1AD6:/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso isofrom_device=/dev/disk/by-uuid/3271-1AD6 isofrom_system=/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso loader=syslinux quiet resume=/dev/system/swap splash=silent quiet showopts
> ima_tpm 1 TINFO: verify boot aggregate
> ima_tpm 1 TINFO: used algorithm: sha1
> ima_tpm 1 TINFO: IMA boot aggregate: '1172f0990296510ed39403b4f1de83c82e093aae'
> ima_tpm 1 TPASS: bios boot aggregate matches IMA boot aggregate (1172f0990296510ed39403b4f1de83c82e093aae)
> ima_tpm 2 TINFO: verify PCR values
> ima_tpm 2 TINFO: evmctl version: evmctl 1.2.1
> ima_tpm 2 TINFO: new PCRS path, evmctl >= 1.1 required
> ima_tpm 2 TINFO: verify PCR (Process Control Register)
> ima_tpm 2 TPASS: aggregate PCR value matches real PCR value
> 
> Summary:
> passed   2
> failed   0
> skipped  0
> warnings 0
> 
> 
> > # head -1 /sys/kernel/security/ima/ascii_runtime_measurements
> 
> > 10 a3132d2501128ff527171658d40d8deb61e2292b ima-ng
> > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5
> > b boot_aggregate
> 
> mine:
> 10 c125a1d3684a9737f20f6c1bc880782fae60fb28 ima-ng sha1:1172f0990296510ed39403b4f1de83c82e093aae boot_aggregate
> 
> > The ima-evm-utils next-testing branch has code to calculate the
> > boot_aggregate based on multiple banks.
> I see, 696bf0b ("ima-evm-utils: calculate the digests for multiple TPM banks")
> I wonder whether it's reasonable trying to port that to ima_boot_aggregate.c or
> just depend on evmctl. External dependencies are sometimes complicated, but for
> IMA I incline to just require evmctl.

Unlike TPM 1.2, the TPM 2.0 device driver doesn't export the TPM PCRs.
 Not only would you have a dependency on ima-evm-utils, but also on a
userspace application(s) for reading the TPM PCRs.  That dependency
exists whether you're using evmctl to calculate the boot_aggregate or
doing it yourself.

> 
> > # evmctl ima_boot_aggregate
> 
> > sha1:4cf3d105b1a1a41b951cc6431f0801c01fe50b24
> > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5b
> 
> Thus obviously evmctl (from next-testing) also gets only sha1
> ./src/evmctl ima_boot_aggregate
> sha1:1172f0990296510ed39403b4f1de83c82e093aae
> 
> > There's also a new test to verify the boot_aggregate.
> 
> > $ VERBOSE=1 make check TESTS=boog_aggregate.test
> BTW I got some errors
> ...
> make  check-TESTS
> make[2]: Entering directory '/home/foo/ima-evm-utils/tests'
> make[3]: Entering directory '/home/foo/ima-evm-utils/tests'
> make[4]: Entering directory '/home/foo/ima-evm-utils/tests'
> make[4]: Nothing to be done for 'boog_aggregate.log'.
> make[4]: Leaving directory '/home/foo/ima-evm-utils/tests'
> fatal: making test-suite.log: failed to create boog_aggregate.trs
> fatal: making test-suite.log: failed to create boog_aggregate.log
> make[3]: *** [Makefile:516: test-suite.log] Error 1
> make[3]: Leaving directory '/home/foo/ima-evm-utils/tests'
> make[2]: *** [Makefile:625: check-TESTS] Error 2
> make[2]: Leaving directory '/home/foo/ima-evm-utils/tests'
> make[1]: *** [Makefile:692: check-am] Error 2
> make[1]: Leaving directory '/home/foo/ima-evm-utils/tests'
> make: *** [Makefile:514: check-recursive] Error 1

[Cc'ing Vitaly]

The boot_aggregate.trs and boot_aggregate.log files are being created
in the tests/ directory.  Is that directory read-only?
 
> 
> > Both need some review and testing before being released.
> Any estimation when code is released?

Probably not before the next open window, but definitely before it is
released.

Mimi

WARNING: multiple messages have this Message-ID (diff)
From: Mimi Zohar <zohar@linux.ibm.com>
To: ltp@lists.linux.it
Subject: [LTP] [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
Date: Thu, 28 May 2020 11:19:05 -0400	[thread overview]
Message-ID: <1590679145.4457.39.camel@linux.ibm.com> (raw)
In-Reply-To: <20200528140747.GA8401@dell5510>

On Thu, 2020-05-28 at 16:07 +0200, Petr Vorel wrote:
> Hi Mimi,
> 
> thanks a lot for testing!
> 
> > On Wed, 2020-05-27 at 09:14 +0200, Petr Vorel wrote:
> > > Fixes test for kernel commit: 6f1a1d103b48 ima: ("Switch to
> > > ima_hash_algo for boot aggregate") from current linux-integrity tree.
> 
> > > Tests was failing, because it expect SHA1 hash, but for TPM 2.0 is
> > > now used IMA default hash algorithm (by default default SHA256).
> > > This is similar for entries in IMA measurement list so we can reuse
> > > already existing code.
> 
> > > Signed-off-by: Petr Vorel <pvorel@suse.cz>
> > > ---
> > > changes v1->v2:
> > > * removing global variables from get_algorithm_digest (hopefully it's
> > > less ugly)
> 
> > > Tested only on VM. Can anybody test it on real HW?
> 
> > With just this change, the ima_tpm.sh test is failing. ?I assume it is
> > failing because it is reading the SHA1 TPM bank, not the SHA256 bank
> > to calculate the boot_aggregate hash.
> First question: is it correct to take sha256? Because on my test below it's
> reading sha1, because that's the content of /sys/kernel/security/ima/ascii_runtime_measurements
> 
> I thought just kernel commit: 6f1a1d103b48 ima: ("Switch to ima_hash_algo for
> boot aggregate") from current linux-integrity tree is needed, but I tested it on
> b59fda449cf0 ("ima: Set again build_ima_appraise variable") (i.e. having all
> Robeto's ima patches,  missing just last 2 commits from next-integrity head).
> What is needed to get your setup?

This isn't a configuration problem, but an issue of reading PCRs and
calculating the TPM bank appropriate boot_aggregate. ?If you're
calculating a sha256 boot_aggregate, then the test needs to read and
calculate the boot_aggregate by reading the SHA256 TPM bank.

> We both have CONFIG_IMA_DEFAULT_HASH_SHA256=y and CONFIG_IMA_DEFAULT_HASH="sha256".
> 
> > ima_tpm 1 TINFO: timeout per run is 0h 5m 0s
> > ima_tpm 1 TINFO: IMA kernel config:
> > ima_tpm 1 TINFO: CONFIG_IMA=y
> > ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10
> > ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y
> > ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y
> > ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
> > ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y
> > ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256"
> > ima_tpm 1 TINFO: CONFIG_IMA_WRITE_POLICY=y
> > ima_tpm 1 TINFO: CONFIG_IMA_READ_POLICY=y
> > ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y
> > ima_tpm 1 TINFO: CONFIG_IMA_ARCH_POLICY=y
> > ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y
> > ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS=y
> > ima_tpm 1 TINFO: CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS=y
> > ima_tpm 1 TINFO: CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT=y
> > ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.6.0-rc3+.signed root=UUID=119f1a79-c391-4e37-905d-3a503284cadb ro quiet splash ima-policy=tcb
> > ima_tpm 1 TINFO: verify boot aggregate
> > ima_tpm 1 TINFO: used algorithm: sha256
> > ima_tpm 1 TINFO: IMA boot aggregate: 'b2341e4ccea25be7fa750830fb5fdf4bef1c44a4'
> > ima_tpm 1 TFAIL: bios boot aggregate does not match IMA boot aggregate (3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5b)
> > ima_tpm 2 TINFO: verify PCR values
> > ima_tpm 2 TINFO: evmctl version: evmctl 1.2
> > ima_tpm 2 TCONF: TPM Hardware Support not enabled in kernel or no TPM chip found
> > ima_tpm 3 TINFO: AppArmor enabled, this may affect test results
> > ima_tpm 3 TINFO: it can be disabled with TST_DISABLE_APPARMOR=1 (requires super/root)
> > ima_tpm 3 TINFO: loaded AppArmor profiles: none
> 
> > Summary:
> > passed   0
> > failed   1
> > skipped  1
> > warnings 0
> 
> 
> BTW my results on custom kernel:
> ima_tpm 1 TINFO: timeout per run is 0h 5m 0s
> ima_tpm 1 TINFO: IMA kernel config:
> ima_tpm 1 TINFO: CONFIG_IMA=y
> ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10
> ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y
> ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256"
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_BOOTPARAM=y
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_MODSIG=y
> ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y
> ima_tpm 1 TINFO: CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY=y
> ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.3.18-20-default root=/dev/mapper/system-root crashkernel=121M,high crashkernel=72M,low isofrom=/dev/disk/by-uuid/3271-1AD6:/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso isofrom_device=/dev/disk/by-uuid/3271-1AD6 isofrom_system=/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso loader=syslinux quiet resume=/dev/system/swap splash=silent quiet showopts
> ima_tpm 1 TINFO: IMA kernel config:
> ima_tpm 1 TINFO: CONFIG_IMA=y
> ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10
> ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y
> ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256"
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_BOOTPARAM=y
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_MODSIG=y
> ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y
> ima_tpm 1 TINFO: CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY=y
> ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.3.18-20-default root=/dev/mapper/system-root crashkernel=121M,high crashkernel=72M,low isofrom=/dev/disk/by-uuid/3271-1AD6:/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso isofrom_device=/dev/disk/by-uuid/3271-1AD6 isofrom_system=/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso loader=syslinux quiet resume=/dev/system/swap splash=silent quiet showopts
> ima_tpm 1 TINFO: verify boot aggregate
> ima_tpm 1 TINFO: used algorithm: sha1
> ima_tpm 1 TINFO: IMA boot aggregate: '1172f0990296510ed39403b4f1de83c82e093aae'
> ima_tpm 1 TPASS: bios boot aggregate matches IMA boot aggregate (1172f0990296510ed39403b4f1de83c82e093aae)
> ima_tpm 2 TINFO: verify PCR values
> ima_tpm 2 TINFO: evmctl version: evmctl 1.2.1
> ima_tpm 2 TINFO: new PCRS path, evmctl >= 1.1 required
> ima_tpm 2 TINFO: verify PCR (Process Control Register)
> ima_tpm 2 TPASS: aggregate PCR value matches real PCR value
> 
> Summary:
> passed   2
> failed   0
> skipped  0
> warnings 0
> 
> 
> > # head -1 /sys/kernel/security/ima/ascii_runtime_measurements
> 
> > 10 a3132d2501128ff527171658d40d8deb61e2292b ima-ng
> > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5
> > b boot_aggregate
> 
> mine:
> 10 c125a1d3684a9737f20f6c1bc880782fae60fb28 ima-ng sha1:1172f0990296510ed39403b4f1de83c82e093aae boot_aggregate
> 
> > The ima-evm-utils next-testing branch has code to calculate the
> > boot_aggregate based on multiple banks.
> I see, 696bf0b ("ima-evm-utils: calculate the digests for multiple TPM banks")
> I wonder whether it's reasonable trying to port that to ima_boot_aggregate.c or
> just depend on evmctl. External dependencies are sometimes complicated, but for
> IMA I incline to just require evmctl.

Unlike TPM 1.2, the TPM 2.0 device driver doesn't export the TPM PCRs.
?Not only would you have a dependency on ima-evm-utils, but also on a
userspace application(s) for reading the TPM PCRs. ?That dependency
exists whether you're using evmctl to calculate the boot_aggregate or
doing it yourself.

> 
> > # evmctl ima_boot_aggregate
> 
> > sha1:4cf3d105b1a1a41b951cc6431f0801c01fe50b24
> > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5b
> 
> Thus obviously evmctl (from next-testing) also gets only sha1
> ./src/evmctl ima_boot_aggregate
> sha1:1172f0990296510ed39403b4f1de83c82e093aae
> 
> > There's also a new test to verify the boot_aggregate.
> 
> > $ VERBOSE=1 make check TESTS=boog_aggregate.test
> BTW I got some errors
> ...
> make  check-TESTS
> make[2]: Entering directory '/home/foo/ima-evm-utils/tests'
> make[3]: Entering directory '/home/foo/ima-evm-utils/tests'
> make[4]: Entering directory '/home/foo/ima-evm-utils/tests'
> make[4]: Nothing to be done for 'boog_aggregate.log'.
> make[4]: Leaving directory '/home/foo/ima-evm-utils/tests'
> fatal: making test-suite.log: failed to create boog_aggregate.trs
> fatal: making test-suite.log: failed to create boog_aggregate.log
> make[3]: *** [Makefile:516: test-suite.log] Error 1
> make[3]: Leaving directory '/home/foo/ima-evm-utils/tests'
> make[2]: *** [Makefile:625: check-TESTS] Error 2
> make[2]: Leaving directory '/home/foo/ima-evm-utils/tests'
> make[1]: *** [Makefile:692: check-am] Error 2
> make[1]: Leaving directory '/home/foo/ima-evm-utils/tests'
> make: *** [Makefile:514: check-recursive] Error 1

[Cc'ing Vitaly]

The boot_aggregate.trs and boot_aggregate.log files are being created
in the tests/ directory. ?Is that directory read-only?
?
> 
> > Both need some review and testing before being released.
> Any estimation when code is released?

Probably not before the next open window, but definitely before it is
released.

Mimi

  reply	other threads:[~2020-05-28 15:19 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-27  7:14 [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate Petr Vorel
2020-05-27  7:14 ` [LTP] " Petr Vorel
2020-05-27 17:41 ` Mimi Zohar
2020-05-27 17:41   ` [LTP] " Mimi Zohar
2020-05-28 14:07   ` Petr Vorel
2020-05-28 14:07     ` [LTP] " Petr Vorel
2020-05-28 15:19     ` Mimi Zohar [this message]
2020-05-28 15:19       ` Mimi Zohar
2020-05-28 16:05       ` Petr Vorel
2020-05-28 16:05         ` [LTP] " Petr Vorel
2020-06-15 19:41         ` Bruno Meneguele
2020-06-15 19:41           ` [LTP] " Bruno Meneguele
2020-06-15 20:01           ` Bruno Meneguele
2020-06-15 20:01             ` [LTP] " Bruno Meneguele
2020-06-16 22:40             ` Mimi Zohar
2020-06-16 22:40               ` [LTP] " Mimi Zohar
2020-06-17 19:52               ` Bruno Meneguele
2020-06-17 19:52                 ` [LTP] " Bruno Meneguele
2020-06-19  7:46             ` Petr Vorel
2020-06-19  7:46               ` [LTP] " Petr Vorel
2020-06-15 20:21           ` Mimi Zohar
2020-06-15 20:21             ` [LTP] " Mimi Zohar
2020-06-17  1:21             ` Jerry Snitselaar
2020-06-17  1:21               ` [LTP] " Jerry Snitselaar
2020-06-17 20:45               ` Bruno Meneguele
2020-06-17 20:45                 ` [LTP] " Bruno Meneguele
2020-06-17 22:19                 ` Maurizio Drocco
2020-06-17 22:19                   ` [LTP] " Maurizio Drocco
2020-06-19  8:21                 ` Petr Vorel
2020-06-19  8:21                   ` [LTP] " Petr Vorel
2020-06-19 12:43                   ` Mimi Zohar
2020-06-19 12:43                     ` [LTP] " Mimi Zohar
2020-06-19 13:01                     ` Petr Vorel
2020-06-19 13:01                       ` [LTP] " Petr Vorel
2020-06-19 10:07             ` Petr Vorel
2020-06-19 10:07               ` [LTP] " Petr Vorel
2020-06-19 13:01               ` Mimi Zohar
2020-06-19 13:01                 ` [LTP] " Mimi Zohar

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=1590679145.4457.39.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=chrubis@suse.cz \
    --cc=linux-integrity@vger.kernel.org \
    --cc=ltp@lists.linux.it \
    --cc=pcervinka@suse.com \
    --cc=pvorel@suse.cz \
    --cc=vt@altlinux.org \
    --cc=zohar@linux.vnet.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 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.