| Message ID | 157617293957.8172.1404790695313599409.stgit@tstruk-mobl1 (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [=v2,1/3] tpm: fix invalid locking in NONBLOCKING mode | expand |
On Thu, 2019-12-12 at 09:48 -0800, Tadeusz Struk wrote: > Unseal with wrong auth or wrong policy test affects DA lockout > and eventually causes the tests to fail with: > "ProtocolError: TPM_RC_LOCKOUT: rc=0x00000921" > when the tests run multiple times. > Send tpm clear command after the test to reset the DA counters. > > Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com> > --- > tools/testing/selftests/tpm2/test_smoke.sh | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/tools/testing/selftests/tpm2/test_smoke.sh > b/tools/testing/selftests/tpm2/test_smoke.sh > index cb54ab637ea6..8155c2ea7ccb 100755 > --- a/tools/testing/selftests/tpm2/test_smoke.sh > +++ b/tools/testing/selftests/tpm2/test_smoke.sh > @@ -3,3 +3,8 @@ > > python -m unittest -v tpm2_tests.SmokeTest > python -m unittest -v tpm2_tests.AsyncTest > + > +CLEAR_CMD=$(which tpm2_clear) > +if [ -n $CLEAR_CMD ]; then > + tpm2_clear -T device > +fi TPM2_Clear reprovisions the SPS ... that would make all currently exported TPM keys go invalid. I know these tests should be connected to a vTPM, so doing this should be safe, but if this accidentally got executed on your laptop all TPM relying functions would be disrupted, which doesn't seem to be the best thing to hard wire into a test. What about doing a TPM2_DictionaryAttackLockReset instead, which is the least invasive route to fixing the problem ... provided you know what the lockout authorization is. James
On 12/12/19 11:51 AM, James Bottomley wrote: > TPM2_Clear reprovisions the SPS ... that would make all currently > exported TPM keys go invalid. I know these tests should be connected > to a vTPM, so doing this should be safe, but if this accidentally got > executed on your laptop all TPM relying functions would be disrupted, > which doesn't seem to be the best thing to hard wire into a test. That is true, but it will need to be executed as root, and root should know what she/he is doing ;) > > What about doing a TPM2_DictionaryAttackLockReset instead, which is the > least invasive route to fixing the problem ... provided you know what > the lockout authorization is. I can change tpm2_clear to tpm2_dictionarylockout -c if we want to make it foolproof. In this case we can assume that the lockout auth is empty.
On Thu, 2019-12-12 at 12:49 -0800, Tadeusz Struk wrote: > On 12/12/19 11:51 AM, James Bottomley wrote: > > TPM2_Clear reprovisions the SPS ... that would make all currently > > exported TPM keys go invalid. I know these tests should be > > connected to a vTPM, so doing this should be safe, but if this > > accidentally got executed on your laptop all TPM relying functions > > would be disrupted, which doesn't seem to be the best thing to hard > > wire into a test. > > That is true, but it will need to be executed as root, and root > should know what she/he is doing ;) Not in the modern kernel resource manager world: anyone who is in the tpm group can access the tpmrm device and we haven't added a dangerous command filter like we promised we would, so unless they have actually set lockout or platform authorization, they'll find they can execute it > > What about doing a TPM2_DictionaryAttackLockReset instead, which is > > the least invasive route to fixing the problem ... provided you > > know what the lockout authorization is. > > I can change tpm2_clear to tpm2_dictionarylockout -c if we want to > make it foolproof. In this case we can assume that the lockout auth > is empty. Well, if it isn't TPM2_Clear would refuse to execute as well since that requires either lockout auth or platform + physical presence. James
On 12/12/19 12:54 PM, James Bottomley wrote: > Not in the modern kernel resource manager world: anyone who is in the > tpm group can access the tpmrm device and we haven't added a dangerous > command filter like we promised we would, so unless they have actually > set lockout or platform authorization, they'll find they can execute it The default for the tpm2_* tools with '-T device' switch is to talk to /dev/tpm0. If one would try to run it, by mistake, it would fail with: $ tpm2_clear -T device ERROR:tcti:src/tss2-tcti/tcti-device.c:439:Tss2_Tcti_Device_Init() Failed to open device file /dev/tpm0: Permission denied To point it to /dev/tpmrm0 it would need to be: $ tpm2_clear -T device:/dev/tpmrm0
On December 12, 2019 4:07:26 PM EST, Tadeusz Struk <tadeusz.struk@intel.com> wrote: >On 12/12/19 12:54 PM, James Bottomley wrote: >> Not in the modern kernel resource manager world: anyone who is in the >> tpm group can access the tpmrm device and we haven't added a >dangerous >> command filter like we promised we would, so unless they have >actually >> set lockout or platform authorization, they'll find they can execute >it > >The default for the tpm2_* tools with '-T device' switch is to talk to >/dev/tpm0. > >If one would try to run it, by mistake, it would fail with: > >$ tpm2_clear -T device >ERROR:tcti:src/tss2-tcti/tcti-device.c:439:Tss2_Tcti_Device_Init() >Failed to open device file /dev/tpm0: Permission denied > >To point it to /dev/tpmrm0 it would need to be: >$ tpm2_clear -T device:/dev/tpmrm0 And most other toolkits talk to the tpmrm device because the tpm 1.2 daemon based architecture didn't work so well. The point is that if tpm2_clear works on your emulator, it likely works on your real tpm, so making the tests safer to run is not unreasonable. James
On Thu, 2019-12-12 at 12:49 -0800, Tadeusz Struk wrote: > I can change tpm2_clear to tpm2_dictionarylockout -c if we want to make > it foolproof. In this case we can assume that the lockout auth is empty. Check that your fix applies cleanly to for-linus-v5.5-rc3 before you send it [*]. I'll amend it then to the appropriate commit. [*] git://git.infradead.org/users/jjs/linux-tpmdd.git /Jarkko
diff --git a/tools/testing/selftests/tpm2/test_smoke.sh b/tools/testing/selftests/tpm2/test_smoke.sh index cb54ab637ea6..8155c2ea7ccb 100755 --- a/tools/testing/selftests/tpm2/test_smoke.sh +++ b/tools/testing/selftests/tpm2/test_smoke.sh @@ -3,3 +3,8 @@ python -m unittest -v tpm2_tests.SmokeTest python -m unittest -v tpm2_tests.AsyncTest + +CLEAR_CMD=$(which tpm2_clear) +if [ -n $CLEAR_CMD ]; then + tpm2_clear -T device +fi
Unseal with wrong auth or wrong policy test affects DA lockout and eventually causes the tests to fail with: "ProtocolError: TPM_RC_LOCKOUT: rc=0x00000921" when the tests run multiple times. Send tpm clear command after the test to reset the DA counters. Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com> --- tools/testing/selftests/tpm2/test_smoke.sh | 5 +++++ 1 file changed, 5 insertions(+)