* [LTP] [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
@ 2020-06-15 19:41 ` Bruno Meneguele
0 siblings, 0 replies; 38+ messages in thread
From: Bruno Meneguele @ 2020-06-15 19:41 UTC (permalink / raw)
To: ltp
On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote:
> Hi Mimi,
> ...
> > > > 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.
> OK, I tested it on TPM 1.2 (no TPM 2.0 available atm).
> I guess you have TPM 2.0, that's why I didn't spot this issue.
>
> To sum that: my patch is required for any system without physical TPM with with
> kernel with b59fda449cf0 + it also works for TPM 1.2 (regardless kernel
> version), because TPM 1.2 supports sha1 only boot aggregate.
>
> But testing on kernel with b59fda449cf0 with TPM 2.0 is not only broken with
> this patch, but also on current version in master, right? As you have
> sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 anyway.
> So this patch would help at least testing on VM without vTPM.
>
If we consider to delay this change until we have the ima-evm-utils
released with the ima_boot_aggregate + make this test dependent on
both ima-evm-utils and tsspcrread, would it be worth to SKIP the test in
case a TPM2.0 sha256 bank is detected instead of FAIL? Thus we could
have the test fixed for TPM1.2 && no-TPM cases until we get the full
support for multiple banks?
> ...
> > > > 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.
> Hm, things get complicated.
> Yep I remember your patch to skip verifying TPM 2.0 PCR values
> https://patchwork.ozlabs.org/project/ltp/patch/1558041162.3971.2.camel@linux.ibm.com/
> At least thanks to Jerry Snitselaar since v5.6 we have
> /sys/class/tpm/tpm*/tpm_version_major. We could check this (+ try also
> /sys/class/tpm/tpm0/device/description for older kernels).
>
> BTW on my system there is also /sys/class/tpm/tpm0/ppi/version, which has 1.2,
> not sure if it indicate TPM 1.2, but I wouldn't rely on that.
>
IIUC 'tpm_version_major' should be the only safe reference of the actual
TCG spec version being implemented by the hw TPM, in a sysfs standard
output.
> ...
> > > > 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?
> Yes, drwxr-xr-x. Testing on fresh clone and issue persists.
>
Yes, same thing here.. but didn't really check the reason for that. Will
take a time later to see what's happening.
> > > > 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.
> Thanks for info.
>
--
bmeneg
PGP Key: http://bmeneg.com/pubkey.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linux.it/pipermail/ltp/attachments/20200615/c866967e/attachment-0001.sig>
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
2020-06-15 19:41 ` [LTP] " Bruno Meneguele
@ 2020-06-15 20:01 ` Bruno Meneguele
-1 siblings, 0 replies; 38+ messages in thread
From: Bruno Meneguele @ 2020-06-15 20:01 UTC (permalink / raw)
To: Petr Vorel
Cc: Mimi Zohar, ltp, Mimi Zohar, Petr Cervinka, Cyril Hrubis,
linux-integrity, Vitaly Chikunov
[-- Attachment #1: Type: text/plain, Size: 5803 bytes --]
On Mon, Jun 15, 2020 at 04:41:34PM -0300, Bruno Meneguele wrote:
> On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote:
> > Hi Mimi,
> > ...
> > > > > 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.
> > OK, I tested it on TPM 1.2 (no TPM 2.0 available atm).
> > I guess you have TPM 2.0, that's why I didn't spot this issue.
> >
> > To sum that: my patch is required for any system without physical TPM with with
> > kernel with b59fda449cf0 + it also works for TPM 1.2 (regardless kernel
> > version), because TPM 1.2 supports sha1 only boot aggregate.
> >
> > But testing on kernel with b59fda449cf0 with TPM 2.0 is not only broken with
> > this patch, but also on current version in master, right? As you have
> > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 anyway.
> > So this patch would help at least testing on VM without vTPM.
> >
>
> If we consider to delay this change until we have the ima-evm-utils
> released with the ima_boot_aggregate + make this test dependent on
> both ima-evm-utils and tsspcrread, would it be worth to SKIP the test in
> case a TPM2.0 sha256 bank is detected instead of FAIL? Thus we could
> have the test fixed for TPM1.2 && no-TPM cases until we get the full
> support for multiple banks?
>
> > ...
> > > > > 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.
> > Hm, things get complicated.
> > Yep I remember your patch to skip verifying TPM 2.0 PCR values
> > https://patchwork.ozlabs.org/project/ltp/patch/1558041162.3971.2.camel@linux.ibm.com/
> > At least thanks to Jerry Snitselaar since v5.6 we have
> > /sys/class/tpm/tpm*/tpm_version_major. We could check this (+ try also
> > /sys/class/tpm/tpm0/device/description for older kernels).
> >
> > BTW on my system there is also /sys/class/tpm/tpm0/ppi/version, which has 1.2,
> > not sure if it indicate TPM 1.2, but I wouldn't rely on that.
> >
>
> IIUC 'tpm_version_major' should be the only safe reference of the actual
> TCG spec version being implemented by the hw TPM, in a sysfs standard
> output.
>
> > ...
> > > > > There's also a new test to verify the boot_aggregate.
> >
> > > > > $ VERBOSE=1 make check TESTS=boog_aggregate.test
^^^^
boot
That's the issue :).
> > > > 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?
> > Yes, drwxr-xr-x. Testing on fresh clone and issue persists.
> >
>
> Yes, same thing here.. but didn't really check the reason for that. Will
> take a time later to see what's happening.
>
> > > > > 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.
> > Thanks for info.
> >
>
> --
> bmeneg
> PGP Key: http://bmeneg.com/pubkey.txt
--
bmeneg
PGP Key: http://bmeneg.com/pubkey.txt
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread* [LTP] [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
@ 2020-06-15 20:01 ` Bruno Meneguele
0 siblings, 0 replies; 38+ messages in thread
From: Bruno Meneguele @ 2020-06-15 20:01 UTC (permalink / raw)
To: ltp
On Mon, Jun 15, 2020 at 04:41:34PM -0300, Bruno Meneguele wrote:
> On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote:
> > Hi Mimi,
> > ...
> > > > > 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.
> > OK, I tested it on TPM 1.2 (no TPM 2.0 available atm).
> > I guess you have TPM 2.0, that's why I didn't spot this issue.
> >
> > To sum that: my patch is required for any system without physical TPM with with
> > kernel with b59fda449cf0 + it also works for TPM 1.2 (regardless kernel
> > version), because TPM 1.2 supports sha1 only boot aggregate.
> >
> > But testing on kernel with b59fda449cf0 with TPM 2.0 is not only broken with
> > this patch, but also on current version in master, right? As you have
> > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 anyway.
> > So this patch would help at least testing on VM without vTPM.
> >
>
> If we consider to delay this change until we have the ima-evm-utils
> released with the ima_boot_aggregate + make this test dependent on
> both ima-evm-utils and tsspcrread, would it be worth to SKIP the test in
> case a TPM2.0 sha256 bank is detected instead of FAIL? Thus we could
> have the test fixed for TPM1.2 && no-TPM cases until we get the full
> support for multiple banks?
>
> > ...
> > > > > 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.
> > Hm, things get complicated.
> > Yep I remember your patch to skip verifying TPM 2.0 PCR values
> > https://patchwork.ozlabs.org/project/ltp/patch/1558041162.3971.2.camel@linux.ibm.com/
> > At least thanks to Jerry Snitselaar since v5.6 we have
> > /sys/class/tpm/tpm*/tpm_version_major. We could check this (+ try also
> > /sys/class/tpm/tpm0/device/description for older kernels).
> >
> > BTW on my system there is also /sys/class/tpm/tpm0/ppi/version, which has 1.2,
> > not sure if it indicate TPM 1.2, but I wouldn't rely on that.
> >
>
> IIUC 'tpm_version_major' should be the only safe reference of the actual
> TCG spec version being implemented by the hw TPM, in a sysfs standard
> output.
>
> > ...
> > > > > There's also a new test to verify the boot_aggregate.
> >
> > > > > $ VERBOSE=1 make check TESTS=boog_aggregate.test
^^^^
boot
That's the issue :).
> > > > 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?
> > Yes, drwxr-xr-x. Testing on fresh clone and issue persists.
> >
>
> Yes, same thing here.. but didn't really check the reason for that. Will
> take a time later to see what's happening.
>
> > > > > 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.
> > Thanks for info.
> >
>
> --
> bmeneg
> PGP Key: http://bmeneg.com/pubkey.txt
--
bmeneg
PGP Key: http://bmeneg.com/pubkey.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linux.it/pipermail/ltp/attachments/20200615/758b0375/attachment-0001.sig>
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
2020-06-15 20:01 ` [LTP] " Bruno Meneguele
@ 2020-06-16 22:40 ` Mimi Zohar
-1 siblings, 0 replies; 38+ messages in thread
From: Mimi Zohar @ 2020-06-16 22:40 UTC (permalink / raw)
To: Bruno Meneguele, Petr Vorel
Cc: ltp, Mimi Zohar, Petr Cervinka, Cyril Hrubis, linux-integrity,
Vitaly Chikunov
On Mon, 2020-06-15 at 17:01 -0300, Bruno Meneguele wrote:
> On Mon, Jun 15, 2020 at 04:41:34PM -0300, Bruno Meneguele wrote:
> > On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote:
> > > > The boot_aggregate.trs and boot_aggregate.log files are being created
> > > > in the tests/ directory. Is that directory read-only?
> > > Yes, drwxr-xr-x. Testing on fresh clone and issue persists.
> > >
> >
> > Yes, same thing here.. but didn't really check the reason for that. Will
> > take a time later to see what's happening.
Cloning as root will cause that to happen.
$ sudo git clone git://git.code.sf.net/p/linux-ima/ima-evm-utils --branch next-testing
Cloning into 'ima-evm-utils'...
remote: Enumerating objects: 1154, done.
remote: Counting objects: 100% (1154/1154), done.
remote: Compressing objects: 100% (1052/1052), done.
remote: Total 1154 (delta 736), reused 182 (delta 96)
Receiving objects: 100% (1154/1154), 335.12 KiB | 0 bytes/s, done.
Resolving deltas: 100% (736/736), done.
Checking connectivity... done.
$ ls -lat ima-evm-utils/ | grep tests
drwxr-xr-x. 2 root root 220 Jun 16 18:28 tests
Mimi
^ permalink raw reply [flat|nested] 38+ messages in thread
* [LTP] [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
@ 2020-06-16 22:40 ` Mimi Zohar
0 siblings, 0 replies; 38+ messages in thread
From: Mimi Zohar @ 2020-06-16 22:40 UTC (permalink / raw)
To: ltp
On Mon, 2020-06-15 at 17:01 -0300, Bruno Meneguele wrote:
> On Mon, Jun 15, 2020 at 04:41:34PM -0300, Bruno Meneguele wrote:
> > On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote:
> > > > The boot_aggregate.trs and boot_aggregate.log files are being created
> > > > in the tests/ directory. ?Is that directory read-only?
> > > Yes, drwxr-xr-x. Testing on fresh clone and issue persists.
> > >
> >
> > Yes, same thing here.. but didn't really check the reason for that. Will
> > take a time later to see what's happening.
Cloning as root will cause that to happen.
$ sudo git clone git://git.code.sf.net/p/linux-ima/ima-evm-utils --branch next-testing
Cloning into 'ima-evm-utils'...
remote: Enumerating objects: 1154, done.
remote: Counting objects: 100% (1154/1154), done.
remote: Compressing objects: 100% (1052/1052), done.
remote: Total 1154 (delta 736), reused 182 (delta 96)
Receiving objects: 100% (1154/1154), 335.12 KiB | 0 bytes/s, done.
Resolving deltas: 100% (736/736), done.
Checking connectivity... done.
$ ls -lat ima-evm-utils/ | grep tests
drwxr-xr-x. 2 root root 220 Jun 16 18:28 tests
Mimi
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
2020-06-16 22:40 ` [LTP] " Mimi Zohar
@ 2020-06-17 19:52 ` Bruno Meneguele
-1 siblings, 0 replies; 38+ messages in thread
From: Bruno Meneguele @ 2020-06-17 19:52 UTC (permalink / raw)
To: Mimi Zohar
Cc: Petr Vorel, ltp, Mimi Zohar, Petr Cervinka, Cyril Hrubis,
linux-integrity, Vitaly Chikunov
[-- Attachment #1: Type: text/plain, Size: 1607 bytes --]
On Tue, Jun 16, 2020 at 06:40:11PM -0400, Mimi Zohar wrote:
> On Mon, 2020-06-15 at 17:01 -0300, Bruno Meneguele wrote:
> > On Mon, Jun 15, 2020 at 04:41:34PM -0300, Bruno Meneguele wrote:
> > > On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote:
>
> > > > > The boot_aggregate.trs and boot_aggregate.log files are being created
> > > > > in the tests/ directory. Is that directory read-only?
> > > > Yes, drwxr-xr-x. Testing on fresh clone and issue persists.
> > > >
> > >
> > > Yes, same thing here.. but didn't really check the reason for that. Will
> > > take a time later to see what's happening.
>
> Cloning as root will cause that to happen.
>
> $ sudo git clone git://git.code.sf.net/p/linux-ima/ima-evm-utils --branch next-testing
> Cloning into 'ima-evm-utils'...
> remote: Enumerating objects: 1154, done.
> remote: Counting objects: 100% (1154/1154), done.
> remote: Compressing objects: 100% (1052/1052), done.
> remote: Total 1154 (delta 736), reused 182 (delta 96)
> Receiving objects: 100% (1154/1154), 335.12 KiB | 0 bytes/s, done.
> Resolving deltas: 100% (736/736), done.
> Checking connectivity... done.
>
> $ ls -lat ima-evm-utils/ | grep tests
> drwxr-xr-x. 2 root root 220 Jun 16 18:28 tests
>
> Mimi
>
Yes, indeed. But what really happened with both I and Petr was trying to
run the test copying and pasting what you've sent:
$ VERBOSE=1 make check TESTS=boog_aggregate.test
the typo in "boog" (vs "boot") was the cause. So I think we can ignore
this issue here :).
--
bmeneg
PGP Key: http://bmeneg.com/pubkey.txt
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread
* [LTP] [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
@ 2020-06-17 19:52 ` Bruno Meneguele
0 siblings, 0 replies; 38+ messages in thread
From: Bruno Meneguele @ 2020-06-17 19:52 UTC (permalink / raw)
To: ltp
On Tue, Jun 16, 2020 at 06:40:11PM -0400, Mimi Zohar wrote:
> On Mon, 2020-06-15 at 17:01 -0300, Bruno Meneguele wrote:
> > On Mon, Jun 15, 2020 at 04:41:34PM -0300, Bruno Meneguele wrote:
> > > On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote:
>
> > > > > The boot_aggregate.trs and boot_aggregate.log files are being created
> > > > > in the tests/ directory. ?Is that directory read-only?
> > > > Yes, drwxr-xr-x. Testing on fresh clone and issue persists.
> > > >
> > >
> > > Yes, same thing here.. but didn't really check the reason for that. Will
> > > take a time later to see what's happening.
>
> Cloning as root will cause that to happen.
>
> $ sudo git clone git://git.code.sf.net/p/linux-ima/ima-evm-utils --branch next-testing
> Cloning into 'ima-evm-utils'...
> remote: Enumerating objects: 1154, done.
> remote: Counting objects: 100% (1154/1154), done.
> remote: Compressing objects: 100% (1052/1052), done.
> remote: Total 1154 (delta 736), reused 182 (delta 96)
> Receiving objects: 100% (1154/1154), 335.12 KiB | 0 bytes/s, done.
> Resolving deltas: 100% (736/736), done.
> Checking connectivity... done.
>
> $ ls -lat ima-evm-utils/ | grep tests
> drwxr-xr-x. 2 root root 220 Jun 16 18:28 tests
>
> Mimi
>
Yes, indeed. But what really happened with both I and Petr was trying to
run the test copying and pasting what you've sent:
$ VERBOSE=1 make check TESTS=boog_aggregate.test
the typo in "boog" (vs "boot") was the cause. So I think we can ignore
this issue here :).
--
bmeneg
PGP Key: http://bmeneg.com/pubkey.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linux.it/pipermail/ltp/attachments/20200617/7aa5aa78/attachment.sig>
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
2020-06-15 20:01 ` [LTP] " Bruno Meneguele
@ 2020-06-19 7:46 ` Petr Vorel
-1 siblings, 0 replies; 38+ messages in thread
From: Petr Vorel @ 2020-06-19 7:46 UTC (permalink / raw)
To: Bruno Meneguele
Cc: Mimi Zohar, ltp, Mimi Zohar, Petr Cervinka, Cyril Hrubis,
linux-integrity, Vitaly Chikunov
Hi Bruno,
> > > > > > $ VERBOSE=1 make check TESTS=boog_aggregate.test
> ^^^^
> boot
> That's the issue :).
Thanks! Obviously everything is working with correct test name :).
Kind regards,
Petr
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
2020-06-15 19:41 ` [LTP] " Bruno Meneguele
@ 2020-06-15 20:21 ` Mimi Zohar
-1 siblings, 0 replies; 38+ messages in thread
From: Mimi Zohar @ 2020-06-15 20:21 UTC (permalink / raw)
To: Bruno Meneguele, Petr Vorel
Cc: ltp, Mimi Zohar, Petr Cervinka, Cyril Hrubis, linux-integrity,
Vitaly Chikunov, Maurizio Drocco
On Mon, 2020-06-15 at 16:41 -0300, Bruno Meneguele wrote:
> On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote:
> > Hi Mimi,
> > ...
> > > > > 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.
> > OK, I tested it on TPM 1.2 (no TPM 2.0 available atm).
> > I guess you have TPM 2.0, that's why I didn't spot this issue.
> >
> > To sum that: my patch is required for any system without physical TPM with with
> > kernel with b59fda449cf0 + it also works for TPM 1.2 (regardless kernel
> > version), because TPM 1.2 supports sha1 only boot aggregate.
> >
> > But testing on kernel with b59fda449cf0 with TPM 2.0 is not only broken with
> > this patch, but also on current version in master, right? As you have
> > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 anyway.
> > So this patch would help at least testing on VM without vTPM.
> >
>
> If we consider to delay this change until we have the ima-evm-utils
> released with the ima_boot_aggregate + make this test dependent on
> both ima-evm-utils and tsspcrread, would it be worth to SKIP the test in
> case a TPM2.0 sha256 bank is detected instead of FAIL? Thus we could
> have the test fixed for TPM1.2 && no-TPM cases until we get the full
> support for multiple banks?
As long as we're dealing with the "boot_aggregate", Maurizio just
posted a kernel patch for including PCR 8 & 9 in the boot_aggregate.
The existing IMA LTP "boot_aggregate" test is going to need to
support this change.
I'd appreciate if someone could send me a TPM event log, the PCRs, and
the associated IMA ascii_runtime_measurements "boot_aggregate" from a
system with a discrete TPM 2.0 with PCRs 8 & 9 events.
>
> > ...
> > > > > 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.
> > Hm, things get complicated.
> > Yep I remember your patch to skip verifying TPM 2.0 PCR values
> > https://patchwork.ozlabs.org/project/ltp/patch/1558041162.3971.2.camel@linux.ibm.com/
> > At least thanks to Jerry Snitselaar since v5.6 we have
> > /sys/class/tpm/tpm*/tpm_version_major. We could check this (+ try also
> > /sys/class/tpm/tpm0/device/description for older kernels).
> >
> > BTW on my system there is also /sys/class/tpm/tpm0/ppi/version, which has 1.2,
> > not sure if it indicate TPM 1.2, but I wouldn't rely on that.
> >
>
> IIUC 'tpm_version_major' should be the only safe reference of the actual
> TCG spec version being implemented by the hw TPM, in a sysfs standard
> output.
That was only upstreamed in linux-v5.6. Has it been backported?
The PCRs are not exported for TPM 2.0, unfortunately, making
regression tests dependent on a userspace app. The existing LTP
ima_tpm.sh test looks for the PCRs in either
/sys/class/tpm/tpm0/device/pcrs or /sys/class/misc/tpm0/device/pcrs.
Perhaps piggyback on the pseudo PCR file to test for TPM 1.2.
>
> > ...
> > > > > 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?
> > Yes, drwxr-xr-x. Testing on fresh clone and issue persists.
> >
>
> Yes, same thing here.. but didn't really check the reason for that. Will
> take a time later to see what's happening.
Thanks, much appreciated. I'm not seeing that here.
Mimi
^ permalink raw reply [flat|nested] 38+ messages in thread* [LTP] [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
@ 2020-06-15 20:21 ` Mimi Zohar
0 siblings, 0 replies; 38+ messages in thread
From: Mimi Zohar @ 2020-06-15 20:21 UTC (permalink / raw)
To: ltp
On Mon, 2020-06-15 at 16:41 -0300, Bruno Meneguele wrote:
> On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote:
> > Hi Mimi,
> > ...
> > > > > 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.
> > OK, I tested it on TPM 1.2 (no TPM 2.0 available atm).
> > I guess you have TPM 2.0, that's why I didn't spot this issue.
> >
> > To sum that: my patch is required for any system without physical TPM with with
> > kernel with b59fda449cf0 + it also works for TPM 1.2 (regardless kernel
> > version), because TPM 1.2 supports sha1 only boot aggregate.
> >
> > But testing on kernel with b59fda449cf0 with TPM 2.0 is not only broken with
> > this patch, but also on current version in master, right? As you have
> > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 anyway.
> > So this patch would help at least testing on VM without vTPM.
> >
>
> If we consider to delay this change until we have the ima-evm-utils
> released with the ima_boot_aggregate + make this test dependent on
> both ima-evm-utils and tsspcrread, would it be worth to SKIP the test in
> case a TPM2.0 sha256 bank is detected instead of FAIL? Thus we could
> have the test fixed for TPM1.2 && no-TPM cases until we get the full
> support for multiple banks?
As long as we're dealing with the "boot_aggregate", Maurizio just
posted a kernel patch for including PCR 8 & 9 in the boot_aggregate.
?The existing IMA LTP "boot_aggregate" test is going to need to
support this change.
I'd appreciate if someone could send me a TPM event log, the PCRs, and
the associated IMA ascii_runtime_measurements "boot_aggregate" from a
system with a discrete TPM 2.0 with PCRs 8 & 9 events.
>
> > ...
> > > > > 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.
> > Hm, things get complicated.
> > Yep I remember your patch to skip verifying TPM 2.0 PCR values
> > https://patchwork.ozlabs.org/project/ltp/patch/1558041162.3971.2.camel@linux.ibm.com/
> > At least thanks to Jerry Snitselaar since v5.6 we have
> > /sys/class/tpm/tpm*/tpm_version_major. We could check this (+ try also
> > /sys/class/tpm/tpm0/device/description for older kernels).
> >
> > BTW on my system there is also /sys/class/tpm/tpm0/ppi/version, which has 1.2,
> > not sure if it indicate TPM 1.2, but I wouldn't rely on that.
> >
>
> IIUC 'tpm_version_major' should be the only safe reference of the actual
> TCG spec version being implemented by the hw TPM, in a sysfs standard
> output.
That was only upstreamed in linux-v5.6. ?Has it been backported?
The PCRs are not exported for TPM 2.0, unfortunately, making
regression tests dependent on a userspace app. ?The existing LTP
ima_tpm.sh test looks for the PCRs in either
/sys/class/tpm/tpm0/device/pcrs or /sys/class/misc/tpm0/device/pcrs.
?Perhaps piggyback on the pseudo PCR file to test for TPM 1.2.
>
> > ...
> > > > > 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?
> > Yes, drwxr-xr-x. Testing on fresh clone and issue persists.
> >
>
> Yes, same thing here.. but didn't really check the reason for that. Will
> take a time later to see what's happening.
Thanks, much appreciated. ?I'm not seeing that here.
Mimi
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
2020-06-15 20:21 ` [LTP] " Mimi Zohar
@ 2020-06-17 1:21 ` Jerry Snitselaar
-1 siblings, 0 replies; 38+ messages in thread
From: Jerry Snitselaar @ 2020-06-17 1:21 UTC (permalink / raw)
To: Mimi Zohar
Cc: Bruno Meneguele, Petr Vorel, ltp, Mimi Zohar, Petr Cervinka,
Cyril Hrubis, linux-integrity, Vitaly Chikunov, Maurizio Drocco
On Mon Jun 15 20, Mimi Zohar wrote:
>On Mon, 2020-06-15 at 16:41 -0300, Bruno Meneguele wrote:
>> On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote:
>> > Hi Mimi,
>> > ...
>> > > > > 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.
>> > OK, I tested it on TPM 1.2 (no TPM 2.0 available atm).
>> > I guess you have TPM 2.0, that's why I didn't spot this issue.
>> >
>> > To sum that: my patch is required for any system without physical TPM with with
>> > kernel with b59fda449cf0 + it also works for TPM 1.2 (regardless kernel
>> > version), because TPM 1.2 supports sha1 only boot aggregate.
>> >
>> > But testing on kernel with b59fda449cf0 with TPM 2.0 is not only broken with
>> > this patch, but also on current version in master, right? As you have
>> > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 anyway.
>> > So this patch would help at least testing on VM without vTPM.
>> >
>>
>> If we consider to delay this change until we have the ima-evm-utils
>> released with the ima_boot_aggregate + make this test dependent on
>> both ima-evm-utils and tsspcrread, would it be worth to SKIP the test in
>> case a TPM2.0 sha256 bank is detected instead of FAIL? Thus we could
>> have the test fixed for TPM1.2 && no-TPM cases until we get the full
>> support for multiple banks?
>
>As long as we're dealing with the "boot_aggregate", Maurizio just
>posted a kernel patch for including PCR 8 & 9 in the boot_aggregate.
> The existing IMA LTP "boot_aggregate" test is going to need to
>support this change.
>
>I'd appreciate if someone could send me a TPM event log, the PCRs, and
>the associated IMA ascii_runtime_measurements "boot_aggregate" from a
>system with a discrete TPM 2.0 with PCRs 8 & 9 events.
>
>>
>> > ...
>> > > > > 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.
>> > Hm, things get complicated.
>> > Yep I remember your patch to skip verifying TPM 2.0 PCR values
>> > https://patchwork.ozlabs.org/project/ltp/patch/1558041162.3971.2.camel@linux.ibm.com/
>> > At least thanks to Jerry Snitselaar since v5.6 we have
>> > /sys/class/tpm/tpm*/tpm_version_major. We could check this (+ try also
>> > /sys/class/tpm/tpm0/device/description for older kernels).
>> >
>> > BTW on my system there is also /sys/class/tpm/tpm0/ppi/version, which has 1.2,
>> > not sure if it indicate TPM 1.2, but I wouldn't rely on that.
>> >
>>
>> IIUC 'tpm_version_major' should be the only safe reference of the actual
>> TCG spec version being implemented by the hw TPM, in a sysfs standard
>> output.
>
>That was only upstreamed in linux-v5.6. Has it been backported?
>
Not that I know of. Since it isn't using chip->ops and only
looks at chip->flags it could probably be backported, but I'd
have to take a look at it.
>The PCRs are not exported for TPM 2.0, unfortunately, making
>regression tests dependent on a userspace app. The existing LTP
>ima_tpm.sh test looks for the PCRs in either
>/sys/class/tpm/tpm0/device/pcrs or /sys/class/misc/tpm0/device/pcrs.
> Perhaps piggyback on the pseudo PCR file to test for TPM 1.2.
>
>>
>> > ...
>> > > > > 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?
>> > Yes, drwxr-xr-x. Testing on fresh clone and issue persists.
>> >
>>
>> Yes, same thing here.. but didn't really check the reason for that. Will
>> take a time later to see what's happening.
>
>Thanks, much appreciated. I'm not seeing that here.
>
>Mimi
>
^ permalink raw reply [flat|nested] 38+ messages in thread* [LTP] [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
@ 2020-06-17 1:21 ` Jerry Snitselaar
0 siblings, 0 replies; 38+ messages in thread
From: Jerry Snitselaar @ 2020-06-17 1:21 UTC (permalink / raw)
To: ltp
On Mon Jun 15 20, Mimi Zohar wrote:
>On Mon, 2020-06-15 at 16:41 -0300, Bruno Meneguele wrote:
>> On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote:
>> > Hi Mimi,
>> > ...
>> > > > > 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.
>> > OK, I tested it on TPM 1.2 (no TPM 2.0 available atm).
>> > I guess you have TPM 2.0, that's why I didn't spot this issue.
>> >
>> > To sum that: my patch is required for any system without physical TPM with with
>> > kernel with b59fda449cf0 + it also works for TPM 1.2 (regardless kernel
>> > version), because TPM 1.2 supports sha1 only boot aggregate.
>> >
>> > But testing on kernel with b59fda449cf0 with TPM 2.0 is not only broken with
>> > this patch, but also on current version in master, right? As you have
>> > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 anyway.
>> > So this patch would help at least testing on VM without vTPM.
>> >
>>
>> If we consider to delay this change until we have the ima-evm-utils
>> released with the ima_boot_aggregate + make this test dependent on
>> both ima-evm-utils and tsspcrread, would it be worth to SKIP the test in
>> case a TPM2.0 sha256 bank is detected instead of FAIL? Thus we could
>> have the test fixed for TPM1.2 && no-TPM cases until we get the full
>> support for multiple banks?
>
>As long as we're dealing with the "boot_aggregate", Maurizio just
>posted a kernel patch for including PCR 8 & 9 in the boot_aggregate.
>?The existing IMA LTP "boot_aggregate" test is going to need to
>support this change.
>
>I'd appreciate if someone could send me a TPM event log, the PCRs, and
>the associated IMA ascii_runtime_measurements "boot_aggregate" from a
>system with a discrete TPM 2.0 with PCRs 8 & 9 events.
>
>>
>> > ...
>> > > > > 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.
>> > Hm, things get complicated.
>> > Yep I remember your patch to skip verifying TPM 2.0 PCR values
>> > https://patchwork.ozlabs.org/project/ltp/patch/1558041162.3971.2.camel@linux.ibm.com/
>> > At least thanks to Jerry Snitselaar since v5.6 we have
>> > /sys/class/tpm/tpm*/tpm_version_major. We could check this (+ try also
>> > /sys/class/tpm/tpm0/device/description for older kernels).
>> >
>> > BTW on my system there is also /sys/class/tpm/tpm0/ppi/version, which has 1.2,
>> > not sure if it indicate TPM 1.2, but I wouldn't rely on that.
>> >
>>
>> IIUC 'tpm_version_major' should be the only safe reference of the actual
>> TCG spec version being implemented by the hw TPM, in a sysfs standard
>> output.
>
>That was only upstreamed in linux-v5.6. ?Has it been backported?
>
Not that I know of. Since it isn't using chip->ops and only
looks at chip->flags it could probably be backported, but I'd
have to take a look at it.
>The PCRs are not exported for TPM 2.0, unfortunately, making
>regression tests dependent on a userspace app. ?The existing LTP
>ima_tpm.sh test looks for the PCRs in either
>/sys/class/tpm/tpm0/device/pcrs or /sys/class/misc/tpm0/device/pcrs.
>?Perhaps piggyback on the pseudo PCR file to test for TPM 1.2.
>
>>
>> > ...
>> > > > > 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?
>> > Yes, drwxr-xr-x. Testing on fresh clone and issue persists.
>> >
>>
>> Yes, same thing here.. but didn't really check the reason for that. Will
>> take a time later to see what's happening.
>
>Thanks, much appreciated. ?I'm not seeing that here.
>
>Mimi
>
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
2020-06-17 1:21 ` [LTP] " Jerry Snitselaar
@ 2020-06-17 20:45 ` Bruno Meneguele
-1 siblings, 0 replies; 38+ messages in thread
From: Bruno Meneguele @ 2020-06-17 20:45 UTC (permalink / raw)
To: Jerry Snitselaar
Cc: Mimi Zohar, Petr Vorel, ltp, Mimi Zohar, Petr Cervinka,
Cyril Hrubis, linux-integrity, Vitaly Chikunov, Maurizio Drocco
[-- Attachment #1: Type: text/plain, Size: 7459 bytes --]
On Tue, Jun 16, 2020 at 06:21:48PM -0700, Jerry Snitselaar wrote:
> On Mon Jun 15 20, Mimi Zohar wrote:
> > On Mon, 2020-06-15 at 16:41 -0300, Bruno Meneguele wrote:
> > > On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote:
> > > > Hi Mimi,
> > > > ...
> > > > > > > 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.
> > > > OK, I tested it on TPM 1.2 (no TPM 2.0 available atm).
> > > > I guess you have TPM 2.0, that's why I didn't spot this issue.
> > > >
> > > > To sum that: my patch is required for any system without physical TPM with with
> > > > kernel with b59fda449cf0 + it also works for TPM 1.2 (regardless kernel
> > > > version), because TPM 1.2 supports sha1 only boot aggregate.
> > > >
> > > > But testing on kernel with b59fda449cf0 with TPM 2.0 is not only broken with
> > > > this patch, but also on current version in master, right? As you have
> > > > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 anyway.
> > > > So this patch would help at least testing on VM without vTPM.
> > > >
> > >
> > > If we consider to delay this change until we have the ima-evm-utils
> > > released with the ima_boot_aggregate + make this test dependent on
> > > both ima-evm-utils and tsspcrread, would it be worth to SKIP the test in
> > > case a TPM2.0 sha256 bank is detected instead of FAIL? Thus we could
> > > have the test fixed for TPM1.2 && no-TPM cases until we get the full
> > > support for multiple banks?
> >
> > As long as we're dealing with the "boot_aggregate", Maurizio just
> > posted a kernel patch for including PCR 8 & 9 in the boot_aggregate.
> > The existing IMA LTP "boot_aggregate" test is going to need to
> > support this change.
> >
> > I'd appreciate if someone could send me a TPM event log, the PCRs, and
> > the associated IMA ascii_runtime_measurements "boot_aggregate" from a
> > system with a discrete TPM 2.0 with PCRs 8 & 9 events.
> >
Maybe Maurizio already have it at hand?
I can try to setup a system with grub2+tpm to get the log with pcr 8 and
9 filled.
> > >
> > > > ...
> > > > > > > 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.
> > > > Hm, things get complicated.
> > > > Yep I remember your patch to skip verifying TPM 2.0 PCR values
> > > > https://patchwork.ozlabs.org/project/ltp/patch/1558041162.3971.2.camel@linux.ibm.com/
> > > > At least thanks to Jerry Snitselaar since v5.6 we have
> > > > /sys/class/tpm/tpm*/tpm_version_major. We could check this (+ try also
> > > > /sys/class/tpm/tpm0/device/description for older kernels).
> > > >
> > > > BTW on my system there is also /sys/class/tpm/tpm0/ppi/version, which has 1.2,
> > > > not sure if it indicate TPM 1.2, but I wouldn't rely on that.
> > > >
Missed this last paragraph.. but /sys/class/tpm/tpm0/ppi/version has
relation to the Physical Presence Interface version, which is the
communication interface between firmware and OS afaik, and doesn't
points to the TPM version: TPM2.0 may have PPI version 1.2 or 1.3.
> > >
> > > IIUC 'tpm_version_major' should be the only safe reference of the actual
> > > TCG spec version being implemented by the hw TPM, in a sysfs standard
> > > output.
> >
> > That was only upstreamed in linux-v5.6. Has it been backported?
> >
Hmm, well pointed.
>
> Not that I know of. Since it isn't using chip->ops and only
> looks at chip->flags it could probably be backported, but I'd
> have to take a look at it.
>
> > The PCRs are not exported for TPM 2.0, unfortunately, making
> > regression tests dependent on a userspace app. The existing LTP
> > ima_tpm.sh test looks for the PCRs in either
> > /sys/class/tpm/tpm0/device/pcrs or /sys/class/misc/tpm0/device/pcrs.
> > Perhaps piggyback on the pseudo PCR file to test for TPM 1.2.
> >
> > >
> > > > ...
> > > > > > > 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?
> > > > Yes, drwxr-xr-x. Testing on fresh clone and issue persists.
> > > >
> > >
> > > Yes, same thing here.. but didn't really check the reason for that. Will
> > > take a time later to see what's happening.
> >
> > Thanks, much appreciated. I'm not seeing that here.
> >
> > Mimi
> >
>
--
bmeneg
PGP Key: http://bmeneg.com/pubkey.txt
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 38+ messages in thread* [LTP] [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
@ 2020-06-17 20:45 ` Bruno Meneguele
0 siblings, 0 replies; 38+ messages in thread
From: Bruno Meneguele @ 2020-06-17 20:45 UTC (permalink / raw)
To: ltp
On Tue, Jun 16, 2020 at 06:21:48PM -0700, Jerry Snitselaar wrote:
> On Mon Jun 15 20, Mimi Zohar wrote:
> > On Mon, 2020-06-15 at 16:41 -0300, Bruno Meneguele wrote:
> > > On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote:
> > > > Hi Mimi,
> > > > ...
> > > > > > > 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.
> > > > OK, I tested it on TPM 1.2 (no TPM 2.0 available atm).
> > > > I guess you have TPM 2.0, that's why I didn't spot this issue.
> > > >
> > > > To sum that: my patch is required for any system without physical TPM with with
> > > > kernel with b59fda449cf0 + it also works for TPM 1.2 (regardless kernel
> > > > version), because TPM 1.2 supports sha1 only boot aggregate.
> > > >
> > > > But testing on kernel with b59fda449cf0 with TPM 2.0 is not only broken with
> > > > this patch, but also on current version in master, right? As you have
> > > > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 anyway.
> > > > So this patch would help at least testing on VM without vTPM.
> > > >
> > >
> > > If we consider to delay this change until we have the ima-evm-utils
> > > released with the ima_boot_aggregate + make this test dependent on
> > > both ima-evm-utils and tsspcrread, would it be worth to SKIP the test in
> > > case a TPM2.0 sha256 bank is detected instead of FAIL? Thus we could
> > > have the test fixed for TPM1.2 && no-TPM cases until we get the full
> > > support for multiple banks?
> >
> > As long as we're dealing with the "boot_aggregate", Maurizio just
> > posted a kernel patch for including PCR 8 & 9 in the boot_aggregate.
> > ?The existing IMA LTP "boot_aggregate" test is going to need to
> > support this change.
> >
> > I'd appreciate if someone could send me a TPM event log, the PCRs, and
> > the associated IMA ascii_runtime_measurements "boot_aggregate" from a
> > system with a discrete TPM 2.0 with PCRs 8 & 9 events.
> >
Maybe Maurizio already have it at hand?
I can try to setup a system with grub2+tpm to get the log with pcr 8 and
9 filled.
> > >
> > > > ...
> > > > > > > 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.
> > > > Hm, things get complicated.
> > > > Yep I remember your patch to skip verifying TPM 2.0 PCR values
> > > > https://patchwork.ozlabs.org/project/ltp/patch/1558041162.3971.2.camel@linux.ibm.com/
> > > > At least thanks to Jerry Snitselaar since v5.6 we have
> > > > /sys/class/tpm/tpm*/tpm_version_major. We could check this (+ try also
> > > > /sys/class/tpm/tpm0/device/description for older kernels).
> > > >
> > > > BTW on my system there is also /sys/class/tpm/tpm0/ppi/version, which has 1.2,
> > > > not sure if it indicate TPM 1.2, but I wouldn't rely on that.
> > > >
Missed this last paragraph.. but /sys/class/tpm/tpm0/ppi/version has
relation to the Physical Presence Interface version, which is the
communication interface between firmware and OS afaik, and doesn't
points to the TPM version: TPM2.0 may have PPI version 1.2 or 1.3.
> > >
> > > IIUC 'tpm_version_major' should be the only safe reference of the actual
> > > TCG spec version being implemented by the hw TPM, in a sysfs standard
> > > output.
> >
> > That was only upstreamed in linux-v5.6. ?Has it been backported?
> >
Hmm, well pointed.
>
> Not that I know of. Since it isn't using chip->ops and only
> looks at chip->flags it could probably be backported, but I'd
> have to take a look at it.
>
> > The PCRs are not exported for TPM 2.0, unfortunately, making
> > regression tests dependent on a userspace app. ?The existing LTP
> > ima_tpm.sh test looks for the PCRs in either
> > /sys/class/tpm/tpm0/device/pcrs or /sys/class/misc/tpm0/device/pcrs.
> > ?Perhaps piggyback on the pseudo PCR file to test for TPM 1.2.
> >
> > >
> > > > ...
> > > > > > > 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?
> > > > Yes, drwxr-xr-x. Testing on fresh clone and issue persists.
> > > >
> > >
> > > Yes, same thing here.. but didn't really check the reason for that. Will
> > > take a time later to see what's happening.
> >
> > Thanks, much appreciated. ?I'm not seeing that here.
> >
> > Mimi
> >
>
--
bmeneg
PGP Key: http://bmeneg.com/pubkey.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linux.it/pipermail/ltp/attachments/20200617/4dfc485e/attachment-0001.sig>
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
2020-06-17 20:45 ` [LTP] " Bruno Meneguele
@ 2020-06-17 22:19 ` Maurizio Drocco
-1 siblings, 0 replies; 38+ messages in thread
From: Maurizio Drocco @ 2020-06-17 22:19 UTC (permalink / raw)
To: Bruno Meneguele, Jerry Snitselaar
Cc: Mimi Zohar, Petr Vorel, ltp, Mimi Zohar, Petr Cervinka,
Cyril Hrubis, linux-integrity, Vitaly Chikunov, Maurizio Drocco
On 6/17/2020 4:45 PM, Bruno Meneguele wrote:
> On Tue, Jun 16, 2020 at 06:21:48PM -0700, Jerry Snitselaar wrote:
>> On Mon Jun 15 20, Mimi Zohar wrote:
>>> On Mon, 2020-06-15 at 16:41 -0300, Bruno Meneguele wrote:
>>>> On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote:
>>>>> Hi Mimi,
>>>>> ...
>>>>>>>> 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.
>>>>> OK, I tested it on TPM 1.2 (no TPM 2.0 available atm).
>>>>> I guess you have TPM 2.0, that's why I didn't spot this issue.
>>>>>
>>>>> To sum that: my patch is required for any system without physical TPM with with
>>>>> kernel with b59fda449cf0 + it also works for TPM 1.2 (regardless kernel
>>>>> version), because TPM 1.2 supports sha1 only boot aggregate.
>>>>>
>>>>> But testing on kernel with b59fda449cf0 with TPM 2.0 is not only broken with
>>>>> this patch, but also on current version in master, right? As you have
>>>>> sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 anyway.
>>>>> So this patch would help at least testing on VM without vTPM.
>>>>>
>>>> If we consider to delay this change until we have the ima-evm-utils
>>>> released with the ima_boot_aggregate + make this test dependent on
>>>> both ima-evm-utils and tsspcrread, would it be worth to SKIP the test in
>>>> case a TPM2.0 sha256 bank is detected instead of FAIL? Thus we could
>>>> have the test fixed for TPM1.2 && no-TPM cases until we get the full
>>>> support for multiple banks?
>>> As long as we're dealing with the "boot_aggregate", Maurizio just
>>> posted a kernel patch for including PCR 8 & 9 in the boot_aggregate.
>>> The existing IMA LTP "boot_aggregate" test is going to need to
>>> support this change.
>>>
>>> I'd appreciate if someone could send me a TPM event log, the PCRs, and
>>> the associated IMA ascii_runtime_measurements "boot_aggregate" from a
>>> system with a discrete TPM 2.0 with PCRs 8 & 9 events.
>>>
> Maybe Maurizio already have it at hand?
> I can try to setup a system with grub2+tpm to get the log with pcr 8 and
> 9 filled.
Hi Bruno, I confirm I have a couple of systems on where 8 & 9 and the
IMA list are filled at boot (already shared with Mimi), now I am
figuring out how to produce TPM event logs as well.
^ permalink raw reply [flat|nested] 38+ messages in thread* [LTP] [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
@ 2020-06-17 22:19 ` Maurizio Drocco
0 siblings, 0 replies; 38+ messages in thread
From: Maurizio Drocco @ 2020-06-17 22:19 UTC (permalink / raw)
To: ltp
On 6/17/2020 4:45 PM, Bruno Meneguele wrote:
> On Tue, Jun 16, 2020 at 06:21:48PM -0700, Jerry Snitselaar wrote:
>> On Mon Jun 15 20, Mimi Zohar wrote:
>>> On Mon, 2020-06-15 at 16:41 -0300, Bruno Meneguele wrote:
>>>> On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote:
>>>>> Hi Mimi,
>>>>> ...
>>>>>>>> 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.
>>>>> OK, I tested it on TPM 1.2 (no TPM 2.0 available atm).
>>>>> I guess you have TPM 2.0, that's why I didn't spot this issue.
>>>>>
>>>>> To sum that: my patch is required for any system without physical TPM with with
>>>>> kernel with b59fda449cf0 + it also works for TPM 1.2 (regardless kernel
>>>>> version), because TPM 1.2 supports sha1 only boot aggregate.
>>>>>
>>>>> But testing on kernel with b59fda449cf0 with TPM 2.0 is not only broken with
>>>>> this patch, but also on current version in master, right? As you have
>>>>> sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 anyway.
>>>>> So this patch would help at least testing on VM without vTPM.
>>>>>
>>>> If we consider to delay this change until we have the ima-evm-utils
>>>> released with the ima_boot_aggregate + make this test dependent on
>>>> both ima-evm-utils and tsspcrread, would it be worth to SKIP the test in
>>>> case a TPM2.0 sha256 bank is detected instead of FAIL? Thus we could
>>>> have the test fixed for TPM1.2 && no-TPM cases until we get the full
>>>> support for multiple banks?
>>> As long as we're dealing with the "boot_aggregate", Maurizio just
>>> posted a kernel patch for including PCR 8 & 9 in the boot_aggregate.
>>> ?The existing IMA LTP "boot_aggregate" test is going to need to
>>> support this change.
>>>
>>> I'd appreciate if someone could send me a TPM event log, the PCRs, and
>>> the associated IMA ascii_runtime_measurements "boot_aggregate" from a
>>> system with a discrete TPM 2.0 with PCRs 8 & 9 events.
>>>
> Maybe Maurizio already have it at hand?
> I can try to setup a system with grub2+tpm to get the log with pcr 8 and
> 9 filled.
Hi Bruno, I confirm I have a couple of systems on where 8 & 9 and the
IMA list are filled at boot (already shared with Mimi), now I am
figuring out how to produce TPM event logs as well.
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
2020-06-17 20:45 ` [LTP] " Bruno Meneguele
@ 2020-06-19 8:21 ` Petr Vorel
-1 siblings, 0 replies; 38+ messages in thread
From: Petr Vorel @ 2020-06-19 8:21 UTC (permalink / raw)
To: Bruno Meneguele
Cc: Jerry Snitselaar, Mimi Zohar, ltp, Mimi Zohar, Petr Cervinka,
Cyril Hrubis, linux-integrity, Vitaly Chikunov, Maurizio Drocco
Hi all,
...
> > > I'd appreciate if someone could send me a TPM event log, the PCRs, and
> > > the associated IMA ascii_runtime_measurements "boot_aggregate" from a
> > > system with a discrete TPM 2.0 with PCRs 8 & 9 events.
> Maybe Maurizio already have it at hand?
I'd appreciate to have these files as well.
> I can try to setup a system with grub2+tpm to get the log with pcr 8 and
> 9 filled.
> > > > > ...
> > > > > > > > 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.
> > > > > Hm, things get complicated.
> > > > > Yep I remember your patch to skip verifying TPM 2.0 PCR values
> > > > > https://patchwork.ozlabs.org/project/ltp/patch/1558041162.3971.2.camel@linux.ibm.com/
> > > > > At least thanks to Jerry Snitselaar since v5.6 we have
> > > > > /sys/class/tpm/tpm*/tpm_version_major. We could check this (+ try also
> > > > > /sys/class/tpm/tpm0/device/description for older kernels).
> > > > > BTW on my system there is also /sys/class/tpm/tpm0/ppi/version, which has 1.2,
> > > > > not sure if it indicate TPM 1.2, but I wouldn't rely on that.
> Missed this last paragraph.. but /sys/class/tpm/tpm0/ppi/version has
> relation to the Physical Presence Interface version, which is the
> communication interface between firmware and OS afaik, and doesn't
> points to the TPM version: TPM2.0 may have PPI version 1.2 or 1.3.
Kind regards,
Petr
^ permalink raw reply [flat|nested] 38+ messages in thread* [LTP] [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
@ 2020-06-19 8:21 ` Petr Vorel
0 siblings, 0 replies; 38+ messages in thread
From: Petr Vorel @ 2020-06-19 8:21 UTC (permalink / raw)
To: ltp
Hi all,
...
> > > I'd appreciate if someone could send me a TPM event log, the PCRs, and
> > > the associated IMA ascii_runtime_measurements "boot_aggregate" from a
> > > system with a discrete TPM 2.0 with PCRs 8 & 9 events.
> Maybe Maurizio already have it at hand?
I'd appreciate to have these files as well.
> I can try to setup a system with grub2+tpm to get the log with pcr 8 and
> 9 filled.
> > > > > ...
> > > > > > > > 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.
> > > > > Hm, things get complicated.
> > > > > Yep I remember your patch to skip verifying TPM 2.0 PCR values
> > > > > https://patchwork.ozlabs.org/project/ltp/patch/1558041162.3971.2.camel@linux.ibm.com/
> > > > > At least thanks to Jerry Snitselaar since v5.6 we have
> > > > > /sys/class/tpm/tpm*/tpm_version_major. We could check this (+ try also
> > > > > /sys/class/tpm/tpm0/device/description for older kernels).
> > > > > BTW on my system there is also /sys/class/tpm/tpm0/ppi/version, which has 1.2,
> > > > > not sure if it indicate TPM 1.2, but I wouldn't rely on that.
> Missed this last paragraph.. but /sys/class/tpm/tpm0/ppi/version has
> relation to the Physical Presence Interface version, which is the
> communication interface between firmware and OS afaik, and doesn't
> points to the TPM version: TPM2.0 may have PPI version 1.2 or 1.3.
Kind regards,
Petr
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
2020-06-19 8:21 ` [LTP] " Petr Vorel
@ 2020-06-19 12:43 ` Mimi Zohar
-1 siblings, 0 replies; 38+ messages in thread
From: Mimi Zohar @ 2020-06-19 12:43 UTC (permalink / raw)
To: Petr Vorel, Bruno Meneguele
Cc: Jerry Snitselaar, ltp, Mimi Zohar, Petr Cervinka, Cyril Hrubis,
linux-integrity, Vitaly Chikunov, Maurizio Drocco
On Fri, 2020-06-19 at 10:21 +0200, Petr Vorel wrote:
> Hi all,
>
> ...
> > > > I'd appreciate if someone could send me a TPM event log, the PCRs, and
> > > > the associated IMA ascii_runtime_measurements "boot_aggregate" from a
> > > > system with a discrete TPM 2.0 with PCRs 8 & 9 events.
>
>
> > Maybe Maurizio already have it at hand?
> I'd appreciate to have these files as well.
>
> > I can try to setup a system with grub2+tpm to get the log with pcr 8 and
> > 9 filled.
Both RHEL 8 and Ubuntu 20.04 LTS have PCRs 8 & 9. I'll include one as
another example for the tests/boot_aggregate.test.
Mimi
^ permalink raw reply [flat|nested] 38+ messages in thread
* [LTP] [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
@ 2020-06-19 12:43 ` Mimi Zohar
0 siblings, 0 replies; 38+ messages in thread
From: Mimi Zohar @ 2020-06-19 12:43 UTC (permalink / raw)
To: ltp
On Fri, 2020-06-19 at 10:21 +0200, Petr Vorel wrote:
> Hi all,
>
> ...
> > > > I'd appreciate if someone could send me a TPM event log, the PCRs, and
> > > > the associated IMA ascii_runtime_measurements "boot_aggregate" from a
> > > > system with a discrete TPM 2.0 with PCRs 8 & 9 events.
>
>
> > Maybe Maurizio already have it at hand?
> I'd appreciate to have these files as well.
>
> > I can try to setup a system with grub2+tpm to get the log with pcr 8 and
> > 9 filled.
Both RHEL 8 and Ubuntu 20.04 LTS have PCRs 8 & 9. ?I'll include one as
another example for the tests/boot_aggregate.test.
Mimi
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
2020-06-19 12:43 ` [LTP] " Mimi Zohar
@ 2020-06-19 13:01 ` Petr Vorel
-1 siblings, 0 replies; 38+ messages in thread
From: Petr Vorel @ 2020-06-19 13:01 UTC (permalink / raw)
To: Mimi Zohar
Cc: Bruno Meneguele, Jerry Snitselaar, ltp, Mimi Zohar, Petr Cervinka,
Cyril Hrubis, linux-integrity, Vitaly Chikunov, Maurizio Drocco
Hi Mimi,
> > ...
> > > > > I'd appreciate if someone could send me a TPM event log, the PCRs, and
> > > > > the associated IMA ascii_runtime_measurements "boot_aggregate" from a
> > > > > system with a discrete TPM 2.0 with PCRs 8 & 9 events.
> > > Maybe Maurizio already have it at hand?
> > I'd appreciate to have these files as well.
> > > I can try to setup a system with grub2+tpm to get the log with pcr 8 and
> > > 9 filled.
> Both RHEL 8 and Ubuntu 20.04 LTS have PCRs 8 & 9. I'll include one as
> another example for the tests/boot_aggregate.test.
Thank you!
Kind regards,
Petr
^ permalink raw reply [flat|nested] 38+ messages in thread
* [LTP] [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
@ 2020-06-19 13:01 ` Petr Vorel
0 siblings, 0 replies; 38+ messages in thread
From: Petr Vorel @ 2020-06-19 13:01 UTC (permalink / raw)
To: ltp
Hi Mimi,
> > ...
> > > > > I'd appreciate if someone could send me a TPM event log, the PCRs, and
> > > > > the associated IMA ascii_runtime_measurements "boot_aggregate" from a
> > > > > system with a discrete TPM 2.0 with PCRs 8 & 9 events.
> > > Maybe Maurizio already have it at hand?
> > I'd appreciate to have these files as well.
> > > I can try to setup a system with grub2+tpm to get the log with pcr 8 and
> > > 9 filled.
> Both RHEL 8 and Ubuntu 20.04 LTS have PCRs 8 & 9. ?I'll include one as
> another example for the tests/boot_aggregate.test.
Thank you!
Kind regards,
Petr
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
2020-06-15 20:21 ` [LTP] " Mimi Zohar
@ 2020-06-19 10:07 ` Petr Vorel
-1 siblings, 0 replies; 38+ messages in thread
From: Petr Vorel @ 2020-06-19 10:07 UTC (permalink / raw)
To: Mimi Zohar
Cc: Bruno Meneguele, ltp, Mimi Zohar, Petr Cervinka, Cyril Hrubis,
linux-integrity, Vitaly Chikunov, Maurizio Drocco
Hi all,
> On Mon, 2020-06-15 at 16:41 -0300, Bruno Meneguele wrote:
> > On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote:
> > > Hi Mimi,
...
> > > To sum that: my patch is required for any system without physical TPM with with
> > > kernel with b59fda449cf0 + it also works for TPM 1.2 (regardless kernel
> > > version), because TPM 1.2 supports sha1 only boot aggregate.
> > > But testing on kernel with b59fda449cf0 with TPM 2.0 is not only broken with
> > > this patch, but also on current version in master, right? As you have
> > > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 anyway.
> > > So this patch would help at least testing on VM without vTPM.
> > If we consider to delay this change until we have the ima-evm-utils
> > released with the ima_boot_aggregate + make this test dependent on
> > both ima-evm-utils and tsspcrread, would it be worth to SKIP the test in
> > case a TPM2.0 sha256 bank is detected instead of FAIL? Thus we could
> > have the test fixed for TPM1.2 && no-TPM cases until we get the full
> > support for multiple banks?
+1
> As long as we're dealing with the "boot_aggregate", Maurizio just
> posted a kernel patch for including PCR 8 & 9 in the boot_aggregate.
> The existing IMA LTP "boot_aggregate" test is going to need to
> support this change.
I'm not sure if I did something wrong, but it looks to me that 'evmctl
ima_boot_aggregate' does not provide backward compatibility with TPM 1.2.
Or am I wrong?
And given the fact that new evmctl is not released, I'd adapt the test just for
TPM 1.2 && no-TPM as Bruno suggested (TCONF if
/sys/class/tpm/tpm0/tpm_version_major presented and not 1, print info about TPM
2.0 not yet supported otherwise).
BTW what is the correct way for systems with more TPM (is there any? It looks
it's possible [1]). Which of them is used? Should I loop over
/sys/class/tpm/tpm*/tpm_version_major or just use
/sys/class/tpm/tpm0/tpm_version_major?
Kind regards,
Petr
[1] https://letstrust.de/archives/29-New-fun-fact!.html
^ permalink raw reply [flat|nested] 38+ messages in thread
* [LTP] [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
@ 2020-06-19 10:07 ` Petr Vorel
0 siblings, 0 replies; 38+ messages in thread
From: Petr Vorel @ 2020-06-19 10:07 UTC (permalink / raw)
To: ltp
Hi all,
> On Mon, 2020-06-15 at 16:41 -0300, Bruno Meneguele wrote:
> > On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote:
> > > Hi Mimi,
...
> > > To sum that: my patch is required for any system without physical TPM with with
> > > kernel with b59fda449cf0 + it also works for TPM 1.2 (regardless kernel
> > > version), because TPM 1.2 supports sha1 only boot aggregate.
> > > But testing on kernel with b59fda449cf0 with TPM 2.0 is not only broken with
> > > this patch, but also on current version in master, right? As you have
> > > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 anyway.
> > > So this patch would help at least testing on VM without vTPM.
> > If we consider to delay this change until we have the ima-evm-utils
> > released with the ima_boot_aggregate + make this test dependent on
> > both ima-evm-utils and tsspcrread, would it be worth to SKIP the test in
> > case a TPM2.0 sha256 bank is detected instead of FAIL? Thus we could
> > have the test fixed for TPM1.2 && no-TPM cases until we get the full
> > support for multiple banks?
+1
> As long as we're dealing with the "boot_aggregate", Maurizio just
> posted a kernel patch for including PCR 8 & 9 in the boot_aggregate.
> ?The existing IMA LTP "boot_aggregate" test is going to need to
> support this change.
I'm not sure if I did something wrong, but it looks to me that 'evmctl
ima_boot_aggregate' does not provide backward compatibility with TPM 1.2.
Or am I wrong?
And given the fact that new evmctl is not released, I'd adapt the test just for
TPM 1.2 && no-TPM as Bruno suggested (TCONF if
/sys/class/tpm/tpm0/tpm_version_major presented and not 1, print info about TPM
2.0 not yet supported otherwise).
BTW what is the correct way for systems with more TPM (is there any? It looks
it's possible [1]). Which of them is used? Should I loop over
/sys/class/tpm/tpm*/tpm_version_major or just use
/sys/class/tpm/tpm0/tpm_version_major?
Kind regards,
Petr
[1] https://letstrust.de/archives/29-New-fun-fact!.html
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
2020-06-19 10:07 ` [LTP] " Petr Vorel
@ 2020-06-19 13:01 ` Mimi Zohar
-1 siblings, 0 replies; 38+ messages in thread
From: Mimi Zohar @ 2020-06-19 13:01 UTC (permalink / raw)
To: Petr Vorel
Cc: Bruno Meneguele, ltp, Mimi Zohar, Petr Cervinka, Cyril Hrubis,
linux-integrity, Vitaly Chikunov, Maurizio Drocco
On Fri, 2020-06-19 at 12:07 +0200, Petr Vorel wrote:
> Hi all,
>
> > On Mon, 2020-06-15 at 16:41 -0300, Bruno Meneguele wrote:
> > > On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote:
> > > > Hi Mimi,
> ...
> > > > To sum that: my patch is required for any system without physical TPM with with
> > > > kernel with b59fda449cf0 + it also works for TPM 1.2 (regardless kernel
> > > > version), because TPM 1.2 supports sha1 only boot aggregate.
>
> > > > But testing on kernel with b59fda449cf0 with TPM 2.0 is not only broken with
> > > > this patch, but also on current version in master, right? As you have
> > > > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 anyway.
> > > > So this patch would help at least testing on VM without vTPM.
>
>
> > > If we consider to delay this change until we have the ima-evm-utils
> > > released with the ima_boot_aggregate + make this test dependent on
> > > both ima-evm-utils and tsspcrread, would it be worth to SKIP the test in
> > > case a TPM2.0 sha256 bank is detected instead of FAIL? Thus we could
> > > have the test fixed for TPM1.2 && no-TPM cases until we get the full
> > > support for multiple banks?
> +1
>
> > As long as we're dealing with the "boot_aggregate", Maurizio just
> > posted a kernel patch for including PCR 8 & 9 in the boot_aggregate.
> > The existing IMA LTP "boot_aggregate" test is going to need to
> > support this change.
> I'm not sure if I did something wrong, but it looks to me that 'evmctl
> ima_boot_aggregate' does not provide backward compatibility with TPM 1.2.
> Or am I wrong?
Calculating the "boot_aggregate" - "evmctl ima_boot_aggregate" - for
TPM 1.2 should work. Reading the code, it looks like it assumes that
the crypto library supports SHA1 and SHA256. That assumption needs to
be addressed.
The tests/boot_aggregate.test logs are TPM 2.0. The test is failing
on systems with a TPM 1.2. I'm working on a fix for this.
Mimi
^ permalink raw reply [flat|nested] 38+ messages in thread
* [LTP] [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
@ 2020-06-19 13:01 ` Mimi Zohar
0 siblings, 0 replies; 38+ messages in thread
From: Mimi Zohar @ 2020-06-19 13:01 UTC (permalink / raw)
To: ltp
On Fri, 2020-06-19 at 12:07 +0200, Petr Vorel wrote:
> Hi all,
>
> > On Mon, 2020-06-15 at 16:41 -0300, Bruno Meneguele wrote:
> > > On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote:
> > > > Hi Mimi,
> ...
> > > > To sum that: my patch is required for any system without physical TPM with with
> > > > kernel with b59fda449cf0 + it also works for TPM 1.2 (regardless kernel
> > > > version), because TPM 1.2 supports sha1 only boot aggregate.
>
> > > > But testing on kernel with b59fda449cf0 with TPM 2.0 is not only broken with
> > > > this patch, but also on current version in master, right? As you have
> > > > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5 anyway.
> > > > So this patch would help at least testing on VM without vTPM.
>
>
> > > If we consider to delay this change until we have the ima-evm-utils
> > > released with the ima_boot_aggregate + make this test dependent on
> > > both ima-evm-utils and tsspcrread, would it be worth to SKIP the test in
> > > case a TPM2.0 sha256 bank is detected instead of FAIL? Thus we could
> > > have the test fixed for TPM1.2 && no-TPM cases until we get the full
> > > support for multiple banks?
> +1
>
> > As long as we're dealing with the "boot_aggregate", Maurizio just
> > posted a kernel patch for including PCR 8 & 9 in the boot_aggregate.
> > ?The existing IMA LTP "boot_aggregate" test is going to need to
> > support this change.
> I'm not sure if I did something wrong, but it looks to me that 'evmctl
> ima_boot_aggregate' does not provide backward compatibility with TPM 1.2.
> Or am I wrong?
Calculating the "boot_aggregate" - "evmctl ima_boot_aggregate" - for
TPM 1.2 should work. ?Reading the code, it looks like it assumes that
the crypto library supports SHA1 and SHA256. ?That assumption needs to
be addressed.
The tests/boot_aggregate.test logs are TPM 2.0. ?The test is failing
on systems with a TPM 1.2. ?I'm working on a fix for this.
Mimi
^ permalink raw reply [flat|nested] 38+ messages in thread