diff for duplicates of <20200617204500.GB40831@glitch> diff --git a/a/1.txt b/N1/1.txt index 33739f7..ce65b35 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -4,7 +4,7 @@ On Tue, Jun 16, 2020 at 06:21:48PM -0700, Jerry Snitselaar 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 +> > > > > > > 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 @@ -17,7 +17,7 @@ On Tue, Jun 16, 2020 at 06:21:48PM -0700, Jerry Snitselaar wrote: > > > > > > 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 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). @@ -42,7 +42,7 @@ On Tue, Jun 16, 2020 at 06:21:48PM -0700, Jerry Snitselaar wrote: > > > > 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 +> > ?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 @@ -64,8 +64,8 @@ I can try to setup a system with grub2+tpm to get the log with pcr 8 and > > > > > > 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 +> > > > > ?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. @@ -89,7 +89,7 @@ points to the TPM version: TPM2.0 may have PPI version 1.2 or 1.3. > > > 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? +> > That was only upstreamed in linux-v5.6. ?Has it been backported? > > Hmm, well pointed. @@ -100,10 +100,10 @@ Hmm, well pointed. > 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 +> > 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. +> > ?Perhaps piggyback on the pseudo PCR file to test for TPM 1.2. > > > > > > > > > ... @@ -131,14 +131,14 @@ Hmm, well pointed. > > > > > [Cc'ing Vitaly] > > > > > > > > > The boot_aggregate.trs and boot_aggregate.log files are being created -> > > > > in the tests/ directory. Is that directory read-only? +> > > > > 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. +> > Thanks, much appreciated. ?I'm not seeing that here. > > > > Mimi > > @@ -147,3 +147,10 @@ Hmm, well pointed. -- 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> diff --git a/a/2.bin b/a/2.bin deleted file mode 100644 index eba8082..0000000 --- a/a/2.bin +++ /dev/null @@ -1,11 +0,0 @@ ------BEGIN PGP SIGNATURE----- - -iQEzBAEBCAAdFiEEdWo6nTbnZdbDmXutYdRkFR+RokMFAl7qgMsACgkQYdRkFR+R -okPKcgf8D93sgeHMpkPQXsPODX717VzCgg51hXtxg1idbxNJXF08oWMnBgngOG27 -LamgCtep2ogLJz3e2M1Wo2mVDt+1/V/NGe1vaa4RKKwE9aXHZ7C3US7boMIVd9nw -KJnl/37qingvQ65+6oF59SR6Cx8F1imEhsieWMtOly12wVSzB4Vsk6/nWx5haCPh -0YmLk+I6gUXLl6JIIW//OiWW8urEFNtlIPLxNb+OAwbCB4fiX4ZjfFW2RzsizAzn -97qg9eyp+5AKaB00QkvgKLPXcJc3hBuMguvP7Igkr7mpMyPPpo/8anklAL2gj6UJ -XKYC77lt7/6fWRFxpc+veesLz+ko8w== -=vDc6 ------END PGP SIGNATURE----- diff --git a/a/2.hdr b/a/2.hdr deleted file mode 100644 index 5e5352c..0000000 --- a/a/2.hdr +++ /dev/null @@ -1 +0,0 @@ -Content-Type: application/pgp-signature; name="signature.asc" diff --git a/a/content_digest b/N1/content_digest index 59d42ec..fceb106 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -7,19 +7,10 @@ "ref\01592252491.11061.181.camel@linux.ibm.com\0" "ref\020200617012148.hhpvxqov2py7fvvc@cantor\0" "From\0Bruno Meneguele <bmeneg@redhat.com>\0" - "Subject\0Re: [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate\0" + "Subject\0[LTP] [LTP v2 1/1] ima_tpm.sh: Fix for calculating boot aggregate\0" "Date\0Wed, 17 Jun 2020 17:45:00 -0300\0" - "To\0Jerry Snitselaar <jsnitsel@redhat.com>\0" - "Cc\0Mimi Zohar <zohar@linux.ibm.com>" - Petr Vorel <pvorel@suse.cz> - ltp@lists.linux.it - Mimi Zohar <zohar@linux.vnet.ibm.com> - Petr Cervinka <pcervinka@suse.com> - Cyril Hrubis <chrubis@suse.cz> - linux-integrity@vger.kernel.org - Vitaly Chikunov <vt@altlinux.org> - " Maurizio Drocco <maurizio.drocco@ibm.com>\0" - "\01:1\0" + "To\0ltp@lists.linux.it\0" + "\00:1\0" "b\0" "On Tue, Jun 16, 2020 at 06:21:48PM -0700, Jerry Snitselaar wrote:\n" "> On Mon Jun 15 20, Mimi Zohar wrote:\n" @@ -27,7 +18,7 @@ "> > > On Thu, May 28, 2020 at 06:05:27PM +0200, Petr Vorel wrote:\n" "> > > > Hi Mimi,\n" "> > > > ...\n" - "> > > > > > > With just this change, the ima_tpm.sh test is failing. \302\240I assume it is\n" + "> > > > > > > With just this change, the ima_tpm.sh test is failing. ?I assume it is\n" "> > > > > > > failing because it is reading the SHA1 TPM bank, not the SHA256 bank\n" "> > > > > > > to calculate the boot_aggregate hash.\n" "> > > > > > First question: is it correct to take sha256? Because on my test below it's\n" @@ -40,7 +31,7 @@ "> > > > > > What is needed to get your setup?\n" "> > > >\n" "> > > > > This isn't a configuration problem, but an issue of reading PCRs and\n" - "> > > > > calculating the TPM bank appropriate boot_aggregate. \302\240If you're\n" + "> > > > > calculating the TPM bank appropriate boot_aggregate. ?If you're\n" "> > > > > calculating a sha256 boot_aggregate, then the test needs to read and\n" "> > > > > calculate the boot_aggregate by reading the SHA256 TPM bank.\n" "> > > > OK, I tested it on TPM 1.2 (no TPM 2.0 available atm).\n" @@ -65,7 +56,7 @@ "> > \n" "> > As long as we're dealing with the \"boot_aggregate\", Maurizio just\n" "> > posted a kernel patch for including PCR 8 & 9 in the boot_aggregate.\n" - "> > \302\240The existing IMA LTP \"boot_aggregate\" test is going to need to\n" + "> > ?The existing IMA LTP \"boot_aggregate\" test is going to need to\n" "> > support this change.\n" "> > \n" "> > I'd appreciate if someone could send me a TPM event log, the PCRs, and\n" @@ -87,8 +78,8 @@ "> > > > > > IMA I incline to just require evmctl.\n" "> > > >\n" "> > > > > Unlike TPM 1.2, the TPM 2.0 device driver doesn't export the TPM PCRs.\n" - "> > > > > \302\240Not only would you have a dependency on ima-evm-utils, but also on a\n" - "> > > > > userspace application(s) for reading the TPM PCRs. \302\240That dependency\n" + "> > > > > ?Not only would you have a dependency on ima-evm-utils, but also on a\n" + "> > > > > userspace application(s) for reading the TPM PCRs. ?That dependency\n" "> > > > > exists whether you're using evmctl to calculate the boot_aggregate or\n" "> > > > > doing it yourself.\n" "> > > > Hm, things get complicated.\n" @@ -112,7 +103,7 @@ "> > > TCG spec version being implemented by the hw TPM, in a sysfs standard\n" "> > > output.\n" "> > \n" - "> > That was only upstreamed in linux-v5.6. \302\240Has it been backported?\n" + "> > That was only upstreamed in linux-v5.6. ?Has it been backported?\n" "> > \n" "\n" "Hmm, well pointed. \n" @@ -123,10 +114,10 @@ "> have to take a look at it.\n" "> \n" "> > The PCRs are not exported for TPM 2.0, unfortunately, making\n" - "> > regression tests dependent on a userspace app. \302\240The existing LTP\n" + "> > regression tests dependent on a userspace app. ?The existing LTP\n" "> > ima_tpm.sh test looks for the PCRs in either\n" "> > /sys/class/tpm/tpm0/device/pcrs or /sys/class/misc/tpm0/device/pcrs.\n" - "> > \302\240Perhaps piggyback on the pseudo PCR file to test for TPM 1.2.\n" + "> > ?Perhaps piggyback on the pseudo PCR file to test for TPM 1.2.\n" "> > \n" "> > > \n" "> > > > ...\n" @@ -154,14 +145,14 @@ "> > > > > [Cc'ing Vitaly]\n" "> > > >\n" "> > > > > The boot_aggregate.trs and boot_aggregate.log files are being created\n" - "> > > > > in the tests/ directory. \302\240Is that directory read-only?\n" + "> > > > > in the tests/ directory. ?Is that directory read-only?\n" "> > > > Yes, drwxr-xr-x. Testing on fresh clone and issue persists.\n" "> > > >\n" "> > > \n" "> > > Yes, same thing here.. but didn't really check the reason for that. Will\n" "> > > take a time later to see what's happening.\n" "> > \n" - "> > Thanks, much appreciated. \302\240I'm not seeing that here.\n" + "> > Thanks, much appreciated. ?I'm not seeing that here.\n" "> > \n" "> > Mimi\n" "> > \n" @@ -169,20 +160,13 @@ "\n" "-- \n" "bmeneg \n" - PGP Key: http://bmeneg.com/pubkey.txt - "\01:2\0" - "fn\0signature.asc\0" - "b\0" - "-----BEGIN PGP SIGNATURE-----\n" - "\n" - "iQEzBAEBCAAdFiEEdWo6nTbnZdbDmXutYdRkFR+RokMFAl7qgMsACgkQYdRkFR+R\n" - "okPKcgf8D93sgeHMpkPQXsPODX717VzCgg51hXtxg1idbxNJXF08oWMnBgngOG27\n" - "LamgCtep2ogLJz3e2M1Wo2mVDt+1/V/NGe1vaa4RKKwE9aXHZ7C3US7boMIVd9nw\n" - "KJnl/37qingvQ65+6oF59SR6Cx8F1imEhsieWMtOly12wVSzB4Vsk6/nWx5haCPh\n" - "0YmLk+I6gUXLl6JIIW//OiWW8urEFNtlIPLxNb+OAwbCB4fiX4ZjfFW2RzsizAzn\n" - "97qg9eyp+5AKaB00QkvgKLPXcJc3hBuMguvP7Igkr7mpMyPPpo/8anklAL2gj6UJ\n" - "XKYC77lt7/6fWRFxpc+veesLz+ko8w==\n" - "=vDc6\n" - "-----END PGP SIGNATURE-----\n" + "PGP Key: http://bmeneg.com/pubkey.txt\n" + "-------------- next part --------------\n" + "A non-text attachment was scrubbed...\n" + "Name: signature.asc\n" + "Type: application/pgp-signature\n" + "Size: 488 bytes\n" + "Desc: not available\n" + URL: <http://lists.linux.it/pipermail/ltp/attachments/20200617/4dfc485e/attachment-0001.sig> -0c05f12eed8fa6e2c705aeaf109fbc1f13a3e13a5f6bd82001935eb958377e11 +c320df18d56a8f3fcff9e2bf213fa86ca10fb5f1568058e0545868973fe78799
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.