* [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
@ 2020-05-27 7:14 ` Petr Vorel
0 siblings, 0 replies; 38+ messages in thread
From: Petr Vorel @ 2020-05-27 7:14 UTC (permalink / raw)
To: ltp; +Cc: Petr Vorel, Mimi Zohar, Petr Cervinka, Cyril Hrubis, linux-integrity
Fixes test for kernel commit: 6f1a1d103b48 ima: ("Switch to
ima_hash_algo for boot aggregate") from current linux-integrity tree.
Tests was failing, because it expect SHA1 hash, but for TPM 2.0 is
now used IMA default hash algorithm (by default default SHA256).
This is similar for entries in IMA measurement list so we can reuse
already existing code.
Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
changes v1->v2:
* removing global variables from get_algorithm_digest (hopefully it's
less ugly)
Tested only on VM. Can anybody test it on real HW?
Kind regards,
Petr
.../integrity/ima/tests/ima_measurements.sh | 62 ++---------------
.../security/integrity/ima/tests/ima_setup.sh | 69 +++++++++++++++++++
.../security/integrity/ima/tests/ima_tpm.sh | 29 +++++---
3 files changed, 96 insertions(+), 64 deletions(-)
diff --git a/testcases/kernel/security/integrity/ima/tests/ima_measurements.sh b/testcases/kernel/security/integrity/ima/tests/ima_measurements.sh
index 54237d688..50de4df98 100755
--- a/testcases/kernel/security/integrity/ima/tests/ima_measurements.sh
+++ b/testcases/kernel/security/integrity/ima/tests/ima_measurements.sh
@@ -6,7 +6,7 @@
#
# Verify that measurements are added to the measurement list based on policy.
-TST_NEEDS_CMDS="awk cut"
+TST_NEEDS_CMDS="awk cut sed"
TST_SETUP="setup"
TST_CNT=3
TST_NEEDS_DEVICE=1
@@ -20,30 +20,8 @@ setup()
TEST_FILE="$PWD/test.txt"
POLICY="$IMA_DIR/policy"
[ -f "$POLICY" ] || tst_res TINFO "not using default policy"
- DIGEST_INDEX=
-
- local template="$(tail -1 $ASCII_MEASUREMENTS | cut -d' ' -f 3)"
- local i
-
- # parse digest index
- # https://www.kernel.org/doc/html/latest/security/IMA-templates.html#use
- case "$template" in
- ima|ima-ng|ima-sig) DIGEST_INDEX=4 ;;
- *)
- # using ima_template_fmt kernel parameter
- local IFS="|"
- i=4
- for word in $template; do
- if [ "$word" = 'd' -o "$word" = 'd-ng' ]; then
- DIGEST_INDEX=$i
- break
- fi
- i=$((i+1))
- done
- esac
- [ -z "$DIGEST_INDEX" ] && tst_brk TCONF \
- "Cannot find digest index (template: '$template')"
+ set_digest_index
}
# TODO: find support for rmd128 rmd256 rmd320 wp256 wp384 tgr128 tgr160
@@ -82,44 +60,18 @@ compute_digest()
ima_check()
{
- local delimiter=':'
- local algorithm digest expected_digest line
+ local algorithm digest expected_digest line tmp
# need to read file to get updated $ASCII_MEASUREMENTS
cat $TEST_FILE > /dev/null
line="$(grep $TEST_FILE $ASCII_MEASUREMENTS | tail -1)"
- if [ -z "$line" ]; then
- tst_res TFAIL "cannot find measurement record for '$TEST_FILE'"
- return
- fi
- tst_res TINFO "measurement record: '$line'"
-
- digest=$(echo "$line" | cut -d' ' -f $DIGEST_INDEX)
- if [ -z "$digest" ]; then
- tst_res TFAIL "cannot find digest (index: $DIGEST_INDEX)"
- return
- fi
- if [ "${digest#*$delimiter}" != "$digest" ]; then
- algorithm=$(echo "$digest" | cut -d $delimiter -f 1)
- digest=$(echo "$digest" | cut -d $delimiter -f 2)
+ if tmp=$(get_algorithm_digest "$line"); then
+ algorithm=$(echo "$tmp" | cut -d'|' -f1)
+ digest=$(echo "$tmp" | cut -d'|' -f2)
else
- case "${#digest}" in
- 32) algorithm="md5" ;;
- 40) algorithm="sha1" ;;
- *)
- tst_res TFAIL "algorithm must be either md5 or sha1 (digest: '$digest')"
- return ;;
- esac
- fi
- if [ -z "$algorithm" ]; then
- tst_res TFAIL "cannot find algorithm"
- return
- fi
- if [ -z "$digest" ]; then
- tst_res TFAIL "cannot find digest"
- return
+ tst_res TBROK "failed to get algorithm/digest for '$TEST_FILE': $tmp"
fi
tst_res TINFO "computing digest for $algorithm algorithm"
diff --git a/testcases/kernel/security/integrity/ima/tests/ima_setup.sh b/testcases/kernel/security/integrity/ima/tests/ima_setup.sh
index 58a12eda3..104088e52 100644
--- a/testcases/kernel/security/integrity/ima/tests/ima_setup.sh
+++ b/testcases/kernel/security/integrity/ima/tests/ima_setup.sh
@@ -112,6 +112,75 @@ ima_cleanup()
fi
}
+set_digest_index()
+{
+ DIGEST_INDEX=
+
+ local template="$(tail -1 $ASCII_MEASUREMENTS | cut -d' ' -f 3)"
+ local i word
+
+ # parse digest index
+ # https://www.kernel.org/doc/html/latest/security/IMA-templates.html#use
+ case "$template" in
+ ima|ima-ng|ima-sig) DIGEST_INDEX=4 ;;
+ *)
+ # using ima_template_fmt kernel parameter
+ local IFS="|"
+ i=4
+ for word in $template; do
+ if [ "$word" = 'd' -o "$word" = 'd-ng' ]; then
+ DIGEST_INDEX=$i
+ break
+ fi
+ i=$((i+1))
+ done
+ esac
+
+ [ -z "$DIGEST_INDEX" ] && tst_brk TCONF \
+ "Cannot find digest index (template: '$template')"
+}
+
+get_algorithm_digest()
+{
+ local line="$1"
+ local delimiter=':'
+ local algorithm digest
+
+ if [ -z "$line" ]; then
+ echo "measurement record not found"
+ return 1
+ fi
+
+ digest=$(echo "$line" | cut -d' ' -f $DIGEST_INDEX)
+ if [ -z "$digest" ]; then
+ echo "digest not found (index: $DIGEST_INDEX, line: '$line')"
+ return 1
+ fi
+
+ if [ "${digest#*$delimiter}" != "$digest" ]; then
+ algorithm=$(echo "$digest" | cut -d $delimiter -f 1)
+ digest=$(echo "$digest" | cut -d $delimiter -f 2)
+ else
+ case "${#digest}" in
+ 32) algorithm="md5" ;;
+ 40) algorithm="sha1" ;;
+ *)
+ echo "algorithm must be either md5 or sha1 (digest: '$digest')"
+ return 1 ;;
+ esac
+ fi
+ if [ -z "$algorithm" ]; then
+ echo "algorithm not found"
+ return 1
+ fi
+ if [ -z "$digest" ]; then
+ echo "digest not found"
+ return 1
+ fi
+
+ echo "$algorithm|$digest"
+}
+
# loop device is needed to use only for tmpfs
TMPDIR="${TMPDIR:-/tmp}"
if [ "$(df -T $TMPDIR | tail -1 | awk '{print $2}')" != "tmpfs" -a -n "$TST_NEEDS_DEVICE" ]; then
diff --git a/testcases/kernel/security/integrity/ima/tests/ima_tpm.sh b/testcases/kernel/security/integrity/ima/tests/ima_tpm.sh
index c69f891f1..444d76d62 100755
--- a/testcases/kernel/security/integrity/ima/tests/ima_tpm.sh
+++ b/testcases/kernel/security/integrity/ima/tests/ima_tpm.sh
@@ -7,6 +7,7 @@
# Verify the boot and PCR aggregates.
TST_CNT=2
+TST_SETUP="set_digest_index"
TST_NEEDS_CMDS="awk cut ima_boot_aggregate"
. ima_setup.sh
@@ -15,29 +16,39 @@ test1()
{
tst_res TINFO "verify boot aggregate"
- local zero="0000000000000000000000000000000000000000"
local tpm_bios="$SECURITYFS/tpm0/binary_bios_measurements"
local ima_measurements="$ASCII_MEASUREMENTS"
- local boot_aggregate boot_hash line
+ local algorithm boot_aggregate digest line tmp zero
# IMA boot aggregate
read line < $ima_measurements
- boot_hash=$(echo $line | awk '{print $(NF-1)}' | cut -d':' -f2)
+
+ if tmp=$(get_algorithm_digest "$line"); then
+ algorithm=$(echo "$tmp" | cut -d'|' -f1)
+ digest=$(echo "$tmp" | cut -d'|' -f2)
+ else
+ tst_res TBROK "failed to get algorithm/digest: $tmp"
+ fi
+
+ tst_res TINFO "used algorithm: $algorithm"
if [ ! -f "$tpm_bios" ]; then
tst_res TINFO "TPM Hardware Support not enabled in kernel or no TPM chip found"
- if [ "$boot_hash" = "$zero" ]; then
- tst_res TPASS "bios boot aggregate is 0"
+ zero=$(echo $digest | awk '{gsub(/./, "0")}; {print}')
+ if [ "$digest" = "$zero" ]; then
+ tst_res TPASS "bios boot aggregate is $zero"
else
- tst_res TFAIL "bios boot aggregate is not 0"
+ tst_res TFAIL "bios boot aggregate is not $zero ($digest)"
fi
else
boot_aggregate=$(ima_boot_aggregate $tpm_bios | grep "boot_aggregate:" | cut -d':' -f2)
- if [ "$boot_hash" = "$boot_aggregate" ]; then
- tst_res TPASS "bios aggregate matches IMA boot aggregate"
+ tst_res TINFO "IMA boot aggregate: '$boot_aggregate'"
+
+ if [ "$digest" = "$boot_aggregate" ]; then
+ tst_res TPASS "bios boot aggregate matches IMA boot aggregate"
else
- tst_res TFAIL "bios aggregate does not match IMA boot aggregate"
+ tst_res TFAIL "bios boot aggregate does not match IMA boot aggregate ($digest)"
fi
fi
}
--
2.26.2
^ permalink raw reply related [flat|nested] 38+ messages in thread
* [LTP] [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
@ 2020-05-27 7:14 ` Petr Vorel
0 siblings, 0 replies; 38+ messages in thread
From: Petr Vorel @ 2020-05-27 7:14 UTC (permalink / raw)
To: ltp
Fixes test for kernel commit: 6f1a1d103b48 ima: ("Switch to
ima_hash_algo for boot aggregate") from current linux-integrity tree.
Tests was failing, because it expect SHA1 hash, but for TPM 2.0 is
now used IMA default hash algorithm (by default default SHA256).
This is similar for entries in IMA measurement list so we can reuse
already existing code.
Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
changes v1->v2:
* removing global variables from get_algorithm_digest (hopefully it's
less ugly)
Tested only on VM. Can anybody test it on real HW?
Kind regards,
Petr
.../integrity/ima/tests/ima_measurements.sh | 62 ++---------------
.../security/integrity/ima/tests/ima_setup.sh | 69 +++++++++++++++++++
.../security/integrity/ima/tests/ima_tpm.sh | 29 +++++---
3 files changed, 96 insertions(+), 64 deletions(-)
diff --git a/testcases/kernel/security/integrity/ima/tests/ima_measurements.sh b/testcases/kernel/security/integrity/ima/tests/ima_measurements.sh
index 54237d688..50de4df98 100755
--- a/testcases/kernel/security/integrity/ima/tests/ima_measurements.sh
+++ b/testcases/kernel/security/integrity/ima/tests/ima_measurements.sh
@@ -6,7 +6,7 @@
#
# Verify that measurements are added to the measurement list based on policy.
-TST_NEEDS_CMDS="awk cut"
+TST_NEEDS_CMDS="awk cut sed"
TST_SETUP="setup"
TST_CNT=3
TST_NEEDS_DEVICE=1
@@ -20,30 +20,8 @@ setup()
TEST_FILE="$PWD/test.txt"
POLICY="$IMA_DIR/policy"
[ -f "$POLICY" ] || tst_res TINFO "not using default policy"
- DIGEST_INDEX=
-
- local template="$(tail -1 $ASCII_MEASUREMENTS | cut -d' ' -f 3)"
- local i
-
- # parse digest index
- # https://www.kernel.org/doc/html/latest/security/IMA-templates.html#use
- case "$template" in
- ima|ima-ng|ima-sig) DIGEST_INDEX=4 ;;
- *)
- # using ima_template_fmt kernel parameter
- local IFS="|"
- i=4
- for word in $template; do
- if [ "$word" = 'd' -o "$word" = 'd-ng' ]; then
- DIGEST_INDEX=$i
- break
- fi
- i=$((i+1))
- done
- esac
- [ -z "$DIGEST_INDEX" ] && tst_brk TCONF \
- "Cannot find digest index (template: '$template')"
+ set_digest_index
}
# TODO: find support for rmd128 rmd256 rmd320 wp256 wp384 tgr128 tgr160
@@ -82,44 +60,18 @@ compute_digest()
ima_check()
{
- local delimiter=':'
- local algorithm digest expected_digest line
+ local algorithm digest expected_digest line tmp
# need to read file to get updated $ASCII_MEASUREMENTS
cat $TEST_FILE > /dev/null
line="$(grep $TEST_FILE $ASCII_MEASUREMENTS | tail -1)"
- if [ -z "$line" ]; then
- tst_res TFAIL "cannot find measurement record for '$TEST_FILE'"
- return
- fi
- tst_res TINFO "measurement record: '$line'"
-
- digest=$(echo "$line" | cut -d' ' -f $DIGEST_INDEX)
- if [ -z "$digest" ]; then
- tst_res TFAIL "cannot find digest (index: $DIGEST_INDEX)"
- return
- fi
- if [ "${digest#*$delimiter}" != "$digest" ]; then
- algorithm=$(echo "$digest" | cut -d $delimiter -f 1)
- digest=$(echo "$digest" | cut -d $delimiter -f 2)
+ if tmp=$(get_algorithm_digest "$line"); then
+ algorithm=$(echo "$tmp" | cut -d'|' -f1)
+ digest=$(echo "$tmp" | cut -d'|' -f2)
else
- case "${#digest}" in
- 32) algorithm="md5" ;;
- 40) algorithm="sha1" ;;
- *)
- tst_res TFAIL "algorithm must be either md5 or sha1 (digest: '$digest')"
- return ;;
- esac
- fi
- if [ -z "$algorithm" ]; then
- tst_res TFAIL "cannot find algorithm"
- return
- fi
- if [ -z "$digest" ]; then
- tst_res TFAIL "cannot find digest"
- return
+ tst_res TBROK "failed to get algorithm/digest for '$TEST_FILE': $tmp"
fi
tst_res TINFO "computing digest for $algorithm algorithm"
diff --git a/testcases/kernel/security/integrity/ima/tests/ima_setup.sh b/testcases/kernel/security/integrity/ima/tests/ima_setup.sh
index 58a12eda3..104088e52 100644
--- a/testcases/kernel/security/integrity/ima/tests/ima_setup.sh
+++ b/testcases/kernel/security/integrity/ima/tests/ima_setup.sh
@@ -112,6 +112,75 @@ ima_cleanup()
fi
}
+set_digest_index()
+{
+ DIGEST_INDEX=
+
+ local template="$(tail -1 $ASCII_MEASUREMENTS | cut -d' ' -f 3)"
+ local i word
+
+ # parse digest index
+ # https://www.kernel.org/doc/html/latest/security/IMA-templates.html#use
+ case "$template" in
+ ima|ima-ng|ima-sig) DIGEST_INDEX=4 ;;
+ *)
+ # using ima_template_fmt kernel parameter
+ local IFS="|"
+ i=4
+ for word in $template; do
+ if [ "$word" = 'd' -o "$word" = 'd-ng' ]; then
+ DIGEST_INDEX=$i
+ break
+ fi
+ i=$((i+1))
+ done
+ esac
+
+ [ -z "$DIGEST_INDEX" ] && tst_brk TCONF \
+ "Cannot find digest index (template: '$template')"
+}
+
+get_algorithm_digest()
+{
+ local line="$1"
+ local delimiter=':'
+ local algorithm digest
+
+ if [ -z "$line" ]; then
+ echo "measurement record not found"
+ return 1
+ fi
+
+ digest=$(echo "$line" | cut -d' ' -f $DIGEST_INDEX)
+ if [ -z "$digest" ]; then
+ echo "digest not found (index: $DIGEST_INDEX, line: '$line')"
+ return 1
+ fi
+
+ if [ "${digest#*$delimiter}" != "$digest" ]; then
+ algorithm=$(echo "$digest" | cut -d $delimiter -f 1)
+ digest=$(echo "$digest" | cut -d $delimiter -f 2)
+ else
+ case "${#digest}" in
+ 32) algorithm="md5" ;;
+ 40) algorithm="sha1" ;;
+ *)
+ echo "algorithm must be either md5 or sha1 (digest: '$digest')"
+ return 1 ;;
+ esac
+ fi
+ if [ -z "$algorithm" ]; then
+ echo "algorithm not found"
+ return 1
+ fi
+ if [ -z "$digest" ]; then
+ echo "digest not found"
+ return 1
+ fi
+
+ echo "$algorithm|$digest"
+}
+
# loop device is needed to use only for tmpfs
TMPDIR="${TMPDIR:-/tmp}"
if [ "$(df -T $TMPDIR | tail -1 | awk '{print $2}')" != "tmpfs" -a -n "$TST_NEEDS_DEVICE" ]; then
diff --git a/testcases/kernel/security/integrity/ima/tests/ima_tpm.sh b/testcases/kernel/security/integrity/ima/tests/ima_tpm.sh
index c69f891f1..444d76d62 100755
--- a/testcases/kernel/security/integrity/ima/tests/ima_tpm.sh
+++ b/testcases/kernel/security/integrity/ima/tests/ima_tpm.sh
@@ -7,6 +7,7 @@
# Verify the boot and PCR aggregates.
TST_CNT=2
+TST_SETUP="set_digest_index"
TST_NEEDS_CMDS="awk cut ima_boot_aggregate"
. ima_setup.sh
@@ -15,29 +16,39 @@ test1()
{
tst_res TINFO "verify boot aggregate"
- local zero="0000000000000000000000000000000000000000"
local tpm_bios="$SECURITYFS/tpm0/binary_bios_measurements"
local ima_measurements="$ASCII_MEASUREMENTS"
- local boot_aggregate boot_hash line
+ local algorithm boot_aggregate digest line tmp zero
# IMA boot aggregate
read line < $ima_measurements
- boot_hash=$(echo $line | awk '{print $(NF-1)}' | cut -d':' -f2)
+
+ if tmp=$(get_algorithm_digest "$line"); then
+ algorithm=$(echo "$tmp" | cut -d'|' -f1)
+ digest=$(echo "$tmp" | cut -d'|' -f2)
+ else
+ tst_res TBROK "failed to get algorithm/digest: $tmp"
+ fi
+
+ tst_res TINFO "used algorithm: $algorithm"
if [ ! -f "$tpm_bios" ]; then
tst_res TINFO "TPM Hardware Support not enabled in kernel or no TPM chip found"
- if [ "$boot_hash" = "$zero" ]; then
- tst_res TPASS "bios boot aggregate is 0"
+ zero=$(echo $digest | awk '{gsub(/./, "0")}; {print}')
+ if [ "$digest" = "$zero" ]; then
+ tst_res TPASS "bios boot aggregate is $zero"
else
- tst_res TFAIL "bios boot aggregate is not 0"
+ tst_res TFAIL "bios boot aggregate is not $zero ($digest)"
fi
else
boot_aggregate=$(ima_boot_aggregate $tpm_bios | grep "boot_aggregate:" | cut -d':' -f2)
- if [ "$boot_hash" = "$boot_aggregate" ]; then
- tst_res TPASS "bios aggregate matches IMA boot aggregate"
+ tst_res TINFO "IMA boot aggregate: '$boot_aggregate'"
+
+ if [ "$digest" = "$boot_aggregate" ]; then
+ tst_res TPASS "bios boot aggregate matches IMA boot aggregate"
else
- tst_res TFAIL "bios aggregate does not match IMA boot aggregate"
+ tst_res TFAIL "bios boot aggregate does not match IMA boot aggregate ($digest)"
fi
fi
}
--
2.26.2
^ permalink raw reply related [flat|nested] 38+ messages in thread
* Re: [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
2020-05-27 7:14 ` [LTP] " Petr Vorel
@ 2020-05-27 17:41 ` Mimi Zohar
-1 siblings, 0 replies; 38+ messages in thread
From: Mimi Zohar @ 2020-05-27 17:41 UTC (permalink / raw)
To: Petr Vorel, ltp; +Cc: Mimi Zohar, Petr Cervinka, Cyril Hrubis, linux-integrity
Hi Petr,
On Wed, 2020-05-27 at 09:14 +0200, Petr Vorel wrote:
> Fixes test for kernel commit: 6f1a1d103b48 ima: ("Switch to
> ima_hash_algo for boot aggregate") from current linux-integrity tree.
>
> Tests was failing, because it expect SHA1 hash, but for TPM 2.0 is
> now used IMA default hash algorithm (by default default SHA256).
> This is similar for entries in IMA measurement list so we can reuse
> already existing code.
>
> Signed-off-by: Petr Vorel <pvorel@suse.cz>
> ---
> changes v1->v2:
> * removing global variables from get_algorithm_digest (hopefully it's
> less ugly)
>
> Tested only on VM. Can anybody test it on real HW?
With just this change, the ima_tpm.sh test is failing. I assume it is
failing because it is reading the SHA1 TPM bank, not the SHA256 bank
to calculate the boot_aggregate hash.
ima_tpm 1 TINFO: timeout per run is 0h 5m 0s
ima_tpm 1 TINFO: IMA kernel config:
ima_tpm 1 TINFO: CONFIG_IMA=y
ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10
ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y
ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y
ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y
ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256"
ima_tpm 1 TINFO: CONFIG_IMA_WRITE_POLICY=y
ima_tpm 1 TINFO: CONFIG_IMA_READ_POLICY=y
ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y
ima_tpm 1 TINFO: CONFIG_IMA_ARCH_POLICY=y
ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y
ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS=y
ima_tpm 1 TINFO: CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS=y
ima_tpm 1 TINFO: CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT=y
ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.6.0-rc3+.signed root=UUID=119f1a79-c391-4e37-905d-3a503284cadb ro quiet splash ima-policy=tcb
ima_tpm 1 TINFO: verify boot aggregate
ima_tpm 1 TINFO: used algorithm: sha256
ima_tpm 1 TINFO: IMA boot aggregate: 'b2341e4ccea25be7fa750830fb5fdf4bef1c44a4'
ima_tpm 1 TFAIL: bios boot aggregate does not match IMA boot aggregate (3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5b)
ima_tpm 2 TINFO: verify PCR values
ima_tpm 2 TINFO: evmctl version: evmctl 1.2
ima_tpm 2 TCONF: TPM Hardware Support not enabled in kernel or no TPM chip found
ima_tpm 3 TINFO: AppArmor enabled, this may affect test results
ima_tpm 3 TINFO: it can be disabled with TST_DISABLE_APPARMOR=1 (requires super/root)
ima_tpm 3 TINFO: loaded AppArmor profiles: none
Summary:
passed 0
failed 1
skipped 1
warnings 0
# head -1 /sys/kernel/security/ima/ascii_runtime_measurements
10 a3132d2501128ff527171658d40d8deb61e2292b ima-ng
sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5
b boot_aggregate
The ima-evm-utils next-testing branch has code to calculate the
boot_aggregate based on multiple banks.
# evmctl ima_boot_aggregate
sha1:4cf3d105b1a1a41b951cc6431f0801c01fe50b24
sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5b
There's also a new test to verify the boot_aggregate.
$ VERBOSE=1 make check TESTS=boog_aggregate.test
Both need some review and testing before being released.
thanks,
Mimi
^ permalink raw reply [flat|nested] 38+ messages in thread
* [LTP] [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
@ 2020-05-27 17:41 ` Mimi Zohar
0 siblings, 0 replies; 38+ messages in thread
From: Mimi Zohar @ 2020-05-27 17:41 UTC (permalink / raw)
To: ltp
Hi Petr,
On Wed, 2020-05-27 at 09:14 +0200, Petr Vorel wrote:
> Fixes test for kernel commit: 6f1a1d103b48 ima: ("Switch to
> ima_hash_algo for boot aggregate") from current linux-integrity tree.
>
> Tests was failing, because it expect SHA1 hash, but for TPM 2.0 is
> now used IMA default hash algorithm (by default default SHA256).
> This is similar for entries in IMA measurement list so we can reuse
> already existing code.
>
> Signed-off-by: Petr Vorel <pvorel@suse.cz>
> ---
> changes v1->v2:
> * removing global variables from get_algorithm_digest (hopefully it's
> less ugly)
>
> Tested only on VM. Can anybody test it on real HW?
With just this change, the ima_tpm.sh test is failing. ?I assume it is
failing because it is reading the SHA1 TPM bank, not the SHA256 bank
to calculate the boot_aggregate hash.
ima_tpm 1 TINFO: timeout per run is 0h 5m 0s
ima_tpm 1 TINFO: IMA kernel config:
ima_tpm 1 TINFO: CONFIG_IMA=y
ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10
ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y
ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y
ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y
ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256"
ima_tpm 1 TINFO: CONFIG_IMA_WRITE_POLICY=y
ima_tpm 1 TINFO: CONFIG_IMA_READ_POLICY=y
ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y
ima_tpm 1 TINFO: CONFIG_IMA_ARCH_POLICY=y
ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y
ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS=y
ima_tpm 1 TINFO: CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS=y
ima_tpm 1 TINFO: CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT=y
ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.6.0-rc3+.signed root=UUID=119f1a79-c391-4e37-905d-3a503284cadb ro quiet splash ima-policy=tcb
ima_tpm 1 TINFO: verify boot aggregate
ima_tpm 1 TINFO: used algorithm: sha256
ima_tpm 1 TINFO: IMA boot aggregate: 'b2341e4ccea25be7fa750830fb5fdf4bef1c44a4'
ima_tpm 1 TFAIL: bios boot aggregate does not match IMA boot aggregate (3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5b)
ima_tpm 2 TINFO: verify PCR values
ima_tpm 2 TINFO: evmctl version: evmctl 1.2
ima_tpm 2 TCONF: TPM Hardware Support not enabled in kernel or no TPM chip found
ima_tpm 3 TINFO: AppArmor enabled, this may affect test results
ima_tpm 3 TINFO: it can be disabled with TST_DISABLE_APPARMOR=1 (requires super/root)
ima_tpm 3 TINFO: loaded AppArmor profiles: none
Summary:
passed 0
failed 1
skipped 1
warnings 0
# head -1 /sys/kernel/security/ima/ascii_runtime_measurements
10 a3132d2501128ff527171658d40d8deb61e2292b ima-ng
sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5
b boot_aggregate
The ima-evm-utils next-testing branch has code to calculate the
boot_aggregate based on multiple banks.
# evmctl ima_boot_aggregate
sha1:4cf3d105b1a1a41b951cc6431f0801c01fe50b24
sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5b
There's also a new test to verify the boot_aggregate.
$ VERBOSE=1 make check TESTS=boog_aggregate.test
Both need some review and testing before being released.
thanks,
Mimi
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
2020-05-27 17:41 ` [LTP] " Mimi Zohar
@ 2020-05-28 14:07 ` Petr Vorel
-1 siblings, 0 replies; 38+ messages in thread
From: Petr Vorel @ 2020-05-28 14:07 UTC (permalink / raw)
To: Mimi Zohar; +Cc: ltp, Mimi Zohar, Petr Cervinka, Cyril Hrubis, linux-integrity
Hi Mimi,
thanks a lot for testing!
> On Wed, 2020-05-27 at 09:14 +0200, Petr Vorel wrote:
> > Fixes test for kernel commit: 6f1a1d103b48 ima: ("Switch to
> > ima_hash_algo for boot aggregate") from current linux-integrity tree.
> > Tests was failing, because it expect SHA1 hash, but for TPM 2.0 is
> > now used IMA default hash algorithm (by default default SHA256).
> > This is similar for entries in IMA measurement list so we can reuse
> > already existing code.
> > Signed-off-by: Petr Vorel <pvorel@suse.cz>
> > ---
> > changes v1->v2:
> > * removing global variables from get_algorithm_digest (hopefully it's
> > less ugly)
> > Tested only on VM. Can anybody test it on real HW?
> With just this change, the ima_tpm.sh test is failing. I assume it is
> failing because it is reading the SHA1 TPM bank, not the SHA256 bank
> to calculate the boot_aggregate hash.
First question: is it correct to take sha256? Because on my test below it's
reading sha1, because that's the content of /sys/kernel/security/ima/ascii_runtime_measurements
I thought just kernel commit: 6f1a1d103b48 ima: ("Switch to ima_hash_algo for
boot aggregate") from current linux-integrity tree is needed, but I tested it on
b59fda449cf0 ("ima: Set again build_ima_appraise variable") (i.e. having all
Robeto's ima patches, missing just last 2 commits from next-integrity head).
What is needed to get your setup?
We both have CONFIG_IMA_DEFAULT_HASH_SHA256=y and CONFIG_IMA_DEFAULT_HASH="sha256".
> ima_tpm 1 TINFO: timeout per run is 0h 5m 0s
> ima_tpm 1 TINFO: IMA kernel config:
> ima_tpm 1 TINFO: CONFIG_IMA=y
> ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10
> ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y
> ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256"
> ima_tpm 1 TINFO: CONFIG_IMA_WRITE_POLICY=y
> ima_tpm 1 TINFO: CONFIG_IMA_READ_POLICY=y
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y
> ima_tpm 1 TINFO: CONFIG_IMA_ARCH_POLICY=y
> ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y
> ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS=y
> ima_tpm 1 TINFO: CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS=y
> ima_tpm 1 TINFO: CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT=y
> ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.6.0-rc3+.signed root=UUID=119f1a79-c391-4e37-905d-3a503284cadb ro quiet splash ima-policy=tcb
> ima_tpm 1 TINFO: verify boot aggregate
> ima_tpm 1 TINFO: used algorithm: sha256
> ima_tpm 1 TINFO: IMA boot aggregate: 'b2341e4ccea25be7fa750830fb5fdf4bef1c44a4'
> ima_tpm 1 TFAIL: bios boot aggregate does not match IMA boot aggregate (3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5b)
> ima_tpm 2 TINFO: verify PCR values
> ima_tpm 2 TINFO: evmctl version: evmctl 1.2
> ima_tpm 2 TCONF: TPM Hardware Support not enabled in kernel or no TPM chip found
> ima_tpm 3 TINFO: AppArmor enabled, this may affect test results
> ima_tpm 3 TINFO: it can be disabled with TST_DISABLE_APPARMOR=1 (requires super/root)
> ima_tpm 3 TINFO: loaded AppArmor profiles: none
> Summary:
> passed 0
> failed 1
> skipped 1
> warnings 0
BTW my results on custom kernel:
ima_tpm 1 TINFO: timeout per run is 0h 5m 0s
ima_tpm 1 TINFO: IMA kernel config:
ima_tpm 1 TINFO: CONFIG_IMA=y
ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10
ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y
ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y
ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y
ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256"
ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y
ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_BOOTPARAM=y
ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_MODSIG=y
ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y
ima_tpm 1 TINFO: CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY=y
ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.3.18-20-default root=/dev/mapper/system-root crashkernel=121M,high crashkernel=72M,low isofrom=/dev/disk/by-uuid/3271-1AD6:/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso isofrom_device=/dev/disk/by-uuid/3271-1AD6 isofrom_system=/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso loader=syslinux quiet resume=/dev/system/swap splash=silent quiet showopts
ima_tpm 1 TINFO: IMA kernel config:
ima_tpm 1 TINFO: CONFIG_IMA=y
ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10
ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y
ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y
ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y
ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256"
ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y
ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_BOOTPARAM=y
ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_MODSIG=y
ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y
ima_tpm 1 TINFO: CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY=y
ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.3.18-20-default root=/dev/mapper/system-root crashkernel=121M,high crashkernel=72M,low isofrom=/dev/disk/by-uuid/3271-1AD6:/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso isofrom_device=/dev/disk/by-uuid/3271-1AD6 isofrom_system=/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso loader=syslinux quiet resume=/dev/system/swap splash=silent quiet showopts
ima_tpm 1 TINFO: verify boot aggregate
ima_tpm 1 TINFO: used algorithm: sha1
ima_tpm 1 TINFO: IMA boot aggregate: '1172f0990296510ed39403b4f1de83c82e093aae'
ima_tpm 1 TPASS: bios boot aggregate matches IMA boot aggregate (1172f0990296510ed39403b4f1de83c82e093aae)
ima_tpm 2 TINFO: verify PCR values
ima_tpm 2 TINFO: evmctl version: evmctl 1.2.1
ima_tpm 2 TINFO: new PCRS path, evmctl >= 1.1 required
ima_tpm 2 TINFO: verify PCR (Process Control Register)
ima_tpm 2 TPASS: aggregate PCR value matches real PCR value
Summary:
passed 2
failed 0
skipped 0
warnings 0
> # head -1 /sys/kernel/security/ima/ascii_runtime_measurements
> 10 a3132d2501128ff527171658d40d8deb61e2292b ima-ng
> sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5
> b boot_aggregate
mine:
10 c125a1d3684a9737f20f6c1bc880782fae60fb28 ima-ng sha1:1172f0990296510ed39403b4f1de83c82e093aae boot_aggregate
> The ima-evm-utils next-testing branch has code to calculate the
> boot_aggregate based on multiple banks.
I see, 696bf0b ("ima-evm-utils: calculate the digests for multiple TPM banks")
I wonder whether it's reasonable trying to port that to ima_boot_aggregate.c or
just depend on evmctl. External dependencies are sometimes complicated, but for
IMA I incline to just require evmctl.
> # evmctl ima_boot_aggregate
> sha1:4cf3d105b1a1a41b951cc6431f0801c01fe50b24
> sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5b
Thus obviously evmctl (from next-testing) also gets only sha1
./src/evmctl ima_boot_aggregate
sha1:1172f0990296510ed39403b4f1de83c82e093aae
> There's also a new test to verify the boot_aggregate.
> $ VERBOSE=1 make check TESTS=boog_aggregate.test
BTW I got some errors
...
make check-TESTS
make[2]: Entering directory '/home/foo/ima-evm-utils/tests'
make[3]: Entering directory '/home/foo/ima-evm-utils/tests'
make[4]: Entering directory '/home/foo/ima-evm-utils/tests'
make[4]: Nothing to be done for 'boog_aggregate.log'.
make[4]: Leaving directory '/home/foo/ima-evm-utils/tests'
fatal: making test-suite.log: failed to create boog_aggregate.trs
fatal: making test-suite.log: failed to create boog_aggregate.log
make[3]: *** [Makefile:516: test-suite.log] Error 1
make[3]: Leaving directory '/home/foo/ima-evm-utils/tests'
make[2]: *** [Makefile:625: check-TESTS] Error 2
make[2]: Leaving directory '/home/foo/ima-evm-utils/tests'
make[1]: *** [Makefile:692: check-am] Error 2
make[1]: Leaving directory '/home/foo/ima-evm-utils/tests'
make: *** [Makefile:514: check-recursive] Error 1
> Both need some review and testing before being released.
Any estimation when code is released?
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-05-28 14:07 ` Petr Vorel
0 siblings, 0 replies; 38+ messages in thread
From: Petr Vorel @ 2020-05-28 14:07 UTC (permalink / raw)
To: ltp
Hi Mimi,
thanks a lot for testing!
> On Wed, 2020-05-27 at 09:14 +0200, Petr Vorel wrote:
> > Fixes test for kernel commit: 6f1a1d103b48 ima: ("Switch to
> > ima_hash_algo for boot aggregate") from current linux-integrity tree.
> > Tests was failing, because it expect SHA1 hash, but for TPM 2.0 is
> > now used IMA default hash algorithm (by default default SHA256).
> > This is similar for entries in IMA measurement list so we can reuse
> > already existing code.
> > Signed-off-by: Petr Vorel <pvorel@suse.cz>
> > ---
> > changes v1->v2:
> > * removing global variables from get_algorithm_digest (hopefully it's
> > less ugly)
> > Tested only on VM. Can anybody test it on real HW?
> With just this change, the ima_tpm.sh test is failing. ?I assume it is
> failing because it is reading the SHA1 TPM bank, not the SHA256 bank
> to calculate the boot_aggregate hash.
First question: is it correct to take sha256? Because on my test below it's
reading sha1, because that's the content of /sys/kernel/security/ima/ascii_runtime_measurements
I thought just kernel commit: 6f1a1d103b48 ima: ("Switch to ima_hash_algo for
boot aggregate") from current linux-integrity tree is needed, but I tested it on
b59fda449cf0 ("ima: Set again build_ima_appraise variable") (i.e. having all
Robeto's ima patches, missing just last 2 commits from next-integrity head).
What is needed to get your setup?
We both have CONFIG_IMA_DEFAULT_HASH_SHA256=y and CONFIG_IMA_DEFAULT_HASH="sha256".
> ima_tpm 1 TINFO: timeout per run is 0h 5m 0s
> ima_tpm 1 TINFO: IMA kernel config:
> ima_tpm 1 TINFO: CONFIG_IMA=y
> ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10
> ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y
> ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256"
> ima_tpm 1 TINFO: CONFIG_IMA_WRITE_POLICY=y
> ima_tpm 1 TINFO: CONFIG_IMA_READ_POLICY=y
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y
> ima_tpm 1 TINFO: CONFIG_IMA_ARCH_POLICY=y
> ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y
> ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS=y
> ima_tpm 1 TINFO: CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS=y
> ima_tpm 1 TINFO: CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT=y
> ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.6.0-rc3+.signed root=UUID=119f1a79-c391-4e37-905d-3a503284cadb ro quiet splash ima-policy=tcb
> ima_tpm 1 TINFO: verify boot aggregate
> ima_tpm 1 TINFO: used algorithm: sha256
> ima_tpm 1 TINFO: IMA boot aggregate: 'b2341e4ccea25be7fa750830fb5fdf4bef1c44a4'
> ima_tpm 1 TFAIL: bios boot aggregate does not match IMA boot aggregate (3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5b)
> ima_tpm 2 TINFO: verify PCR values
> ima_tpm 2 TINFO: evmctl version: evmctl 1.2
> ima_tpm 2 TCONF: TPM Hardware Support not enabled in kernel or no TPM chip found
> ima_tpm 3 TINFO: AppArmor enabled, this may affect test results
> ima_tpm 3 TINFO: it can be disabled with TST_DISABLE_APPARMOR=1 (requires super/root)
> ima_tpm 3 TINFO: loaded AppArmor profiles: none
> Summary:
> passed 0
> failed 1
> skipped 1
> warnings 0
BTW my results on custom kernel:
ima_tpm 1 TINFO: timeout per run is 0h 5m 0s
ima_tpm 1 TINFO: IMA kernel config:
ima_tpm 1 TINFO: CONFIG_IMA=y
ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10
ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y
ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y
ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y
ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256"
ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y
ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_BOOTPARAM=y
ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_MODSIG=y
ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y
ima_tpm 1 TINFO: CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY=y
ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.3.18-20-default root=/dev/mapper/system-root crashkernel=121M,high crashkernel=72M,low isofrom=/dev/disk/by-uuid/3271-1AD6:/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso isofrom_device=/dev/disk/by-uuid/3271-1AD6 isofrom_system=/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso loader=syslinux quiet resume=/dev/system/swap splash=silent quiet showopts
ima_tpm 1 TINFO: IMA kernel config:
ima_tpm 1 TINFO: CONFIG_IMA=y
ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10
ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y
ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y
ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y
ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256"
ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y
ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_BOOTPARAM=y
ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_MODSIG=y
ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y
ima_tpm 1 TINFO: CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY=y
ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.3.18-20-default root=/dev/mapper/system-root crashkernel=121M,high crashkernel=72M,low isofrom=/dev/disk/by-uuid/3271-1AD6:/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso isofrom_device=/dev/disk/by-uuid/3271-1AD6 isofrom_system=/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso loader=syslinux quiet resume=/dev/system/swap splash=silent quiet showopts
ima_tpm 1 TINFO: verify boot aggregate
ima_tpm 1 TINFO: used algorithm: sha1
ima_tpm 1 TINFO: IMA boot aggregate: '1172f0990296510ed39403b4f1de83c82e093aae'
ima_tpm 1 TPASS: bios boot aggregate matches IMA boot aggregate (1172f0990296510ed39403b4f1de83c82e093aae)
ima_tpm 2 TINFO: verify PCR values
ima_tpm 2 TINFO: evmctl version: evmctl 1.2.1
ima_tpm 2 TINFO: new PCRS path, evmctl >= 1.1 required
ima_tpm 2 TINFO: verify PCR (Process Control Register)
ima_tpm 2 TPASS: aggregate PCR value matches real PCR value
Summary:
passed 2
failed 0
skipped 0
warnings 0
> # head -1 /sys/kernel/security/ima/ascii_runtime_measurements
> 10 a3132d2501128ff527171658d40d8deb61e2292b ima-ng
> sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5
> b boot_aggregate
mine:
10 c125a1d3684a9737f20f6c1bc880782fae60fb28 ima-ng sha1:1172f0990296510ed39403b4f1de83c82e093aae boot_aggregate
> The ima-evm-utils next-testing branch has code to calculate the
> boot_aggregate based on multiple banks.
I see, 696bf0b ("ima-evm-utils: calculate the digests for multiple TPM banks")
I wonder whether it's reasonable trying to port that to ima_boot_aggregate.c or
just depend on evmctl. External dependencies are sometimes complicated, but for
IMA I incline to just require evmctl.
> # evmctl ima_boot_aggregate
> sha1:4cf3d105b1a1a41b951cc6431f0801c01fe50b24
> sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5b
Thus obviously evmctl (from next-testing) also gets only sha1
./src/evmctl ima_boot_aggregate
sha1:1172f0990296510ed39403b4f1de83c82e093aae
> There's also a new test to verify the boot_aggregate.
> $ VERBOSE=1 make check TESTS=boog_aggregate.test
BTW I got some errors
...
make check-TESTS
make[2]: Entering directory '/home/foo/ima-evm-utils/tests'
make[3]: Entering directory '/home/foo/ima-evm-utils/tests'
make[4]: Entering directory '/home/foo/ima-evm-utils/tests'
make[4]: Nothing to be done for 'boog_aggregate.log'.
make[4]: Leaving directory '/home/foo/ima-evm-utils/tests'
fatal: making test-suite.log: failed to create boog_aggregate.trs
fatal: making test-suite.log: failed to create boog_aggregate.log
make[3]: *** [Makefile:516: test-suite.log] Error 1
make[3]: Leaving directory '/home/foo/ima-evm-utils/tests'
make[2]: *** [Makefile:625: check-TESTS] Error 2
make[2]: Leaving directory '/home/foo/ima-evm-utils/tests'
make[1]: *** [Makefile:692: check-am] Error 2
make[1]: Leaving directory '/home/foo/ima-evm-utils/tests'
make: *** [Makefile:514: check-recursive] Error 1
> Both need some review and testing before being released.
Any estimation when code is released?
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-05-28 14:07 ` [LTP] " Petr Vorel
@ 2020-05-28 15:19 ` Mimi Zohar
-1 siblings, 0 replies; 38+ messages in thread
From: Mimi Zohar @ 2020-05-28 15:19 UTC (permalink / raw)
To: Petr Vorel
Cc: ltp, Mimi Zohar, Petr Cervinka, Cyril Hrubis, linux-integrity,
Vitaly Chikunov
On Thu, 2020-05-28 at 16:07 +0200, Petr Vorel wrote:
> Hi Mimi,
>
> thanks a lot for testing!
>
> > On Wed, 2020-05-27 at 09:14 +0200, Petr Vorel wrote:
> > > Fixes test for kernel commit: 6f1a1d103b48 ima: ("Switch to
> > > ima_hash_algo for boot aggregate") from current linux-integrity tree.
>
> > > Tests was failing, because it expect SHA1 hash, but for TPM 2.0 is
> > > now used IMA default hash algorithm (by default default SHA256).
> > > This is similar for entries in IMA measurement list so we can reuse
> > > already existing code.
>
> > > Signed-off-by: Petr Vorel <pvorel@suse.cz>
> > > ---
> > > changes v1->v2:
> > > * removing global variables from get_algorithm_digest (hopefully it's
> > > less ugly)
>
> > > Tested only on VM. Can anybody test it on real HW?
>
> > With just this change, the ima_tpm.sh test is failing. I assume it is
> > failing because it is reading the SHA1 TPM bank, not the SHA256 bank
> > to calculate the boot_aggregate hash.
> First question: is it correct to take sha256? Because on my test below it's
> reading sha1, because that's the content of /sys/kernel/security/ima/ascii_runtime_measurements
>
> I thought just kernel commit: 6f1a1d103b48 ima: ("Switch to ima_hash_algo for
> boot aggregate") from current linux-integrity tree is needed, but I tested it on
> b59fda449cf0 ("ima: Set again build_ima_appraise variable") (i.e. having all
> Robeto's ima patches, missing just last 2 commits from next-integrity head).
> What is needed to get your setup?
This isn't a configuration problem, but an issue of reading PCRs and
calculating the TPM bank appropriate boot_aggregate. If you're
calculating a sha256 boot_aggregate, then the test needs to read and
calculate the boot_aggregate by reading the SHA256 TPM bank.
> We both have CONFIG_IMA_DEFAULT_HASH_SHA256=y and CONFIG_IMA_DEFAULT_HASH="sha256".
>
> > ima_tpm 1 TINFO: timeout per run is 0h 5m 0s
> > ima_tpm 1 TINFO: IMA kernel config:
> > ima_tpm 1 TINFO: CONFIG_IMA=y
> > ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10
> > ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y
> > ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y
> > ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
> > ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y
> > ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256"
> > ima_tpm 1 TINFO: CONFIG_IMA_WRITE_POLICY=y
> > ima_tpm 1 TINFO: CONFIG_IMA_READ_POLICY=y
> > ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y
> > ima_tpm 1 TINFO: CONFIG_IMA_ARCH_POLICY=y
> > ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y
> > ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS=y
> > ima_tpm 1 TINFO: CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS=y
> > ima_tpm 1 TINFO: CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT=y
> > ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.6.0-rc3+.signed root=UUID=119f1a79-c391-4e37-905d-3a503284cadb ro quiet splash ima-policy=tcb
> > ima_tpm 1 TINFO: verify boot aggregate
> > ima_tpm 1 TINFO: used algorithm: sha256
> > ima_tpm 1 TINFO: IMA boot aggregate: 'b2341e4ccea25be7fa750830fb5fdf4bef1c44a4'
> > ima_tpm 1 TFAIL: bios boot aggregate does not match IMA boot aggregate (3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5b)
> > ima_tpm 2 TINFO: verify PCR values
> > ima_tpm 2 TINFO: evmctl version: evmctl 1.2
> > ima_tpm 2 TCONF: TPM Hardware Support not enabled in kernel or no TPM chip found
> > ima_tpm 3 TINFO: AppArmor enabled, this may affect test results
> > ima_tpm 3 TINFO: it can be disabled with TST_DISABLE_APPARMOR=1 (requires super/root)
> > ima_tpm 3 TINFO: loaded AppArmor profiles: none
>
> > Summary:
> > passed 0
> > failed 1
> > skipped 1
> > warnings 0
>
>
> BTW my results on custom kernel:
> ima_tpm 1 TINFO: timeout per run is 0h 5m 0s
> ima_tpm 1 TINFO: IMA kernel config:
> ima_tpm 1 TINFO: CONFIG_IMA=y
> ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10
> ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y
> ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256"
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_BOOTPARAM=y
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_MODSIG=y
> ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y
> ima_tpm 1 TINFO: CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY=y
> ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.3.18-20-default root=/dev/mapper/system-root crashkernel=121M,high crashkernel=72M,low isofrom=/dev/disk/by-uuid/3271-1AD6:/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso isofrom_device=/dev/disk/by-uuid/3271-1AD6 isofrom_system=/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso loader=syslinux quiet resume=/dev/system/swap splash=silent quiet showopts
> ima_tpm 1 TINFO: IMA kernel config:
> ima_tpm 1 TINFO: CONFIG_IMA=y
> ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10
> ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y
> ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256"
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_BOOTPARAM=y
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_MODSIG=y
> ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y
> ima_tpm 1 TINFO: CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY=y
> ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.3.18-20-default root=/dev/mapper/system-root crashkernel=121M,high crashkernel=72M,low isofrom=/dev/disk/by-uuid/3271-1AD6:/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso isofrom_device=/dev/disk/by-uuid/3271-1AD6 isofrom_system=/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso loader=syslinux quiet resume=/dev/system/swap splash=silent quiet showopts
> ima_tpm 1 TINFO: verify boot aggregate
> ima_tpm 1 TINFO: used algorithm: sha1
> ima_tpm 1 TINFO: IMA boot aggregate: '1172f0990296510ed39403b4f1de83c82e093aae'
> ima_tpm 1 TPASS: bios boot aggregate matches IMA boot aggregate (1172f0990296510ed39403b4f1de83c82e093aae)
> ima_tpm 2 TINFO: verify PCR values
> ima_tpm 2 TINFO: evmctl version: evmctl 1.2.1
> ima_tpm 2 TINFO: new PCRS path, evmctl >= 1.1 required
> ima_tpm 2 TINFO: verify PCR (Process Control Register)
> ima_tpm 2 TPASS: aggregate PCR value matches real PCR value
>
> Summary:
> passed 2
> failed 0
> skipped 0
> warnings 0
>
>
> > # head -1 /sys/kernel/security/ima/ascii_runtime_measurements
>
> > 10 a3132d2501128ff527171658d40d8deb61e2292b ima-ng
> > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5
> > b boot_aggregate
>
> mine:
> 10 c125a1d3684a9737f20f6c1bc880782fae60fb28 ima-ng sha1:1172f0990296510ed39403b4f1de83c82e093aae boot_aggregate
>
> > The ima-evm-utils next-testing branch has code to calculate the
> > boot_aggregate based on multiple banks.
> I see, 696bf0b ("ima-evm-utils: calculate the digests for multiple TPM banks")
> I wonder whether it's reasonable trying to port that to ima_boot_aggregate.c or
> just depend on evmctl. External dependencies are sometimes complicated, but for
> IMA I incline to just require evmctl.
Unlike TPM 1.2, the TPM 2.0 device driver doesn't export the TPM PCRs.
Not only would you have a dependency on ima-evm-utils, but also on a
userspace application(s) for reading the TPM PCRs. That dependency
exists whether you're using evmctl to calculate the boot_aggregate or
doing it yourself.
>
> > # evmctl ima_boot_aggregate
>
> > sha1:4cf3d105b1a1a41b951cc6431f0801c01fe50b24
> > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5b
>
> Thus obviously evmctl (from next-testing) also gets only sha1
> ./src/evmctl ima_boot_aggregate
> sha1:1172f0990296510ed39403b4f1de83c82e093aae
>
> > There's also a new test to verify the boot_aggregate.
>
> > $ VERBOSE=1 make check TESTS=boog_aggregate.test
> BTW I got some errors
> ...
> make check-TESTS
> make[2]: Entering directory '/home/foo/ima-evm-utils/tests'
> make[3]: Entering directory '/home/foo/ima-evm-utils/tests'
> make[4]: Entering directory '/home/foo/ima-evm-utils/tests'
> make[4]: Nothing to be done for 'boog_aggregate.log'.
> make[4]: Leaving directory '/home/foo/ima-evm-utils/tests'
> fatal: making test-suite.log: failed to create boog_aggregate.trs
> fatal: making test-suite.log: failed to create boog_aggregate.log
> make[3]: *** [Makefile:516: test-suite.log] Error 1
> make[3]: Leaving directory '/home/foo/ima-evm-utils/tests'
> make[2]: *** [Makefile:625: check-TESTS] Error 2
> make[2]: Leaving directory '/home/foo/ima-evm-utils/tests'
> make[1]: *** [Makefile:692: check-am] Error 2
> make[1]: Leaving directory '/home/foo/ima-evm-utils/tests'
> make: *** [Makefile:514: check-recursive] Error 1
[Cc'ing Vitaly]
The boot_aggregate.trs and boot_aggregate.log files are being created
in the tests/ directory. Is that directory read-only?
>
> > Both need some review and testing before being released.
> Any estimation when code is released?
Probably not before the next open window, but definitely before it is
released.
Mimi
^ permalink raw reply [flat|nested] 38+ messages in thread
* [LTP] [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
@ 2020-05-28 15:19 ` Mimi Zohar
0 siblings, 0 replies; 38+ messages in thread
From: Mimi Zohar @ 2020-05-28 15:19 UTC (permalink / raw)
To: ltp
On Thu, 2020-05-28 at 16:07 +0200, Petr Vorel wrote:
> Hi Mimi,
>
> thanks a lot for testing!
>
> > On Wed, 2020-05-27 at 09:14 +0200, Petr Vorel wrote:
> > > Fixes test for kernel commit: 6f1a1d103b48 ima: ("Switch to
> > > ima_hash_algo for boot aggregate") from current linux-integrity tree.
>
> > > Tests was failing, because it expect SHA1 hash, but for TPM 2.0 is
> > > now used IMA default hash algorithm (by default default SHA256).
> > > This is similar for entries in IMA measurement list so we can reuse
> > > already existing code.
>
> > > Signed-off-by: Petr Vorel <pvorel@suse.cz>
> > > ---
> > > changes v1->v2:
> > > * removing global variables from get_algorithm_digest (hopefully it's
> > > less ugly)
>
> > > Tested only on VM. Can anybody test it on real HW?
>
> > With just this change, the ima_tpm.sh test is failing. ?I assume it is
> > failing because it is reading the SHA1 TPM bank, not the SHA256 bank
> > to calculate the boot_aggregate hash.
> First question: is it correct to take sha256? Because on my test below it's
> reading sha1, because that's the content of /sys/kernel/security/ima/ascii_runtime_measurements
>
> I thought just kernel commit: 6f1a1d103b48 ima: ("Switch to ima_hash_algo for
> boot aggregate") from current linux-integrity tree is needed, but I tested it on
> b59fda449cf0 ("ima: Set again build_ima_appraise variable") (i.e. having all
> Robeto's ima patches, missing just last 2 commits from next-integrity head).
> What is needed to get your setup?
This isn't a configuration problem, but an issue of reading PCRs and
calculating the TPM bank appropriate boot_aggregate. ?If you're
calculating a sha256 boot_aggregate, then the test needs to read and
calculate the boot_aggregate by reading the SHA256 TPM bank.
> We both have CONFIG_IMA_DEFAULT_HASH_SHA256=y and CONFIG_IMA_DEFAULT_HASH="sha256".
>
> > ima_tpm 1 TINFO: timeout per run is 0h 5m 0s
> > ima_tpm 1 TINFO: IMA kernel config:
> > ima_tpm 1 TINFO: CONFIG_IMA=y
> > ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10
> > ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y
> > ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y
> > ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
> > ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y
> > ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256"
> > ima_tpm 1 TINFO: CONFIG_IMA_WRITE_POLICY=y
> > ima_tpm 1 TINFO: CONFIG_IMA_READ_POLICY=y
> > ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y
> > ima_tpm 1 TINFO: CONFIG_IMA_ARCH_POLICY=y
> > ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y
> > ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS=y
> > ima_tpm 1 TINFO: CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS=y
> > ima_tpm 1 TINFO: CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT=y
> > ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.6.0-rc3+.signed root=UUID=119f1a79-c391-4e37-905d-3a503284cadb ro quiet splash ima-policy=tcb
> > ima_tpm 1 TINFO: verify boot aggregate
> > ima_tpm 1 TINFO: used algorithm: sha256
> > ima_tpm 1 TINFO: IMA boot aggregate: 'b2341e4ccea25be7fa750830fb5fdf4bef1c44a4'
> > ima_tpm 1 TFAIL: bios boot aggregate does not match IMA boot aggregate (3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5b)
> > ima_tpm 2 TINFO: verify PCR values
> > ima_tpm 2 TINFO: evmctl version: evmctl 1.2
> > ima_tpm 2 TCONF: TPM Hardware Support not enabled in kernel or no TPM chip found
> > ima_tpm 3 TINFO: AppArmor enabled, this may affect test results
> > ima_tpm 3 TINFO: it can be disabled with TST_DISABLE_APPARMOR=1 (requires super/root)
> > ima_tpm 3 TINFO: loaded AppArmor profiles: none
>
> > Summary:
> > passed 0
> > failed 1
> > skipped 1
> > warnings 0
>
>
> BTW my results on custom kernel:
> ima_tpm 1 TINFO: timeout per run is 0h 5m 0s
> ima_tpm 1 TINFO: IMA kernel config:
> ima_tpm 1 TINFO: CONFIG_IMA=y
> ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10
> ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y
> ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256"
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_BOOTPARAM=y
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_MODSIG=y
> ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y
> ima_tpm 1 TINFO: CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY=y
> ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.3.18-20-default root=/dev/mapper/system-root crashkernel=121M,high crashkernel=72M,low isofrom=/dev/disk/by-uuid/3271-1AD6:/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso isofrom_device=/dev/disk/by-uuid/3271-1AD6 isofrom_system=/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso loader=syslinux quiet resume=/dev/system/swap splash=silent quiet showopts
> ima_tpm 1 TINFO: IMA kernel config:
> ima_tpm 1 TINFO: CONFIG_IMA=y
> ima_tpm 1 TINFO: CONFIG_IMA_MEASURE_PCR_IDX=10
> ima_tpm 1 TINFO: CONFIG_IMA_LSM_RULES=y
> ima_tpm 1 TINFO: CONFIG_IMA_NG_TEMPLATE=y
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH_SHA256=y
> ima_tpm 1 TINFO: CONFIG_IMA_DEFAULT_HASH="sha256"
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE=y
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_BOOTPARAM=y
> ima_tpm 1 TINFO: CONFIG_IMA_APPRAISE_MODSIG=y
> ima_tpm 1 TINFO: CONFIG_IMA_TRUSTED_KEYRING=y
> ima_tpm 1 TINFO: CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY=y
> ima_tpm 1 TINFO: /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.3.18-20-default root=/dev/mapper/system-root crashkernel=121M,high crashkernel=72M,low isofrom=/dev/disk/by-uuid/3271-1AD6:/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso isofrom_device=/dev/disk/by-uuid/3271-1AD6 isofrom_system=/openSUSE-Tumbleweed-NET-x86_64-Snapshot20161222-Media.iso loader=syslinux quiet resume=/dev/system/swap splash=silent quiet showopts
> ima_tpm 1 TINFO: verify boot aggregate
> ima_tpm 1 TINFO: used algorithm: sha1
> ima_tpm 1 TINFO: IMA boot aggregate: '1172f0990296510ed39403b4f1de83c82e093aae'
> ima_tpm 1 TPASS: bios boot aggregate matches IMA boot aggregate (1172f0990296510ed39403b4f1de83c82e093aae)
> ima_tpm 2 TINFO: verify PCR values
> ima_tpm 2 TINFO: evmctl version: evmctl 1.2.1
> ima_tpm 2 TINFO: new PCRS path, evmctl >= 1.1 required
> ima_tpm 2 TINFO: verify PCR (Process Control Register)
> ima_tpm 2 TPASS: aggregate PCR value matches real PCR value
>
> Summary:
> passed 2
> failed 0
> skipped 0
> warnings 0
>
>
> > # head -1 /sys/kernel/security/ima/ascii_runtime_measurements
>
> > 10 a3132d2501128ff527171658d40d8deb61e2292b ima-ng
> > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5
> > b boot_aggregate
>
> mine:
> 10 c125a1d3684a9737f20f6c1bc880782fae60fb28 ima-ng sha1:1172f0990296510ed39403b4f1de83c82e093aae boot_aggregate
>
> > The ima-evm-utils next-testing branch has code to calculate the
> > boot_aggregate based on multiple banks.
> I see, 696bf0b ("ima-evm-utils: calculate the digests for multiple TPM banks")
> I wonder whether it's reasonable trying to port that to ima_boot_aggregate.c or
> just depend on evmctl. External dependencies are sometimes complicated, but for
> IMA I incline to just require evmctl.
Unlike TPM 1.2, the TPM 2.0 device driver doesn't export the TPM PCRs.
?Not only would you have a dependency on ima-evm-utils, but also on a
userspace application(s) for reading the TPM PCRs. ?That dependency
exists whether you're using evmctl to calculate the boot_aggregate or
doing it yourself.
>
> > # evmctl ima_boot_aggregate
>
> > sha1:4cf3d105b1a1a41b951cc6431f0801c01fe50b24
> > sha256:3fd5dc717f886ff7182526efc5edc3abb179a5aac1ab589c8ec888398233ae5b
>
> Thus obviously evmctl (from next-testing) also gets only sha1
> ./src/evmctl ima_boot_aggregate
> sha1:1172f0990296510ed39403b4f1de83c82e093aae
>
> > There's also a new test to verify the boot_aggregate.
>
> > $ VERBOSE=1 make check TESTS=boog_aggregate.test
> BTW I got some errors
> ...
> make check-TESTS
> make[2]: Entering directory '/home/foo/ima-evm-utils/tests'
> make[3]: Entering directory '/home/foo/ima-evm-utils/tests'
> make[4]: Entering directory '/home/foo/ima-evm-utils/tests'
> make[4]: Nothing to be done for 'boog_aggregate.log'.
> make[4]: Leaving directory '/home/foo/ima-evm-utils/tests'
> fatal: making test-suite.log: failed to create boog_aggregate.trs
> fatal: making test-suite.log: failed to create boog_aggregate.log
> make[3]: *** [Makefile:516: test-suite.log] Error 1
> make[3]: Leaving directory '/home/foo/ima-evm-utils/tests'
> make[2]: *** [Makefile:625: check-TESTS] Error 2
> make[2]: Leaving directory '/home/foo/ima-evm-utils/tests'
> make[1]: *** [Makefile:692: check-am] Error 2
> make[1]: Leaving directory '/home/foo/ima-evm-utils/tests'
> make: *** [Makefile:514: check-recursive] Error 1
[Cc'ing Vitaly]
The boot_aggregate.trs and boot_aggregate.log files are being created
in the tests/ directory. ?Is that directory read-only?
?
>
> > Both need some review and testing before being released.
> Any estimation when code is released?
Probably not before the next open window, but definitely before it is
released.
Mimi
^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
2020-05-28 15:19 ` [LTP] " Mimi Zohar
@ 2020-05-28 16:05 ` Petr Vorel
-1 siblings, 0 replies; 38+ messages in thread
From: Petr Vorel @ 2020-05-28 16:05 UTC (permalink / raw)
To: Mimi Zohar
Cc: ltp, Mimi Zohar, Petr Cervinka, Cyril Hrubis, linux-integrity,
Vitaly Chikunov
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.
...
> > > 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.
...
> > > 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.
> > > 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.
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-05-28 16:05 ` Petr Vorel
0 siblings, 0 replies; 38+ messages in thread
From: Petr Vorel @ 2020-05-28 16:05 UTC (permalink / raw)
To: ltp
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.
...
> > > 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.
...
> > > 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.
> > > 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.
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-05-28 16:05 ` [LTP] " Petr Vorel
@ 2020-06-15 19:41 ` Bruno Meneguele
-1 siblings, 0 replies; 38+ messages in thread
From: Bruno Meneguele @ 2020-06-15 19:41 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: 5372 bytes --]
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
[-- 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 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 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: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-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-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-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-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
* [LTP] [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate
@ 2020-06-19 7:46 ` Petr Vorel
0 siblings, 0 replies; 38+ messages in thread
From: Petr Vorel @ 2020-06-19 7:46 UTC (permalink / raw)
To: ltp
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-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-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 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-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
end of thread, other threads:[~2020-06-19 13:04 UTC | newest]
Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-27 7:14 [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate Petr Vorel
2020-05-27 7:14 ` [LTP] " Petr Vorel
2020-05-27 17:41 ` Mimi Zohar
2020-05-27 17:41 ` [LTP] " Mimi Zohar
2020-05-28 14:07 ` Petr Vorel
2020-05-28 14:07 ` [LTP] " Petr Vorel
2020-05-28 15:19 ` Mimi Zohar
2020-05-28 15:19 ` [LTP] " Mimi Zohar
2020-05-28 16:05 ` Petr Vorel
2020-05-28 16:05 ` [LTP] " Petr Vorel
2020-06-15 19:41 ` Bruno Meneguele
2020-06-15 19:41 ` [LTP] " Bruno Meneguele
2020-06-15 20:01 ` Bruno Meneguele
2020-06-15 20:01 ` [LTP] " Bruno Meneguele
2020-06-16 22:40 ` Mimi Zohar
2020-06-16 22:40 ` [LTP] " Mimi Zohar
2020-06-17 19:52 ` Bruno Meneguele
2020-06-17 19:52 ` [LTP] " Bruno Meneguele
2020-06-19 7:46 ` Petr Vorel
2020-06-19 7:46 ` [LTP] " Petr Vorel
2020-06-15 20:21 ` Mimi Zohar
2020-06-15 20:21 ` [LTP] " Mimi Zohar
2020-06-17 1:21 ` Jerry Snitselaar
2020-06-17 1:21 ` [LTP] " Jerry Snitselaar
2020-06-17 20:45 ` Bruno Meneguele
2020-06-17 20:45 ` [LTP] " Bruno Meneguele
2020-06-17 22:19 ` Maurizio Drocco
2020-06-17 22:19 ` [LTP] " Maurizio Drocco
2020-06-19 8:21 ` Petr Vorel
2020-06-19 8:21 ` [LTP] " Petr Vorel
2020-06-19 12:43 ` Mimi Zohar
2020-06-19 12:43 ` [LTP] " Mimi Zohar
2020-06-19 13:01 ` Petr Vorel
2020-06-19 13:01 ` [LTP] " Petr Vorel
2020-06-19 10:07 ` Petr Vorel
2020-06-19 10:07 ` [LTP] " Petr Vorel
2020-06-19 13:01 ` Mimi Zohar
2020-06-19 13:01 ` [LTP] " Mimi Zohar
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.