* tpm device not showing up in /dev anymore
@ 2017-08-28 11:28 Laurent Bigonville
[not found] ` <f9526f55-df96-64fc-a4d6-877ce04e7156-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
0 siblings, 1 reply; 62+ messages in thread
From: Laurent Bigonville @ 2017-08-28 11:28 UTC (permalink / raw)
To: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Hello,
Since the version 4.12 (I also tested with 4.13-rc5) of the kernel, the
tpm device is not showing up in /dev/. In dmesg I can see the following
lines:
> [ 1.772153] tpm_tis 00:06: 1.2 TPM (device-id 0x6871, rev-id 1)
> [ 1.788106] tpm tpm0: tpm_transmit: tpm_send: error -5
> [ 1.788146] tpm tpm0: A TPM error (-5) occurred attempting to
> determine the timeouts
> [ 1.788194] tpm_tis: probe of 00:06 failed with error -5
> [ 1.796865] ima: No TPM chip found, activating TPM-bypass! (rc=-19)
> [ 10.085245] tpm_inf_pnp 00:06: Found TPM with ID IFX0102
If I'm reverting to 4.11, everything is working fine.
An idea how to troubleshoot this?
Regards,
Laurent Bigonville
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
tpmdd-devel mailing list
tpmdd-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
^ permalink raw reply [flat|nested] 62+ messages in thread
[parent not found: <f9526f55-df96-64fc-a4d6-877ce04e7156-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>]
* Re: tpm device not showing up in /dev anymore [not found] ` <f9526f55-df96-64fc-a4d6-877ce04e7156-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> @ 2017-08-29 16:00 ` Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w [not found] ` <dcad0104c46d4d5f88e642862bdb42c2-nFblLGNE8XKJSz+rYg/bSJowlv4uC7bZ@public.gmane.org> 0 siblings, 1 reply; 62+ messages in thread From: Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w @ 2017-08-29 16:00 UTC (permalink / raw) To: bigon-8fiUuRrzOP0dnm+yROfE0A; +Cc: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Hi Laurent, > Since the version 4.12 (I also tested with 4.13-rc5) of the kernel, the tpm > device is not showing up in /dev/. In dmesg I can see the following > lines: Do you know what TPM you are using exactly (model number, firmware version, etc.)? > > [ 1.772153] tpm_tis 00:06: 1.2 TPM (device-id 0x6871, rev-id 1) [ > > 1.788106] tpm tpm0: tpm_transmit: tpm_send: error -5 [ 1.788146] > > tpm tpm0: A TPM error (-5) occurred attempting to determine the > > timeouts [ 1.788194] tpm_tis: probe of 00:06 failed with error -5 [ > > 1.796865] ima: No TPM chip found, activating TPM-bypass! (rc=-19) [ > > 10.085245] tpm_inf_pnp 00:06: Found TPM with ID IFX0102 > > If I'm reverting to 4.11, everything is working fine. Error -5 is EIO, which is as far as I can tell only used in few places (related to expect flag checks) in the tpm_transmit code path that first reports that error. If this is what causes the problem, then it only tells us that the TPM did not understand the command correctly (it received not enough/too much data). I cannot see any obvious changes between 4.11 and 4.12 that might affect the behavior in that region. > An idea how to troubleshoot this? Can you run git bisect on the changes between 4.11 and 4.12, so that we find the offending commit? It is probably sufficient to limit the search to commits that touch something in drivers/char/tpm. Alexander ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ^ permalink raw reply [flat|nested] 62+ messages in thread
[parent not found: <dcad0104c46d4d5f88e642862bdb42c2-nFblLGNE8XKJSz+rYg/bSJowlv4uC7bZ@public.gmane.org>]
* Re: tpm device not showing up in /dev anymore [not found] ` <dcad0104c46d4d5f88e642862bdb42c2-nFblLGNE8XKJSz+rYg/bSJowlv4uC7bZ@public.gmane.org> @ 2017-08-29 16:35 ` Laurent Bigonville [not found] ` <47c4300b-8701-79a6-1c58-3a5853f4c5e3-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> 0 siblings, 1 reply; 62+ messages in thread From: Laurent Bigonville @ 2017-08-29 16:35 UTC (permalink / raw) To: Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w Cc: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Le 29/08/17 à 18:00, Alexander.Steffen@infineon.com a écrit : > Hi Laurent, Hello Alexander, >> Since the version 4.12 (I also tested with 4.13-rc5) of the kernel, the tpm >> device is not showing up in /dev/. In dmesg I can see the following >> lines: > Do you know what TPM you are using exactly (model number, firmware version, etc.)? tpm_version shows: # tpm_version xK�\x13N TPM 1.2 Version Info: Chip Version: 1.2.3.6 Spec Level: 2 Errata Revision: 0 TPM Vendor ID: SNS TPM Version: 01010000 Manufacturer Info: 534e5300 > >>> [ 1.772153] tpm_tis 00:06: 1.2 TPM (device-id 0x6871, rev-id 1) [ >>> 1.788106] tpm tpm0: tpm_transmit: tpm_send: error -5 [ 1.788146] >>> tpm tpm0: A TPM error (-5) occurred attempting to determine the >>> timeouts [ 1.788194] tpm_tis: probe of 00:06 failed with error -5 [ >>> 1.796865] ima: No TPM chip found, activating TPM-bypass! (rc=-19) [ >>> 10.085245] tpm_inf_pnp 00:06: Found TPM with ID IFX0102 >> If I'm reverting to 4.11, everything is working fine. > Error -5 is EIO, which is as far as I can tell only used in few places (related to expect flag checks) in the tpm_transmit code path that first reports that error. If this is what causes the problem, then it only tells us that the TPM did not understand the command correctly (it received not enough/too much data). I cannot see any obvious changes between 4.11 and 4.12 that might affect the behavior in that region. > >> An idea how to troubleshoot this? > Can you run git bisect on the changes between 4.11 and 4.12, so that we find the offending commit? It is probably sufficient to limit the search to commits that touch something in drivers/char/tpm. I'll try and keep you posted. Thanks for your answer. Laurent Bigonville > > Alexander ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ tpmdd-devel mailing list tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel ^ permalink raw reply [flat|nested] 62+ messages in thread
[parent not found: <47c4300b-8701-79a6-1c58-3a5853f4c5e3-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>]
* Re: tpm device not showing up in /dev anymore [not found] ` <47c4300b-8701-79a6-1c58-3a5853f4c5e3-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> @ 2017-08-29 17:39 ` Peter Huewe 2017-08-29 18:55 ` Laurent Bigonville 1 sibling, 0 replies; 62+ messages in thread From: Peter Huewe @ 2017-08-29 17:39 UTC (permalink / raw) To: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Laurent Bigonville, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w Hi Am 29. August 2017 18:35:26 MESZ schrieb Laurent Bigonville <bigon@debian.org>: >Le 29/08/17 à 18:00, Alexander.Steffen@infineon.com a écrit : >> Hi Laurent, > >Hello Alexander, > >>> Since the version 4.12 (I also tested with 4.13-rc5) of the kernel, >the tpm >>> device is not showing up in /dev/. In dmesg I can see the following >>> lines: >> Do you know what TPM you are using exactly (model number, firmware >version, etc.)? >tpm_version shows: > ># tpm_version >xK�\x13N TPM 1.2 Version Info: > Chip Version: 1.2.3.6 > Spec Level: 2 > Errata Revision: 0 > TPM Vendor ID: SNS > TPM Version: 01010000 > Manufacturer Info: 534e5300 > > >> >>>> [ 1.772153] tpm_tis 00:06: 1.2 TPM (device-id 0x6871, rev-id 1) >[ >>>> 1.788106] tpm tpm0: tpm_transmit: tpm_send: error -5 [ 1.788146] >>>> tpm tpm0: A TPM error (-5) occurred attempting to determine the >>>> timeouts [ 1.788194] tpm_tis: probe of 00:06 failed with error >-5 [ >>>> 1.796865] ima: No TPM chip found, activating TPM-bypass! (rc=-19) [ >>>> 10.085245] tpm_inf_pnp 00:06: Found TPM with ID IFX0102 >>> If I'm reverting to 4.11, everything is working fine. >> Error -5 is EIO, which is as far as I can tell only used in few >places (related to expect flag checks) in the tpm_transmit code path >that first reports that error. If this is what causes the problem, then >it only tells us that the TPM did not understand the command correctly >(it received not enough/too much data). I cannot see any obvious >changes between 4.11 and 4.12 that might affect the behavior in that >region. >> >>> An idea how to troubleshoot this? >> Can you run git bisect on the changes between 4.11 and 4.12, so that >we find the offending commit? It is probably sufficient to limit the >search to commits that touch something in drivers/char/tpm. > >I'll try and keep you posted. > >Thanks for your answer. Can you also maybe post the dmesg output on 4.11 for reference? Peter > >Laurent Bigonville > >> >> Alexander > > >------------------------------------------------------------------------------ >Check out the vibrant tech community on one of the world's most >engaging tech sites, Slashdot.org! http://sdm.link/slashdot >_______________________________________________ >tpmdd-devel mailing list >tpmdd-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/tpmdd-devel -- Sent from my mobile ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ tpmdd-devel mailing list tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: tpm device not showing up in /dev anymore [not found] ` <47c4300b-8701-79a6-1c58-3a5853f4c5e3-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> 2017-08-29 17:39 ` Peter Huewe @ 2017-08-29 18:55 ` Laurent Bigonville [not found] ` <595efb25-8d87-f39d-037f-9c9a98462339-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> 1 sibling, 1 reply; 62+ messages in thread From: Laurent Bigonville @ 2017-08-29 18:55 UTC (permalink / raw) To: Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w Cc: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Le 29/08/17 à 18:35, Laurent Bigonville a écrit : > Le 29/08/17 à 18:00, Alexander.Steffen@infineon.com a écrit : >>> An idea how to troubleshoot this? >> Can you run git bisect on the changes between 4.11 and 4.12, so that >> we find the offending commit? It is probably sufficient to limit the >> search to commits that touch something in drivers/char/tpm. > > I'll try and keep you posted. OK I've been able to bisect the problem and the bad commit is: e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad commit commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 Author: Jerry Snitselaar <jsnitsel@redhat.com> Date: Mon Mar 27 08:46:04 2017 -0700 tpm_tis: convert to using locality callbacks This patch converts tpm_tis to use of the new tpm class ops request_locality, and relinquish_locality. With the move to using the callbacks, release_locality is changed so that we now release the locality even if there is no request pending. This required some changes to the tpm_tis_core_init code path to make sure locality is requested when needed: - tpm2_probe code path will end up calling request/release through callbacks, so request_locality prior to tpm2_probe not needed. - probe_itpm makes calls to tpm_tis_send_data which no longer calls request_locality, so add request_locality prior to tpm_tis_send_data calls. Also drop release_locality call in middleof probe_itpm, and keep locality until release_locality called at end of probe_itpm. Cc: Peter Huewe <peterhuewe@gmx.de> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Cc: Marcel Selhorst <tpmdd@selhorst.net> Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 72f21b446e45ea1003de75902b0553deb99157fd M drivers ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ tpmdd-devel mailing list tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel ^ permalink raw reply [flat|nested] 62+ messages in thread
[parent not found: <595efb25-8d87-f39d-037f-9c9a98462339-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>]
* Re: tpm device not showing up in /dev anymore [not found] ` <595efb25-8d87-f39d-037f-9c9a98462339-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> @ 2017-08-31 12:10 ` Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w [not found] ` <857106e4bb864bb8a68b1381fffc8f50-nFblLGNE8XKJSz+rYg/bSJowlv4uC7bZ@public.gmane.org> 0 siblings, 1 reply; 62+ messages in thread From: Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w @ 2017-08-31 12:10 UTC (permalink / raw) To: bigon-8fiUuRrzOP0dnm+yROfE0A, jsnitsel-H+wXaHxf7aLQT0dZR+AlfA Cc: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f > Le 29/08/17 à 18:35, Laurent Bigonville a écrit : > > Le 29/08/17 à 18:00, Alexander.Steffen@infineon.com a écrit : > >>> An idea how to troubleshoot this? > >> Can you run git bisect on the changes between 4.11 and 4.12, so that > >> we find the offending commit? It is probably sufficient to limit the > >> search to commits that touch something in drivers/char/tpm. > > > > I'll try and keep you posted. > > OK I've been able to bisect the problem and the bad commit is: > > e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad commit > commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 > Author: Jerry Snitselaar <jsnitsel@redhat.com> > Date: Mon Mar 27 08:46:04 2017 -0700 > > tpm_tis: convert to using locality callbacks > > This patch converts tpm_tis to use of the new tpm class ops > request_locality, and relinquish_locality. > > With the move to using the callbacks, release_locality is changed so > that we now release the locality even if there is no request pending. > > This required some changes to the tpm_tis_core_init code path to > make sure locality is requested when needed: > > - tpm2_probe code path will end up calling request/release through > callbacks, so request_locality prior to tpm2_probe not needed. > > - probe_itpm makes calls to tpm_tis_send_data which no longer calls > request_locality, so add request_locality prior to tpm_tis_send_data > calls. Also drop release_locality call in middleof probe_itpm, and > keep locality until release_locality called at end of probe_itpm. > > Cc: Peter Huewe <peterhuewe@gmx.de> > Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> > Cc: Marcel Selhorst <tpmdd@selhorst.net> > Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> > Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > > :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 > 72f21b446e45ea1003de75902b0553deb99157fd M drivers > I've looked again at the code in question, but could not find anything that is obviously wrong there. Locality is now requested/released at slightly different points in the process than before, but that's it. It does not seem to cause problems with the majority of TPMs, since you are the first to report any, so maybe it is a quirk that only affects this device. Perhaps Jerry can help, since this is his change? Alexander ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ tpmdd-devel mailing list tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel ^ permalink raw reply [flat|nested] 62+ messages in thread
[parent not found: <857106e4bb864bb8a68b1381fffc8f50-nFblLGNE8XKJSz+rYg/bSJowlv4uC7bZ@public.gmane.org>]
* Re: tpm device not showing up in /dev anymore [not found] ` <857106e4bb864bb8a68b1381fffc8f50-nFblLGNE8XKJSz+rYg/bSJowlv4uC7bZ@public.gmane.org> @ 2017-08-31 16:40 ` Jerry Snitselaar 2017-09-01 12:10 ` Laurent Bigonville 0 siblings, 1 reply; 62+ messages in thread From: Jerry Snitselaar @ 2017-08-31 16:40 UTC (permalink / raw) To: Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w Cc: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Jarkko Sakkinen On Thu Aug 31 17, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org wrote: >> Le 29/08/17 à 18:35, Laurent Bigonville a écrit : >> > Le 29/08/17 à 18:00, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org a écrit : >> >>> An idea how to troubleshoot this? >> >> Can you run git bisect on the changes between 4.11 and 4.12, so that >> >> we find the offending commit? It is probably sufficient to limit the >> >> search to commits that touch something in drivers/char/tpm. >> > >> > I'll try and keep you posted. >> >> OK I've been able to bisect the problem and the bad commit is: >> >> e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad commit >> commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >> Author: Jerry Snitselaar <jsnitsel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> >> Date: Mon Mar 27 08:46:04 2017 -0700 >> >> tpm_tis: convert to using locality callbacks >> >> This patch converts tpm_tis to use of the new tpm class ops >> request_locality, and relinquish_locality. >> >> With the move to using the callbacks, release_locality is changed so >> that we now release the locality even if there is no request pending. >> >> This required some changes to the tpm_tis_core_init code path to >> make sure locality is requested when needed: >> >> - tpm2_probe code path will end up calling request/release through >> callbacks, so request_locality prior to tpm2_probe not needed. >> >> - probe_itpm makes calls to tpm_tis_send_data which no longer calls >> request_locality, so add request_locality prior to tpm_tis_send_data >> calls. Also drop release_locality call in middleof probe_itpm, and >> keep locality until release_locality called at end of probe_itpm. >> >> Cc: Peter Huewe <peterhuewe-Mmb7MZpHnFY@public.gmane.org> >> Cc: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> >> Cc: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> >> Cc: Marcel Selhorst <tpmdd-yWjUBOtONefk1uMJSBkQmQ@public.gmane.org> >> Signed-off-by: Jerry Snitselaar <jsnitsel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> >> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> >> Tested-by: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> >> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> >> >> :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >> 72f21b446e45ea1003de75902b0553deb99157fd M drivers >> > >I've looked again at the code in question, but could not find anything that is obviously wrong there. Locality is now requested/released at slightly different points in the process than before, but that's it. It does not seem to cause problems with the majority of TPMs, since you are the first to report any, so maybe it is a quirk that only affects this device. > >Perhaps Jerry can help, since this is his change? > >Alexander Getting some caffeine in me, and starting to take a look. Adding Jarkko as well since this might involve the general locality changes. Laurent, if I send you a patch with some debugging code added, would you be able to run it on that system? I wasn't running into issues on the system I had with a 1.2 device, but I no longer have access to it. I'll see if I can find one in our labs and reproduce it there. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: tpm device not showing up in /dev anymore 2017-08-31 16:40 ` Jerry Snitselaar @ 2017-09-01 12:10 ` Laurent Bigonville [not found] ` <0d9be244-ace0-030d-6ff9-c4e94c63b7e9-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> 0 siblings, 1 reply; 62+ messages in thread From: Laurent Bigonville @ 2017-09-01 12:10 UTC (permalink / raw) To: Jerry Snitselaar, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w Cc: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Jarkko Sakkinen Le 31/08/17 à 18:40, Jerry Snitselaar a écrit : > On Thu Aug 31 17, Alexander.Steffen@infineon.com wrote: >>> Le 29/08/17 à 18:35, Laurent Bigonville a écrit : >>> > Le 29/08/17 à 18:00, Alexander.Steffen@infineon.com a écrit : >>> >>> An idea how to troubleshoot this? >>> >> Can you run git bisect on the changes between 4.11 and 4.12, so that >>> >> we find the offending commit? It is probably sufficient to limit the >>> >> search to commits that touch something in drivers/char/tpm. >>> > >>> > I'll try and keep you posted. >>> >>> OK I've been able to bisect the problem and the bad commit is: >>> >>> e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad commit >>> commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >>> Author: Jerry Snitselaar <jsnitsel@redhat.com> >>> Date: Mon Mar 27 08:46:04 2017 -0700 >>> >>> tpm_tis: convert to using locality callbacks >>> >>> This patch converts tpm_tis to use of the new tpm class ops >>> request_locality, and relinquish_locality. >>> >>> With the move to using the callbacks, release_locality is >>> changed so >>> that we now release the locality even if there is no request >>> pending. >>> >>> This required some changes to the tpm_tis_core_init code path to >>> make sure locality is requested when needed: >>> >>> - tpm2_probe code path will end up calling request/release >>> through >>> callbacks, so request_locality prior to tpm2_probe not needed. >>> >>> - probe_itpm makes calls to tpm_tis_send_data which no longer >>> calls >>> request_locality, so add request_locality prior to >>> tpm_tis_send_data >>> calls. Also drop release_locality call in middleof >>> probe_itpm, and >>> keep locality until release_locality called at end of >>> probe_itpm. >>> >>> Cc: Peter Huewe <peterhuewe@gmx.de> >>> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >>> Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> >>> Cc: Marcel Selhorst <tpmdd@selhorst.net> >>> Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> >>> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >>> Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >>> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >>> >>> :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >>> 72f21b446e45ea1003de75902b0553deb99157fd M drivers >>> >> >> I've looked again at the code in question, but could not find >> anything that is obviously wrong there. Locality is now >> requested/released at slightly different points in the process than >> before, but that's it. It does not seem to cause problems with the >> majority of TPMs, since you are the first to report any, so maybe it >> is a quirk that only affects this device. >> >> Perhaps Jerry can help, since this is his change? >> >> Alexander > > Getting some caffeine in me, and starting to take a look. Adding > Jarkko as well since this might involve the general locality changes. > > Laurent, if I send you a patch with some debugging code added, would > you be able to run it on that system? I wasn't running into issues > on the system I had with a 1.2 device, but I no longer have access > to it. I'll see if I can find one in our labs and reproduce it there. Yes I should be able to do that ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ tpmdd-devel mailing list tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel ^ permalink raw reply [flat|nested] 62+ messages in thread
[parent not found: <0d9be244-ace0-030d-6ff9-c4e94c63b7e9-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>]
* Re: tpm device not showing up in /dev anymore [not found] ` <0d9be244-ace0-030d-6ff9-c4e94c63b7e9-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> @ 2017-09-06 4:05 ` Jarkko Sakkinen 2017-10-14 8:13 ` Jerry Snitselaar 0 siblings, 1 reply; 62+ messages in thread From: Jarkko Sakkinen @ 2017-09-06 4:05 UTC (permalink / raw) To: Laurent Bigonville; +Cc: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent Bigonville wrote: > Le 31/08/17 à 18:40, Jerry Snitselaar a écrit : > > On Thu Aug 31 17, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org wrote: > > > > Le 29/08/17 à 18:35, Laurent Bigonville a écrit : > > > > > Le 29/08/17 à 18:00, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org a écrit : > > > > >>> An idea how to troubleshoot this? > > > > >> Can you run git bisect on the changes between 4.11 and 4.12, so that > > > > >> we find the offending commit? It is probably sufficient to limit the > > > > >> search to commits that touch something in drivers/char/tpm. > > > > > > > > > > I'll try and keep you posted. > > > > > > > > OK I've been able to bisect the problem and the bad commit is: > > > > > > > > e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad commit > > > > commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 > > > > Author: Jerry Snitselaar <jsnitsel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > > > Date: Mon Mar 27 08:46:04 2017 -0700 > > > > > > > > tpm_tis: convert to using locality callbacks > > > > > > > > This patch converts tpm_tis to use of the new tpm class ops > > > > request_locality, and relinquish_locality. > > > > > > > > With the move to using the callbacks, release_locality is > > > > changed so > > > > that we now release the locality even if there is no > > > > request pending. > > > > > > > > This required some changes to the tpm_tis_core_init code path to > > > > make sure locality is requested when needed: > > > > > > > > - tpm2_probe code path will end up calling > > > > request/release through > > > > callbacks, so request_locality prior to tpm2_probe not needed. > > > > > > > > - probe_itpm makes calls to tpm_tis_send_data which no > > > > longer calls > > > > request_locality, so add request_locality prior to > > > > tpm_tis_send_data > > > > calls. Also drop release_locality call in middleof > > > > probe_itpm, and > > > > keep locality until release_locality called at end of > > > > probe_itpm. > > > > > > > > Cc: Peter Huewe <peterhuewe-Mmb7MZpHnFY@public.gmane.org> > > > > Cc: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> > > > > Cc: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> > > > > Cc: Marcel Selhorst <tpmdd-yWjUBOtONefk1uMJSBkQmQ@public.gmane.org> > > > > Signed-off-by: Jerry Snitselaar <jsnitsel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > > > Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1560@public.gmane.orgtel.com> > > > > Tested-by: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563N0uC3ymp8PA@public.gmane.orgl.com> > > > > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > > > > > > > > :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 > > > > 72f21b446e45ea1003de75902b0553deb99157fd M drivers > > > > > > > > > > I've looked again at the code in question, but could not find > > > anything that is obviously wrong there. Locality is now > > > requested/released at slightly different points in the process than > > > before, but that's it. It does not seem to cause problems with the > > > majority of TPMs, since you are the first to report any, so maybe it > > > is a quirk that only affects this device. > > > > > > Perhaps Jerry can help, since this is his change? > > > > > > Alexander > > > > Getting some caffeine in me, and starting to take a look. Adding > > Jarkko as well since this might involve the general locality changes. > > > > Laurent, if I send you a patch with some debugging code added, would > > you be able to run it on that system? I wasn't running into issues > > on the system I had with a 1.2 device, but I no longer have access > > to it. I'll see if I can find one in our labs and reproduce it there. > > Yes I should be able to do that Any findings? /Jarkko ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore @ 2017-10-14 8:13 ` Jerry Snitselaar 0 siblings, 0 replies; 62+ messages in thread From: Jerry Snitselaar @ 2017-10-14 8:13 UTC (permalink / raw) To: Jarkko Sakkinen Cc: Laurent Bigonville, Alexander.Steffen, tpmdd-devel, linux-integrity On Wed Sep 06 17, Jarkko Sakkinen wrote: >On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent Bigonville wrote: >> Le 31/08/17 a 18:40, Jerry Snitselaar a ecrit : >> > On Thu Aug 31 17, Alexander.Steffen@infineon.com wrote: >> > > > Le 29/08/17 a 18:35, Laurent Bigonville a ecrit : >> > > > > Le 29/08/17 a 18:00, Alexander.Steffen@infineon.com a ecrit : >> > > > >>> An idea how to troubleshoot this? >> > > > >> Can you run git bisect on the changes between 4.11 and 4.12, so that >> > > > >> we find the offending commit? It is probably sufficient to limit the >> > > > >> search to commits that touch something in drivers/char/tpm. >> > > > > >> > > > > I'll try and keep you posted. >> > > > >> > > > OK I've been able to bisect the problem and the bad commit is: >> > > > >> > > > e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad commit >> > > > commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >> > > > Author: Jerry Snitselaar <jsnitsel@redhat.com> >> > > > Date: Mon Mar 27 08:46:04 2017 -0700 >> > > > >> > > > tpm_tis: convert to using locality callbacks >> > > > >> > > > This patch converts tpm_tis to use of the new tpm class ops >> > > > request_locality, and relinquish_locality. >> > > > >> > > > With the move to using the callbacks, release_locality is >> > > > changed so >> > > > that we now release the locality even if there is no >> > > > request pending. >> > > > >> > > > This required some changes to the tpm_tis_core_init code path to >> > > > make sure locality is requested when needed: >> > > > >> > > > - tpm2_probe code path will end up calling >> > > > request/release through >> > > > callbacks, so request_locality prior to tpm2_probe not needed. >> > > > >> > > > - probe_itpm makes calls to tpm_tis_send_data which no >> > > > longer calls >> > > > request_locality, so add request_locality prior to >> > > > tpm_tis_send_data >> > > > calls. Also drop release_locality call in middleof >> > > > probe_itpm, and >> > > > keep locality until release_locality called at end of >> > > > probe_itpm. >> > > > >> > > > Cc: Peter Huewe <peterhuewe@gmx.de> >> > > > Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >> > > > Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> >> > > > Cc: Marcel Selhorst <tpmdd@selhorst.net> >> > > > Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> >> > > > Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >> > > > Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >> > > > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >> > > > >> > > > :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >> > > > 72f21b446e45ea1003de75902b0553deb99157fd M drivers >> > > > >> > > >> > > I've looked again at the code in question, but could not find >> > > anything that is obviously wrong there. Locality is now >> > > requested/released at slightly different points in the process than >> > > before, but that's it. It does not seem to cause problems with the >> > > majority of TPMs, since you are the first to report any, so maybe it >> > > is a quirk that only affects this device. >> > > >> > > Perhaps Jerry can help, since this is his change? >> > > >> > > Alexander >> > >> > Getting some caffeine in me, and starting to take a look. Adding >> > Jarkko as well since this might involve the general locality changes. >> > >> > Laurent, if I send you a patch with some debugging code added, would >> > you be able to run it on that system? I wasn't running into issues >> > on the system I had with a 1.2 device, but I no longer have access >> > to it. I'll see if I can find one in our labs and reproduce it there. >> >> Yes I should be able to do that > >Any findings? > >/Jarkko Okay, finally getting back to this. Looking at the code it isn't clear to me why the change is causing this. So while I stare at this some more Laurent could you reproduce it with this patch so I can see what the status and access registers look like? Does anyone else on here happen to have a Sinosun tpm device? The systems I have access to with TPM1.2 devices don't have this issue. --8<-- diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c index fdde971bc810..7d60a7e4b50a 100644 --- a/drivers/char/tpm/tpm_tis_core.c +++ b/drivers/char/tpm/tpm_tis_core.c @@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, const u8 *buf, size_t len) int rc, status, burstcnt; size_t count = 0; bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; + u8 access; status = tpm_tis_status(chip); if ((status & TPM_STS_COMMAND_READY) == 0) { @@ -292,6 +293,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, const u8 *buf, size_t len) } status = tpm_tis_status(chip); if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), &access); + if (rc < 0) + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: read failure TPM_ACCESS(%d)\n", priv->locality); + else + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: locality: %d status: %x access: %x\n", priv->locality, status, access); rc = -EIO; goto out_err; } @@ -309,6 +315,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, const u8 *buf, size_t len) } status = tpm_tis_status(chip); if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), &access); + if (rc < 0) + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read failure TPM_ACCESS(%d)\n", priv->locality); + else + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: locality: %d status: %x access: %x\n", priv->locality, status, access); rc = -EIO; goto out_err; } -- 2.15.0.rc0 ^ permalink raw reply related [flat|nested] 62+ messages in thread
* Re: tpm device not showing up in /dev anymore @ 2017-10-14 8:13 ` Jerry Snitselaar 0 siblings, 0 replies; 62+ messages in thread From: Jerry Snitselaar @ 2017-10-14 8:13 UTC (permalink / raw) To: Jarkko Sakkinen Cc: linux-integrity-u79uwXL29TY76Z2rM5mHXA, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f On Wed Sep 06 17, Jarkko Sakkinen wrote: >On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent Bigonville wrote: >> Le 31/08/17 à 18:40, Jerry Snitselaar a écrit : >> > On Thu Aug 31 17, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org wrote: >> > > > Le 29/08/17 à 18:35, Laurent Bigonville a écrit : >> > > > > Le 29/08/17 à 18:00, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org a écrit : >> > > > >>> An idea how to troubleshoot this? >> > > > >> Can you run git bisect on the changes between 4.11 and 4.12, so that >> > > > >> we find the offending commit? It is probably sufficient to limit the >> > > > >> search to commits that touch something in drivers/char/tpm. >> > > > > >> > > > > I'll try and keep you posted. >> > > > >> > > > OK I've been able to bisect the problem and the bad commit is: >> > > > >> > > > e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad commit >> > > > commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >> > > > Author: Jerry Snitselaar <jsnitsel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> >> > > > Date: Mon Mar 27 08:46:04 2017 -0700 >> > > > >> > > > tpm_tis: convert to using locality callbacks >> > > > >> > > > This patch converts tpm_tis to use of the new tpm class ops >> > > > request_locality, and relinquish_locality. >> > > > >> > > > With the move to using the callbacks, release_locality is >> > > > changed so >> > > > that we now release the locality even if there is no >> > > > request pending. >> > > > >> > > > This required some changes to the tpm_tis_core_init code path to >> > > > make sure locality is requested when needed: >> > > > >> > > > - tpm2_probe code path will end up calling >> > > > request/release through >> > > > callbacks, so request_locality prior to tpm2_probe not needed. >> > > > >> > > > - probe_itpm makes calls to tpm_tis_send_data which no >> > > > longer calls >> > > > request_locality, so add request_locality prior to >> > > > tpm_tis_send_data >> > > > calls. Also drop release_locality call in middleof >> > > > probe_itpm, and >> > > > keep locality until release_locality called at end of >> > > > probe_itpm. >> > > > >> > > > Cc: Peter Huewe <peterhuewe-Mmb7MZpHnFY@public.gmane.org> >> > > > Cc: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> >> > > > Cc: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> >> > > > Cc: Marcel Selhorst <tpmdd-yWjUBOtONefk1uMJSBkQmQ@public.gmane.org> >> > > > Signed-off-by: Jerry Snitselaar <jsnitsel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> >> > > > Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >> > > > Tested-by: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1561eoWH0uzbU5w@public.gmane.orgel.com> >> > > > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >> > > > >> > > > :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >> > > > 72f21b446e45ea1003de75902b0553deb99157fd M drivers >> > > > >> > > >> > > I've looked again at the code in question, but could not find >> > > anything that is obviously wrong there. Locality is now >> > > requested/released at slightly different points in the process than >> > > before, but that's it. It does not seem to cause problems with the >> > > majority of TPMs, since you are the first to report any, so maybe it >> > > is a quirk that only affects this device. >> > > >> > > Perhaps Jerry can help, since this is his change? >> > > >> > > Alexander >> > >> > Getting some caffeine in me, and starting to take a look. Adding >> > Jarkko as well since this might involve the general locality changes. >> > >> > Laurent, if I send you a patch with some debugging code added, would >> > you be able to run it on that system? I wasn't running into issues >> > on the system I had with a 1.2 device, but I no longer have access >> > to it. I'll see if I can find one in our labs and reproduce it there. >> >> Yes I should be able to do that > >Any findings? > >/Jarkko Okay, finally getting back to this. Looking at the code it isn't clear to me why the change is causing this. So while I stare at this some more Laurent could you reproduce it with this patch so I can see what the status and access registers look like? Does anyone else on here happen to have a Sinosun tpm device? The systems I have access to with TPM1.2 devices don't have this issue. --8<-- diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c index fdde971bc810..7d60a7e4b50a 100644 --- a/drivers/char/tpm/tpm_tis_core.c +++ b/drivers/char/tpm/tpm_tis_core.c @@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, const u8 *buf, size_t len) int rc, status, burstcnt; size_t count = 0; bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; + u8 access; status = tpm_tis_status(chip); if ((status & TPM_STS_COMMAND_READY) == 0) { @@ -292,6 +293,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, const u8 *buf, size_t len) } status = tpm_tis_status(chip); if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), &access); + if (rc < 0) + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: read failure TPM_ACCESS(%d)\n", priv->locality); + else + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: locality: %d status: %x access: %x\n", priv->locality, status, access); rc = -EIO; goto out_err; } @@ -309,6 +315,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, const u8 *buf, size_t len) } status = tpm_tis_status(chip); if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), &access); + if (rc < 0) + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read failure TPM_ACCESS(%d)\n", priv->locality); + else + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: locality: %d status: %x access: %x\n", priv->locality, status, access); rc = -EIO; goto out_err; } -- 2.15.0.rc0 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ^ permalink raw reply related [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2017-10-14 8:13 ` Jerry Snitselaar @ 2017-10-21 8:53 ` Laurent Bigonville -1 siblings, 0 replies; 62+ messages in thread From: Laurent Bigonville @ 2017-10-21 8:53 UTC (permalink / raw) To: Jerry Snitselaar, Jarkko Sakkinen Cc: Alexander.Steffen, tpmdd-devel, linux-integrity [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: multipart/mixed; boundary="------------A9FE3B2D3EA7C477C0DA4586", Size: 6419 bytes --] Le 14/10/17 a 10:13, Jerry Snitselaar a ecrit : > On Wed Sep 06 17, Jarkko Sakkinen wrote: >> On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent Bigonville wrote: >>> Le 31/08/17 a 18:40, Jerry Snitselaar a ecrit : >>> > On Thu Aug 31 17, Alexander.Steffen@infineon.com wrote: >>> > > > Le 29/08/17 a 18:35, Laurent Bigonville a ecrit : >>> > > > > Le 29/08/17 a 18:00, Alexander.Steffen@infineon.com a ecrit : >>> > > > >>> An idea how to troubleshoot this? >>> > > > >> Can you run git bisect on the changes between 4.11 and >>> 4.12, so that >>> > > > >> we find the offending commit? It is probably sufficient to >>> limit the >>> > > > >> search to commits that touch something in drivers/char/tpm. >>> > > > > >>> > > > > I'll try and keep you posted. >>> > > > >>> > > > OK I've been able to bisect the problem and the bad commit is: >>> > > > >>> > > > e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad commit >>> > > > commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >>> > > > Author: Jerry Snitselaar <jsnitsel@redhat.com> >>> > > > Date: Mon Mar 27 08:46:04 2017 -0700 >>> > > > >>> > > > tpm_tis: convert to using locality callbacks >>> > > > >>> > > > This patch converts tpm_tis to use of the new tpm class ops >>> > > > request_locality, and relinquish_locality. >>> > > > >>> > > > With the move to using the callbacks, release_locality is >>> > > > changed so >>> > > > that we now release the locality even if there is no >>> > > > request pending. >>> > > > >>> > > > This required some changes to the tpm_tis_core_init code >>> path to >>> > > > make sure locality is requested when needed: >>> > > > >>> > > > - tpm2_probe code path will end up calling >>> > > > request/release through >>> > > > callbacks, so request_locality prior to tpm2_probe >>> not needed. >>> > > > >>> > > > - probe_itpm makes calls to tpm_tis_send_data which no >>> > > > longer calls >>> > > > request_locality, so add request_locality prior to >>> > > > tpm_tis_send_data >>> > > > calls. Also drop release_locality call in middleof >>> > > > probe_itpm, and >>> > > > keep locality until release_locality called at end of >>> > > > probe_itpm. >>> > > > >>> > > > Cc: Peter Huewe <peterhuewe@gmx.de> >>> > > > Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >>> > > > Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> >>> > > > Cc: Marcel Selhorst <tpmdd@selhorst.net> >>> > > > Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> >>> > > > Reviewed-by: Jarkko Sakkinen >>> <jarkko.sakkinen@linux.intel.com> >>> > > > Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >>> > > > Signed-off-by: Jarkko Sakkinen >>> <jarkko.sakkinen@linux.intel.com> >>> > > > >>> > > > :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >>> > > > 72f21b446e45ea1003de75902b0553deb99157fd M drivers >>> > > > >>> > > >>> > > I've looked again at the code in question, but could not find >>> > > anything that is obviously wrong there. Locality is now >>> > > requested/released at slightly different points in the process than >>> > > before, but that's it. It does not seem to cause problems with the >>> > > majority of TPMs, since you are the first to report any, so >>> maybe it >>> > > is a quirk that only affects this device. >>> > > >>> > > Perhaps Jerry can help, since this is his change? >>> > > >>> > > Alexander >>> > >>> > Getting some caffeine in me, and starting to take a look. Adding >>> > Jarkko as well since this might involve the general locality changes. >>> > >>> > Laurent, if I send you a patch with some debugging code added, would >>> > you be able to run it on that system? I wasn't running into issues >>> > on the system I had with a 1.2 device, but I no longer have access >>> > to it. I'll see if I can find one in our labs and reproduce it there. >>> >>> Yes I should be able to do that >> >> Any findings? >> >> /Jarkko > > Okay, finally getting back to this. Looking at the code it isn't clear > to me > why the change is causing this. So while I stare at this some more > Laurent > could you reproduce it with this patch so I can see what the status and > access registers look like? Does anyone else on here happen to have a > Sinosun > tpm device? The systems I have access to with TPM1.2 devices don't > have this > issue. > > --8<-- > > diff --git a/drivers/char/tpm/tpm_tis_core.c > b/drivers/char/tpm/tpm_tis_core.c > index fdde971bc810..7d60a7e4b50a 100644 > --- a/drivers/char/tpm/tpm_tis_core.c > +++ b/drivers/char/tpm/tpm_tis_core.c > @@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct tpm_chip > *chip, const u8 *buf, size_t len) > int rc, status, burstcnt; > size_t count = 0; > bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; > + u8 access; > > status = tpm_tis_status(chip); > if ((status & TPM_STS_COMMAND_READY) == 0) { > @@ -292,6 +293,11 @@ static int tpm_tis_send_data(struct tpm_chip > *chip, const u8 *buf, size_t len) > } > status = tpm_tis_status(chip); > if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), > &access); > + if (rc < 0) > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: read > failure TPM_ACCESS(%d)\n", priv->locality); > + else > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: > locality: %d status: %x access: %x\n", priv->locality, status, access); > rc = -EIO; > goto out_err; > } > @@ -309,6 +315,11 @@ static int tpm_tis_send_data(struct tpm_chip > *chip, const u8 *buf, size_t len) > } > status = tpm_tis_status(chip); > if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), &access); > + if (rc < 0) > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read > failure TPM_ACCESS(%d)\n", priv->locality); > + else > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: locality: > %d status: %x access: %x\n", priv->locality, status, access); > rc = -EIO; > goto out_err; > } Please find here the dmesg output of the patched kernel [ Part 2, Application/GZIP (Name: "dmesg.txt.gz") 20 KB. ] [ Unable to print this part. ] ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: tpm device not showing up in /dev anymore @ 2017-10-21 8:53 ` Laurent Bigonville 0 siblings, 0 replies; 62+ messages in thread From: Laurent Bigonville @ 2017-10-21 8:53 UTC (permalink / raw) To: Jerry Snitselaar, Jarkko Sakkinen Cc: linux-integrity-u79uwXL29TY76Z2rM5mHXA, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f [-- Attachment #1: Type: text/plain, Size: 7032 bytes --] Le 14/10/17 à 10:13, Jerry Snitselaar a écrit : > On Wed Sep 06 17, Jarkko Sakkinen wrote: >> On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent Bigonville wrote: >>> Le 31/08/17 à 18:40, Jerry Snitselaar a écrit : >>> > On Thu Aug 31 17, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org wrote: >>> > > > Le 29/08/17 à 18:35, Laurent Bigonville a écrit : >>> > > > > Le 29/08/17 à 18:00, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org a écrit : >>> > > > >>> An idea how to troubleshoot this? >>> > > > >> Can you run git bisect on the changes between 4.11 and >>> 4.12, so that >>> > > > >> we find the offending commit? It is probably sufficient to >>> limit the >>> > > > >> search to commits that touch something in drivers/char/tpm. >>> > > > > >>> > > > > I'll try and keep you posted. >>> > > > >>> > > > OK I've been able to bisect the problem and the bad commit is: >>> > > > >>> > > > e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad commit >>> > > > commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >>> > > > Author: Jerry Snitselaar <jsnitsel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> >>> > > > Date: Mon Mar 27 08:46:04 2017 -0700 >>> > > > >>> > > > tpm_tis: convert to using locality callbacks >>> > > > >>> > > > This patch converts tpm_tis to use of the new tpm class ops >>> > > > request_locality, and relinquish_locality. >>> > > > >>> > > > With the move to using the callbacks, release_locality is >>> > > > changed so >>> > > > that we now release the locality even if there is no >>> > > > request pending. >>> > > > >>> > > > This required some changes to the tpm_tis_core_init code >>> path to >>> > > > make sure locality is requested when needed: >>> > > > >>> > > > - tpm2_probe code path will end up calling >>> > > > request/release through >>> > > > callbacks, so request_locality prior to tpm2_probe >>> not needed. >>> > > > >>> > > > - probe_itpm makes calls to tpm_tis_send_data which no >>> > > > longer calls >>> > > > request_locality, so add request_locality prior to >>> > > > tpm_tis_send_data >>> > > > calls. Also drop release_locality call in middleof >>> > > > probe_itpm, and >>> > > > keep locality until release_locality called at end of >>> > > > probe_itpm. >>> > > > >>> > > > Cc: Peter Huewe <peterhuewe-Mmb7MZpHnFY@public.gmane.org> >>> > > > Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >>> > > > Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> >>> > > > Cc: Marcel Selhorst <tpmdd-yWjUBOtONeeDGRHsOpWV0g@public.gmane.orgt> >>> > > > Signed-off-by: Jerry Snitselaar <jsnitsel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> >>> > > > Reviewed-by: Jarkko Sakkinen >>> <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> >>> > > > Tested-by: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> >>> > > > Signed-off-by: Jarkko Sakkinen >>> <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> >>> > > > >>> > > > :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >>> > > > 72f21b446e45ea1003de75902b0553deb99157fd M drivers >>> > > > >>> > > >>> > > I've looked again at the code in question, but could not find >>> > > anything that is obviously wrong there. Locality is now >>> > > requested/released at slightly different points in the process than >>> > > before, but that's it. It does not seem to cause problems with the >>> > > majority of TPMs, since you are the first to report any, so >>> maybe it >>> > > is a quirk that only affects this device. >>> > > >>> > > Perhaps Jerry can help, since this is his change? >>> > > >>> > > Alexander >>> > >>> > Getting some caffeine in me, and starting to take a look. Adding >>> > Jarkko as well since this might involve the general locality changes. >>> > >>> > Laurent, if I send you a patch with some debugging code added, would >>> > you be able to run it on that system? I wasn't running into issues >>> > on the system I had with a 1.2 device, but I no longer have access >>> > to it. I'll see if I can find one in our labs and reproduce it there. >>> >>> Yes I should be able to do that >> >> Any findings? >> >> /Jarkko > > Okay, finally getting back to this. Looking at the code it isn't clear > to me > why the change is causing this. So while I stare at this some more > Laurent > could you reproduce it with this patch so I can see what the status and > access registers look like? Does anyone else on here happen to have a > Sinosun > tpm device? The systems I have access to with TPM1.2 devices don't > have this > issue. > > --8<-- > > diff --git a/drivers/char/tpm/tpm_tis_core.c > b/drivers/char/tpm/tpm_tis_core.c > index fdde971bc810..7d60a7e4b50a 100644 > --- a/drivers/char/tpm/tpm_tis_core.c > +++ b/drivers/char/tpm/tpm_tis_core.c > @@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct tpm_chip > *chip, const u8 *buf, size_t len) > int rc, status, burstcnt; > size_t count = 0; > bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; > + u8 access; > > status = tpm_tis_status(chip); > if ((status & TPM_STS_COMMAND_READY) == 0) { > @@ -292,6 +293,11 @@ static int tpm_tis_send_data(struct tpm_chip > *chip, const u8 *buf, size_t len) > } > status = tpm_tis_status(chip); > if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), > &access); > + if (rc < 0) > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: read > failure TPM_ACCESS(%d)\n", priv->locality); > + else > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: > locality: %d status: %x access: %x\n", priv->locality, status, access); > rc = -EIO; > goto out_err; > } > @@ -309,6 +315,11 @@ static int tpm_tis_send_data(struct tpm_chip > *chip, const u8 *buf, size_t len) > } > status = tpm_tis_status(chip); > if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), &access); > + if (rc < 0) > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read > failure TPM_ACCESS(%d)\n", priv->locality); > + else > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: locality: > %d status: %x access: %x\n", priv->locality, status, access); > rc = -EIO; > goto out_err; > } Please find here the dmesg output of the patched kernel [-- Attachment #2: dmesg.txt.gz --] [-- Type: application/gzip, Size: 20410 bytes --] [-- Attachment #3: Type: text/plain, Size: 202 bytes --] ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot [-- Attachment #4: Type: text/plain, Size: 192 bytes --] _______________________________________________ tpmdd-devel mailing list tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/tpmdd-devel ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore @ 2017-10-23 13:23 ` Jarkko Sakkinen 0 siblings, 0 replies; 62+ messages in thread From: Jarkko Sakkinen @ 2017-10-23 13:23 UTC (permalink / raw) To: Laurent Bigonville Cc: Jerry Snitselaar, Alexander.Steffen, tpmdd-devel, linux-integrity On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote: > Le 14/10/17 a 10:13, Jerry Snitselaar a ecrit : > > On Wed Sep 06 17, Jarkko Sakkinen wrote: > > > On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent Bigonville wrote: > > > > Le 31/08/17 a 18:40, Jerry Snitselaar a ecrit : > > > > > On Thu Aug 31 17, Alexander.Steffen@infineon.com wrote: > > > > > > > Le 29/08/17 a 18:35, Laurent Bigonville a ecrit : > > > > > > > > Le 29/08/17 a 18:00, Alexander.Steffen@infineon.com a ecrit : > > > > > > > >>> An idea how to troubleshoot this? > > > > > > > >> Can you run git bisect on the changes between 4.11 and > > > > 4.12, so that > > > > > > > >> we find the offending commit? It is probably sufficient > > > > to limit the > > > > > > > >> search to commits that touch something in drivers/char/tpm. > > > > > > > > > > > > > > > > I'll try and keep you posted. > > > > > > > > > > > > > > OK I've been able to bisect the problem and the bad commit is: > > > > > > > > > > > > > > e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad commit > > > > > > > commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 > > > > > > > Author: Jerry Snitselaar <jsnitsel@redhat.com> > > > > > > > Date: Mon Mar 27 08:46:04 2017 -0700 > > > > > > > > > > > > > > tpm_tis: convert to using locality callbacks > > > > > > > > > > > > > > This patch converts tpm_tis to use of the new tpm class ops > > > > > > > request_locality, and relinquish_locality. > > > > > > > > > > > > > > With the move to using the callbacks, release_locality is > > > > > > > changed so > > > > > > > that we now release the locality even if there is no > > > > > > > request pending. > > > > > > > > > > > > > > This required some changes to the tpm_tis_core_init > > > > code path to > > > > > > > make sure locality is requested when needed: > > > > > > > > > > > > > > - tpm2_probe code path will end up calling > > > > > > > request/release through > > > > > > > callbacks, so request_locality prior to > > > > tpm2_probe not needed. > > > > > > > > > > > > > > - probe_itpm makes calls to tpm_tis_send_data which no > > > > > > > longer calls > > > > > > > request_locality, so add request_locality prior to > > > > > > > tpm_tis_send_data > > > > > > > calls. Also drop release_locality call in middleof > > > > > > > probe_itpm, and > > > > > > > keep locality until release_locality called at end of > > > > > > > probe_itpm. > > > > > > > > > > > > > > Cc: Peter Huewe <peterhuewe@gmx.de> > > > > > > > Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > > > > > > > Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> > > > > > > > Cc: Marcel Selhorst <tpmdd@selhorst.net> > > > > > > > Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> > > > > > > > Reviewed-by: Jarkko Sakkinen > > > > <jarkko.sakkinen@linux.intel.com> > > > > > > > Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > > > > > > > Signed-off-by: Jarkko Sakkinen > > > > <jarkko.sakkinen@linux.intel.com> > > > > > > > > > > > > > > :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 > > > > > > > 72f21b446e45ea1003de75902b0553deb99157fd M drivers > > > > > > > > > > > > > > > > > > > I've looked again at the code in question, but could not find > > > > > > anything that is obviously wrong there. Locality is now > > > > > > requested/released at slightly different points in the process than > > > > > > before, but that's it. It does not seem to cause problems with the > > > > > > majority of TPMs, since you are the first to report any, so > > > > maybe it > > > > > > is a quirk that only affects this device. > > > > > > > > > > > > Perhaps Jerry can help, since this is his change? > > > > > > > > > > > > Alexander > > > > > > > > > > Getting some caffeine in me, and starting to take a look. Adding > > > > > Jarkko as well since this might involve the general locality changes. > > > > > > > > > > Laurent, if I send you a patch with some debugging code added, would > > > > > you be able to run it on that system? I wasn't running into issues > > > > > on the system I had with a 1.2 device, but I no longer have access > > > > > to it. I'll see if I can find one in our labs and reproduce it there. > > > > > > > > Yes I should be able to do that > > > > > > Any findings? > > > > > > /Jarkko > > > > Okay, finally getting back to this. Looking at the code it isn't clear > > to me > > why the change is causing this. So while I stare at this some more > > Laurent > > could you reproduce it with this patch so I can see what the status and > > access registers look like? Does anyone else on here happen to have a > > Sinosun > > tpm device? The systems I have access to with TPM1.2 devices don't have > > this > > issue. > > > > --8<-- > > > > diff --git a/drivers/char/tpm/tpm_tis_core.c > > b/drivers/char/tpm/tpm_tis_core.c > > index fdde971bc810..7d60a7e4b50a 100644 > > --- a/drivers/char/tpm/tpm_tis_core.c > > +++ b/drivers/char/tpm/tpm_tis_core.c > > @@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, > > const u8 *buf, size_t len) > > int rc, status, burstcnt; > > size_t count = 0; > > bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; > > + u8 access; > > > > status = tpm_tis_status(chip); > > if ((status & TPM_STS_COMMAND_READY) == 0) { > > @@ -292,6 +293,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, > > const u8 *buf, size_t len) > > } > > status = tpm_tis_status(chip); > > if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { > > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), > > &access); > > + if (rc < 0) > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: read > > failure TPM_ACCESS(%d)\n", priv->locality); > > + else > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: > > locality: %d status: %x access: %x\n", priv->locality, status, access); > > rc = -EIO; > > goto out_err; > > } > > @@ -309,6 +315,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, > > const u8 *buf, size_t len) > > } > > status = tpm_tis_status(chip); > > if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { > > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), &access); > > + if (rc < 0) > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read > > failure TPM_ACCESS(%d)\n", priv->locality); > > + else > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: locality: > > %d status: %x access: %x\n", priv->locality, status, access); > > rc = -EIO; > > goto out_err; > > } > > Please find here the dmesg output of the patched kernel At least 0xff is corrupted value in senseful way. CPU fills the read with ones for example for unaligned bus read. See table 19 in PC client spec. This can happen when you do unaligned read for example. Maybe TPM is unreachable i.e. powered off. Bit busy with stuff ATM but would probably make sense to compare that 0x81 to table 18 in the same spec. /Jarkko ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: tpm device not showing up in /dev anymore @ 2017-10-23 13:23 ` Jarkko Sakkinen 0 siblings, 0 replies; 62+ messages in thread From: Jarkko Sakkinen @ 2017-10-23 13:23 UTC (permalink / raw) To: Laurent Bigonville Cc: linux-integrity-u79uwXL29TY76Z2rM5mHXA, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote: > Le 14/10/17 à 10:13, Jerry Snitselaar a écrit : > > On Wed Sep 06 17, Jarkko Sakkinen wrote: > > > On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent Bigonville wrote: > > > > Le 31/08/17 à 18:40, Jerry Snitselaar a écrit : > > > > > On Thu Aug 31 17, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org wrote: > > > > > > > Le 29/08/17 à 18:35, Laurent Bigonville a écrit : > > > > > > > > Le 29/08/17 à 18:00, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org a écrit : > > > > > > > >>> An idea how to troubleshoot this? > > > > > > > >> Can you run git bisect on the changes between 4.11 and > > > > 4.12, so that > > > > > > > >> we find the offending commit? It is probably sufficient > > > > to limit the > > > > > > > >> search to commits that touch something in drivers/char/tpm. > > > > > > > > > > > > > > > > I'll try and keep you posted. > > > > > > > > > > > > > > OK I've been able to bisect the problem and the bad commit is: > > > > > > > > > > > > > > e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad commit > > > > > > > commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 > > > > > > > Author: Jerry Snitselaar <jsnitsel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > > > > > > Date: Mon Mar 27 08:46:04 2017 -0700 > > > > > > > > > > > > > > tpm_tis: convert to using locality callbacks > > > > > > > > > > > > > > This patch converts tpm_tis to use of the new tpm class ops > > > > > > > request_locality, and relinquish_locality. > > > > > > > > > > > > > > With the move to using the callbacks, release_locality is > > > > > > > changed so > > > > > > > that we now release the locality even if there is no > > > > > > > request pending. > > > > > > > > > > > > > > This required some changes to the tpm_tis_core_init > > > > code path to > > > > > > > make sure locality is requested when needed: > > > > > > > > > > > > > > - tpm2_probe code path will end up calling > > > > > > > request/release through > > > > > > > callbacks, so request_locality prior to > > > > tpm2_probe not needed. > > > > > > > > > > > > > > - probe_itpm makes calls to tpm_tis_send_data which no > > > > > > > longer calls > > > > > > > request_locality, so add request_locality prior to > > > > > > > tpm_tis_send_data > > > > > > > calls. Also drop release_locality call in middleof > > > > > > > probe_itpm, and > > > > > > > keep locality until release_locality called at end of > > > > > > > probe_itpm. > > > > > > > > > > > > > > Cc: Peter Huewe <peterhuewe-Mmb7MZpHnFY@public.gmane.org> > > > > > > > Cc: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1560/9W2qTSuDoA@public.gmane.org.com> > > > > > > > Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> > > > > > > > Cc: Marcel Selhorst <tpmdd-yWjUBOtONefk1uMJSBkQmQ@public.gmane.org> > > > > > > > Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> > > > > > > > Reviewed-by: Jarkko Sakkinen > > > > <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> > > > > > > > Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > > > > > > > Signed-off-by: Jarkko Sakkinen > > > > <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> > > > > > > > > > > > > > > :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 > > > > > > > 72f21b446e45ea1003de75902b0553deb99157fd M drivers > > > > > > > > > > > > > > > > > > > I've looked again at the code in question, but could not find > > > > > > anything that is obviously wrong there. Locality is now > > > > > > requested/released at slightly different points in the process than > > > > > > before, but that's it. It does not seem to cause problems with the > > > > > > majority of TPMs, since you are the first to report any, so > > > > maybe it > > > > > > is a quirk that only affects this device. > > > > > > > > > > > > Perhaps Jerry can help, since this is his change? > > > > > > > > > > > > Alexander > > > > > > > > > > Getting some caffeine in me, and starting to take a look. Adding > > > > > Jarkko as well since this might involve the general locality changes. > > > > > > > > > > Laurent, if I send you a patch with some debugging code added, would > > > > > you be able to run it on that system? I wasn't running into issues > > > > > on the system I had with a 1.2 device, but I no longer have access > > > > > to it. I'll see if I can find one in our labs and reproduce it there. > > > > > > > > Yes I should be able to do that > > > > > > Any findings? > > > > > > /Jarkko > > > > Okay, finally getting back to this. Looking at the code it isn't clear > > to me > > why the change is causing this. So while I stare at this some more > > Laurent > > could you reproduce it with this patch so I can see what the status and > > access registers look like? Does anyone else on here happen to have a > > Sinosun > > tpm device? The systems I have access to with TPM1.2 devices don't have > > this > > issue. > > > > --8<-- > > > > diff --git a/drivers/char/tpm/tpm_tis_core.c > > b/drivers/char/tpm/tpm_tis_core.c > > index fdde971bc810..7d60a7e4b50a 100644 > > --- a/drivers/char/tpm/tpm_tis_core.c > > +++ b/drivers/char/tpm/tpm_tis_core.c > > @@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, > > const u8 *buf, size_t len) > > int rc, status, burstcnt; > > size_t count = 0; > > bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; > > + u8 access; > > > > status = tpm_tis_status(chip); > > if ((status & TPM_STS_COMMAND_READY) == 0) { > > @@ -292,6 +293,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, > > const u8 *buf, size_t len) > > } > > status = tpm_tis_status(chip); > > if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { > > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), > > &access); > > + if (rc < 0) > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: read > > failure TPM_ACCESS(%d)\n", priv->locality); > > + else > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: > > locality: %d status: %x access: %x\n", priv->locality, status, access); > > rc = -EIO; > > goto out_err; > > } > > @@ -309,6 +315,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, > > const u8 *buf, size_t len) > > } > > status = tpm_tis_status(chip); > > if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { > > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), &access); > > + if (rc < 0) > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read > > failure TPM_ACCESS(%d)\n", priv->locality); > > + else > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: locality: > > %d status: %x access: %x\n", priv->locality, status, access); > > rc = -EIO; > > goto out_err; > > } > > Please find here the dmesg output of the patched kernel At least 0xff is corrupted value in senseful way. CPU fills the read with ones for example for unaligned bus read. See table 19 in PC client spec. This can happen when you do unaligned read for example. Maybe TPM is unreachable i.e. powered off. Bit busy with stuff ATM but would probably make sense to compare that 0x81 to table 18 in the same spec. /Jarkko ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore @ 2017-10-23 13:45 ` Jerry Snitselaar 0 siblings, 0 replies; 62+ messages in thread From: Jerry Snitselaar @ 2017-10-23 13:45 UTC (permalink / raw) To: Jarkko Sakkinen Cc: Laurent Bigonville, Alexander.Steffen, tpmdd-devel, linux-integrity On Mon Oct 23 17, Jarkko Sakkinen wrote: >On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote: >> Le 14/10/17 a 10:13, Jerry Snitselaar a ecrit : >> > On Wed Sep 06 17, Jarkko Sakkinen wrote: >> > > On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent Bigonville wrote: >> > > > Le 31/08/17 a 18:40, Jerry Snitselaar a ecrit : >> > > > > On Thu Aug 31 17, Alexander.Steffen@infineon.com wrote: >> > > > > > > Le 29/08/17 a 18:35, Laurent Bigonville a ecrit : >> > > > > > > > Le 29/08/17 a 18:00, Alexander.Steffen@infineon.com a ecrit : >> > > > > > > >>> An idea how to troubleshoot this? >> > > > > > > >> Can you run git bisect on the changes between 4.11 and >> > > > 4.12, so that >> > > > > > > >> we find the offending commit? It is probably sufficient >> > > > to limit the >> > > > > > > >> search to commits that touch something in drivers/char/tpm. >> > > > > > > > >> > > > > > > > I'll try and keep you posted. >> > > > > > > >> > > > > > > OK I've been able to bisect the problem and the bad commit is: >> > > > > > > >> > > > > > > e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad commit >> > > > > > > commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >> > > > > > > Author: Jerry Snitselaar <jsnitsel@redhat.com> >> > > > > > > Date: Mon Mar 27 08:46:04 2017 -0700 >> > > > > > > >> > > > > > > tpm_tis: convert to using locality callbacks >> > > > > > > >> > > > > > > This patch converts tpm_tis to use of the new tpm class ops >> > > > > > > request_locality, and relinquish_locality. >> > > > > > > >> > > > > > > With the move to using the callbacks, release_locality is >> > > > > > > changed so >> > > > > > > that we now release the locality even if there is no >> > > > > > > request pending. >> > > > > > > >> > > > > > > This required some changes to the tpm_tis_core_init >> > > > code path to >> > > > > > > make sure locality is requested when needed: >> > > > > > > >> > > > > > > - tpm2_probe code path will end up calling >> > > > > > > request/release through >> > > > > > > callbacks, so request_locality prior to >> > > > tpm2_probe not needed. >> > > > > > > >> > > > > > > - probe_itpm makes calls to tpm_tis_send_data which no >> > > > > > > longer calls >> > > > > > > request_locality, so add request_locality prior to >> > > > > > > tpm_tis_send_data >> > > > > > > calls. Also drop release_locality call in middleof >> > > > > > > probe_itpm, and >> > > > > > > keep locality until release_locality called at end of >> > > > > > > probe_itpm. >> > > > > > > >> > > > > > > Cc: Peter Huewe <peterhuewe@gmx.de> >> > > > > > > Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >> > > > > > > Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> >> > > > > > > Cc: Marcel Selhorst <tpmdd@selhorst.net> >> > > > > > > Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> >> > > > > > > Reviewed-by: Jarkko Sakkinen >> > > > <jarkko.sakkinen@linux.intel.com> >> > > > > > > Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >> > > > > > > Signed-off-by: Jarkko Sakkinen >> > > > <jarkko.sakkinen@linux.intel.com> >> > > > > > > >> > > > > > > :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >> > > > > > > 72f21b446e45ea1003de75902b0553deb99157fd M drivers >> > > > > > > >> > > > > > >> > > > > > I've looked again at the code in question, but could not find >> > > > > > anything that is obviously wrong there. Locality is now >> > > > > > requested/released at slightly different points in the process than >> > > > > > before, but that's it. It does not seem to cause problems with the >> > > > > > majority of TPMs, since you are the first to report any, so >> > > > maybe it >> > > > > > is a quirk that only affects this device. >> > > > > > >> > > > > > Perhaps Jerry can help, since this is his change? >> > > > > > >> > > > > > Alexander >> > > > > >> > > > > Getting some caffeine in me, and starting to take a look. Adding >> > > > > Jarkko as well since this might involve the general locality changes. >> > > > > >> > > > > Laurent, if I send you a patch with some debugging code added, would >> > > > > you be able to run it on that system? I wasn't running into issues >> > > > > on the system I had with a 1.2 device, but I no longer have access >> > > > > to it. I'll see if I can find one in our labs and reproduce it there. >> > > > >> > > > Yes I should be able to do that >> > > >> > > Any findings? >> > > >> > > /Jarkko >> > >> > Okay, finally getting back to this. Looking at the code it isn't clear >> > to me >> > why the change is causing this. So while I stare at this some more >> > Laurent >> > could you reproduce it with this patch so I can see what the status and >> > access registers look like? Does anyone else on here happen to have a >> > Sinosun >> > tpm device? The systems I have access to with TPM1.2 devices don't have >> > this >> > issue. >> > >> > --8<-- >> > >> > diff --git a/drivers/char/tpm/tpm_tis_core.c >> > b/drivers/char/tpm/tpm_tis_core.c >> > index fdde971bc810..7d60a7e4b50a 100644 >> > --- a/drivers/char/tpm/tpm_tis_core.c >> > +++ b/drivers/char/tpm/tpm_tis_core.c >> > @@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >> > const u8 *buf, size_t len) >> > int rc, status, burstcnt; >> > size_t count = 0; >> > bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; >> > + u8 access; >> > >> > status = tpm_tis_status(chip); >> > if ((status & TPM_STS_COMMAND_READY) == 0) { >> > @@ -292,6 +293,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >> > const u8 *buf, size_t len) >> > } >> > status = tpm_tis_status(chip); >> > if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { >> > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), >> > &access); >> > + if (rc < 0) >> > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: read >> > failure TPM_ACCESS(%d)\n", priv->locality); >> > + else >> > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: >> > locality: %d status: %x access: %x\n", priv->locality, status, access); >> > rc = -EIO; >> > goto out_err; >> > } >> > @@ -309,6 +315,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >> > const u8 *buf, size_t len) >> > } >> > status = tpm_tis_status(chip); >> > if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { >> > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), &access); >> > + if (rc < 0) >> > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read >> > failure TPM_ACCESS(%d)\n", priv->locality); >> > + else >> > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: locality: >> > %d status: %x access: %x\n", priv->locality, status, access); >> > rc = -EIO; >> > goto out_err; >> > } >> >> Please find here the dmesg output of the patched kernel > >At least 0xff is corrupted value in senseful way. CPU fills the read >with ones for example for unaligned bus read. See table 19 in PC client >spec. This can happen when you do unaligned read for example. > >Maybe TPM is unreachable i.e. powered off. Bit busy with stuff ATM but >would probably make sense to compare that 0x81 to table 18 in the same >spec. > >/Jarkko 0x81 is saying the access register status is valid, and the locality is not active. That first bit means A Dynamic OS has not been previously established on the platform. Normally we would see 0xa1, which would mean valid register status, and the locality is active. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: tpm device not showing up in /dev anymore @ 2017-10-23 13:45 ` Jerry Snitselaar 0 siblings, 0 replies; 62+ messages in thread From: Jerry Snitselaar @ 2017-10-23 13:45 UTC (permalink / raw) To: Jarkko Sakkinen Cc: linux-integrity-u79uwXL29TY76Z2rM5mHXA, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f On Mon Oct 23 17, Jarkko Sakkinen wrote: >On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote: >> Le 14/10/17 à 10:13, Jerry Snitselaar a écrit : >> > On Wed Sep 06 17, Jarkko Sakkinen wrote: >> > > On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent Bigonville wrote: >> > > > Le 31/08/17 à 18:40, Jerry Snitselaar a écrit : >> > > > > On Thu Aug 31 17, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org wrote: >> > > > > > > Le 29/08/17 à 18:35, Laurent Bigonville a écrit : >> > > > > > > > Le 29/08/17 à 18:00, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org a écrit : >> > > > > > > >>> An idea how to troubleshoot this? >> > > > > > > >> Can you run git bisect on the changes between 4.11 and >> > > > 4.12, so that >> > > > > > > >> we find the offending commit? It is probably sufficient >> > > > to limit the >> > > > > > > >> search to commits that touch something in drivers/char/tpm. >> > > > > > > > >> > > > > > > > I'll try and keep you posted. >> > > > > > > >> > > > > > > OK I've been able to bisect the problem and the bad commit is: >> > > > > > > >> > > > > > > e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad commit >> > > > > > > commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >> > > > > > > Author: Jerry Snitselaar <jsnitsel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> >> > > > > > > Date: Mon Mar 27 08:46:04 2017 -0700 >> > > > > > > >> > > > > > > tpm_tis: convert to using locality callbacks >> > > > > > > >> > > > > > > This patch converts tpm_tis to use of the new tpm class ops >> > > > > > > request_locality, and relinquish_locality. >> > > > > > > >> > > > > > > With the move to using the callbacks, release_locality is >> > > > > > > changed so >> > > > > > > that we now release the locality even if there is no >> > > > > > > request pending. >> > > > > > > >> > > > > > > This required some changes to the tpm_tis_core_init >> > > > code path to >> > > > > > > make sure locality is requested when needed: >> > > > > > > >> > > > > > > - tpm2_probe code path will end up calling >> > > > > > > request/release through >> > > > > > > callbacks, so request_locality prior to >> > > > tpm2_probe not needed. >> > > > > > > >> > > > > > > - probe_itpm makes calls to tpm_tis_send_data which no >> > > > > > > longer calls >> > > > > > > request_locality, so add request_locality prior to >> > > > > > > tpm_tis_send_data >> > > > > > > calls. Also drop release_locality call in middleof >> > > > > > > probe_itpm, and >> > > > > > > keep locality until release_locality called at end of >> > > > > > > probe_itpm. >> > > > > > > >> > > > > > > Cc: Peter Huewe <peterhuewe-Mmb7MZpHnFY@public.gmane.org> >> > > > > > > Cc: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563N0uC3ymp8PA@public.gmane.orgl.com> >> > > > > > > Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> >> > > > > > > Cc: Marcel Selhorst <tpmdd-yWjUBOtONefk1uMJSBkQmQ@public.gmane.org> >> > > > > > > Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> >> > > > > > > Reviewed-by: Jarkko Sakkinen >> > > > <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> >> > > > > > > Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >> > > > > > > Signed-off-by: Jarkko Sakkinen >> > > > <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> >> > > > > > > >> > > > > > > :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >> > > > > > > 72f21b446e45ea1003de75902b0553deb99157fd M drivers >> > > > > > > >> > > > > > >> > > > > > I've looked again at the code in question, but could not find >> > > > > > anything that is obviously wrong there. Locality is now >> > > > > > requested/released at slightly different points in the process than >> > > > > > before, but that's it. It does not seem to cause problems with the >> > > > > > majority of TPMs, since you are the first to report any, so >> > > > maybe it >> > > > > > is a quirk that only affects this device. >> > > > > > >> > > > > > Perhaps Jerry can help, since this is his change? >> > > > > > >> > > > > > Alexander >> > > > > >> > > > > Getting some caffeine in me, and starting to take a look. Adding >> > > > > Jarkko as well since this might involve the general locality changes. >> > > > > >> > > > > Laurent, if I send you a patch with some debugging code added, would >> > > > > you be able to run it on that system? I wasn't running into issues >> > > > > on the system I had with a 1.2 device, but I no longer have access >> > > > > to it. I'll see if I can find one in our labs and reproduce it there. >> > > > >> > > > Yes I should be able to do that >> > > >> > > Any findings? >> > > >> > > /Jarkko >> > >> > Okay, finally getting back to this. Looking at the code it isn't clear >> > to me >> > why the change is causing this. So while I stare at this some more >> > Laurent >> > could you reproduce it with this patch so I can see what the status and >> > access registers look like? Does anyone else on here happen to have a >> > Sinosun >> > tpm device? The systems I have access to with TPM1.2 devices don't have >> > this >> > issue. >> > >> > --8<-- >> > >> > diff --git a/drivers/char/tpm/tpm_tis_core.c >> > b/drivers/char/tpm/tpm_tis_core.c >> > index fdde971bc810..7d60a7e4b50a 100644 >> > --- a/drivers/char/tpm/tpm_tis_core.c >> > +++ b/drivers/char/tpm/tpm_tis_core.c >> > @@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >> > const u8 *buf, size_t len) >> > int rc, status, burstcnt; >> > size_t count = 0; >> > bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; >> > + u8 access; >> > >> > status = tpm_tis_status(chip); >> > if ((status & TPM_STS_COMMAND_READY) == 0) { >> > @@ -292,6 +293,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >> > const u8 *buf, size_t len) >> > } >> > status = tpm_tis_status(chip); >> > if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { >> > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), >> > &access); >> > + if (rc < 0) >> > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: read >> > failure TPM_ACCESS(%d)\n", priv->locality); >> > + else >> > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: >> > locality: %d status: %x access: %x\n", priv->locality, status, access); >> > rc = -EIO; >> > goto out_err; >> > } >> > @@ -309,6 +315,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >> > const u8 *buf, size_t len) >> > } >> > status = tpm_tis_status(chip); >> > if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { >> > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), &access); >> > + if (rc < 0) >> > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read >> > failure TPM_ACCESS(%d)\n", priv->locality); >> > + else >> > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: locality: >> > %d status: %x access: %x\n", priv->locality, status, access); >> > rc = -EIO; >> > goto out_err; >> > } >> >> Please find here the dmesg output of the patched kernel > >At least 0xff is corrupted value in senseful way. CPU fills the read >with ones for example for unaligned bus read. See table 19 in PC client >spec. This can happen when you do unaligned read for example. > >Maybe TPM is unreachable i.e. powered off. Bit busy with stuff ATM but >would probably make sense to compare that 0x81 to table 18 in the same >spec. > >/Jarkko 0x81 is saying the access register status is valid, and the locality is not active. That first bit means A Dynamic OS has not been previously established on the platform. Normally we would see 0xa1, which would mean valid register status, and the locality is active. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2017-10-23 13:45 ` Jerry Snitselaar @ 2017-10-23 13:48 ` Laurent Bigonville -1 siblings, 0 replies; 62+ messages in thread From: Laurent Bigonville @ 2017-10-23 13:48 UTC (permalink / raw) To: Jerry Snitselaar, Jarkko Sakkinen Cc: Alexander.Steffen, tpmdd-devel, linux-integrity Le 23/10/17 a 15:45, Jerry Snitselaar a ecrit : > On Mon Oct 23 17, Jarkko Sakkinen wrote: >> On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote: >>> Le 14/10/17 a 10:13, Jerry Snitselaar a ecrit : >>> > On Wed Sep 06 17, Jarkko Sakkinen wrote: >>> > > On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent Bigonville wrote: >>> > > > Le 31/08/17 a 18:40, Jerry Snitselaar a ecrit : >>> > > > > On Thu Aug 31 17, Alexander.Steffen@infineon.com wrote: >>> > > > > > > Le 29/08/17 a 18:35, Laurent Bigonville a ecrit : >>> > > > > > > > Le 29/08/17 a 18:00, Alexander.Steffen@infineon.com a >>> ecrit : >>> > > > > > > >>> An idea how to troubleshoot this? >>> > > > > > > >> Can you run git bisect on the changes between 4.11 and >>> > > > 4.12, so that >>> > > > > > > >> we find the offending commit? It is probably sufficient >>> > > > to limit the >>> > > > > > > >> search to commits that touch something in >>> drivers/char/tpm. >>> > > > > > > > >>> > > > > > > > I'll try and keep you posted. >>> > > > > > > >>> > > > > > > OK I've been able to bisect the problem and the bad >>> commit is: >>> > > > > > > >>> > > > > > > e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first >>> bad commit >>> > > > > > > commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >>> > > > > > > Author: Jerry Snitselaar <jsnitsel@redhat.com> >>> > > > > > > Date: Mon Mar 27 08:46:04 2017 -0700 >>> > > > > > > >>> > > > > > > tpm_tis: convert to using locality callbacks >>> > > > > > > >>> > > > > > > This patch converts tpm_tis to use of the new tpm >>> class ops >>> > > > > > > request_locality, and relinquish_locality. >>> > > > > > > >>> > > > > > > With the move to using the callbacks, >>> release_locality is >>> > > > > > > changed so >>> > > > > > > that we now release the locality even if there is no >>> > > > > > > request pending. >>> > > > > > > >>> > > > > > > This required some changes to the tpm_tis_core_init >>> > > > code path to >>> > > > > > > make sure locality is requested when needed: >>> > > > > > > >>> > > > > > > - tpm2_probe code path will end up calling >>> > > > > > > request/release through >>> > > > > > > callbacks, so request_locality prior to >>> > > > tpm2_probe not needed. >>> > > > > > > >>> > > > > > > - probe_itpm makes calls to tpm_tis_send_data >>> which no >>> > > > > > > longer calls >>> > > > > > > request_locality, so add request_locality prior to >>> > > > > > > tpm_tis_send_data >>> > > > > > > calls. Also drop release_locality call in middleof >>> > > > > > > probe_itpm, and >>> > > > > > > keep locality until release_locality called at >>> end of >>> > > > > > > probe_itpm. >>> > > > > > > >>> > > > > > > Cc: Peter Huewe <peterhuewe@gmx.de> >>> > > > > > > Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >>> > > > > > > Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> >>> > > > > > > Cc: Marcel Selhorst <tpmdd@selhorst.net> >>> > > > > > > Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> >>> > > > > > > Reviewed-by: Jarkko Sakkinen >>> > > > <jarkko.sakkinen@linux.intel.com> >>> > > > > > > Tested-by: Jarkko Sakkinen >>> <jarkko.sakkinen@linux.intel.com> >>> > > > > > > Signed-off-by: Jarkko Sakkinen >>> > > > <jarkko.sakkinen@linux.intel.com> >>> > > > > > > >>> > > > > > > :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >>> > > > > > > 72f21b446e45ea1003de75902b0553deb99157fd M drivers >>> > > > > > > >>> > > > > > >>> > > > > > I've looked again at the code in question, but could not find >>> > > > > > anything that is obviously wrong there. Locality is now >>> > > > > > requested/released at slightly different points in the >>> process than >>> > > > > > before, but that's it. It does not seem to cause problems >>> with the >>> > > > > > majority of TPMs, since you are the first to report any, so >>> > > > maybe it >>> > > > > > is a quirk that only affects this device. >>> > > > > > >>> > > > > > Perhaps Jerry can help, since this is his change? >>> > > > > > >>> > > > > > Alexander >>> > > > > >>> > > > > Getting some caffeine in me, and starting to take a look. >>> Adding >>> > > > > Jarkko as well since this might involve the general locality >>> changes. >>> > > > > >>> > > > > Laurent, if I send you a patch with some debugging code >>> added, would >>> > > > > you be able to run it on that system? I wasn't running into >>> issues >>> > > > > on the system I had with a 1.2 device, but I no longer have >>> access >>> > > > > to it. I'll see if I can find one in our labs and reproduce >>> it there. >>> > > > >>> > > > Yes I should be able to do that >>> > > >>> > > Any findings? >>> > > >>> > > /Jarkko >>> > >>> > Okay, finally getting back to this. Looking at the code it isn't >>> clear >>> > to me >>> > why the change is causing this. So while I stare at this some more >>> > Laurent >>> > could you reproduce it with this patch so I can see what the >>> status and >>> > access registers look like? Does anyone else on here happen to have a >>> > Sinosun >>> > tpm device? The systems I have access to with TPM1.2 devices don't >>> have >>> > this >>> > issue. >>> > >>> > --8<-- >>> > >>> > diff --git a/drivers/char/tpm/tpm_tis_core.c >>> > b/drivers/char/tpm/tpm_tis_core.c >>> > index fdde971bc810..7d60a7e4b50a 100644 >>> > --- a/drivers/char/tpm/tpm_tis_core.c >>> > +++ b/drivers/char/tpm/tpm_tis_core.c >>> > @@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct tpm_chip >>> *chip, >>> > const u8 *buf, size_t len) >>> > int rc, status, burstcnt; >>> > size_t count = 0; >>> > bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; >>> > + u8 access; >>> > >>> > status = tpm_tis_status(chip); >>> > if ((status & TPM_STS_COMMAND_READY) == 0) { >>> > @@ -292,6 +293,11 @@ static int tpm_tis_send_data(struct tpm_chip >>> *chip, >>> > const u8 *buf, size_t len) >>> > } >>> > status = tpm_tis_status(chip); >>> > if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { >>> > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), >>> > &access); >>> > + if (rc < 0) >>> > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: read >>> > failure TPM_ACCESS(%d)\n", priv->locality); >>> > + else >>> > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: >>> > locality: %d status: %x access: %x\n", priv->locality, status, >>> access); >>> > rc = -EIO; >>> > goto out_err; >>> > } >>> > @@ -309,6 +315,11 @@ static int tpm_tis_send_data(struct tpm_chip >>> *chip, >>> > const u8 *buf, size_t len) >>> > } >>> > status = tpm_tis_status(chip); >>> > if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { >>> > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), >>> &access); >>> > + if (rc < 0) >>> > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read >>> > failure TPM_ACCESS(%d)\n", priv->locality); >>> > + else >>> > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: >>> locality: >>> > %d status: %x access: %x\n", priv->locality, status, access); >>> > rc = -EIO; >>> > goto out_err; >>> > } >>> >>> Please find here the dmesg output of the patched kernel >> >> At least 0xff is corrupted value in senseful way. CPU fills the read >> with ones for example for unaligned bus read. See table 19 in PC client >> spec. This can happen when you do unaligned read for example. >> >> Maybe TPM is unreachable i.e. powered off. Bit busy with stuff ATM but >> would probably make sense to compare that 0x81 to table 18 in the same >> spec. >> >> /Jarkko > > 0x81 is saying the access register status is valid, and the locality > is not active. That first bit means A Dynamic OS has not been previously > established on the platform. Normally we would see 0xa1, which would > mean valid register status, and the locality is active. FTR, the ownership has been claimed using tpm-tools on linux, but I configured windows 10 (dual-boot) on the machine to do its magic to recognize the tpm chip by entering the owner password manually there, not sure if that matters. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: tpm device not showing up in /dev anymore @ 2017-10-23 13:48 ` Laurent Bigonville 0 siblings, 0 replies; 62+ messages in thread From: Laurent Bigonville @ 2017-10-23 13:48 UTC (permalink / raw) To: Jerry Snitselaar, Jarkko Sakkinen Cc: linux-integrity-u79uwXL29TY76Z2rM5mHXA, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Le 23/10/17 à 15:45, Jerry Snitselaar a écrit : > On Mon Oct 23 17, Jarkko Sakkinen wrote: >> On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote: >>> Le 14/10/17 à 10:13, Jerry Snitselaar a écrit : >>> > On Wed Sep 06 17, Jarkko Sakkinen wrote: >>> > > On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent Bigonville wrote: >>> > > > Le 31/08/17 à 18:40, Jerry Snitselaar a écrit : >>> > > > > On Thu Aug 31 17, Alexander.Steffen@infineon.com wrote: >>> > > > > > > Le 29/08/17 à 18:35, Laurent Bigonville a écrit : >>> > > > > > > > Le 29/08/17 à 18:00, Alexander.Steffen@infineon.com a >>> écrit : >>> > > > > > > >>> An idea how to troubleshoot this? >>> > > > > > > >> Can you run git bisect on the changes between 4.11 and >>> > > > 4.12, so that >>> > > > > > > >> we find the offending commit? It is probably sufficient >>> > > > to limit the >>> > > > > > > >> search to commits that touch something in >>> drivers/char/tpm. >>> > > > > > > > >>> > > > > > > > I'll try and keep you posted. >>> > > > > > > >>> > > > > > > OK I've been able to bisect the problem and the bad >>> commit is: >>> > > > > > > >>> > > > > > > e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first >>> bad commit >>> > > > > > > commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >>> > > > > > > Author: Jerry Snitselaar <jsnitsel@redhat.com> >>> > > > > > > Date: Mon Mar 27 08:46:04 2017 -0700 >>> > > > > > > >>> > > > > > > tpm_tis: convert to using locality callbacks >>> > > > > > > >>> > > > > > > This patch converts tpm_tis to use of the new tpm >>> class ops >>> > > > > > > request_locality, and relinquish_locality. >>> > > > > > > >>> > > > > > > With the move to using the callbacks, >>> release_locality is >>> > > > > > > changed so >>> > > > > > > that we now release the locality even if there is no >>> > > > > > > request pending. >>> > > > > > > >>> > > > > > > This required some changes to the tpm_tis_core_init >>> > > > code path to >>> > > > > > > make sure locality is requested when needed: >>> > > > > > > >>> > > > > > > - tpm2_probe code path will end up calling >>> > > > > > > request/release through >>> > > > > > > callbacks, so request_locality prior to >>> > > > tpm2_probe not needed. >>> > > > > > > >>> > > > > > > - probe_itpm makes calls to tpm_tis_send_data >>> which no >>> > > > > > > longer calls >>> > > > > > > request_locality, so add request_locality prior to >>> > > > > > > tpm_tis_send_data >>> > > > > > > calls. Also drop release_locality call in middleof >>> > > > > > > probe_itpm, and >>> > > > > > > keep locality until release_locality called at >>> end of >>> > > > > > > probe_itpm. >>> > > > > > > >>> > > > > > > Cc: Peter Huewe <peterhuewe@gmx.de> >>> > > > > > > Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >>> > > > > > > Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> >>> > > > > > > Cc: Marcel Selhorst <tpmdd@selhorst.net> >>> > > > > > > Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> >>> > > > > > > Reviewed-by: Jarkko Sakkinen >>> > > > <jarkko.sakkinen@linux.intel.com> >>> > > > > > > Tested-by: Jarkko Sakkinen >>> <jarkko.sakkinen@linux.intel.com> >>> > > > > > > Signed-off-by: Jarkko Sakkinen >>> > > > <jarkko.sakkinen@linux.intel.com> >>> > > > > > > >>> > > > > > > :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >>> > > > > > > 72f21b446e45ea1003de75902b0553deb99157fd M drivers >>> > > > > > > >>> > > > > > >>> > > > > > I've looked again at the code in question, but could not find >>> > > > > > anything that is obviously wrong there. Locality is now >>> > > > > > requested/released at slightly different points in the >>> process than >>> > > > > > before, but that's it. It does not seem to cause problems >>> with the >>> > > > > > majority of TPMs, since you are the first to report any, so >>> > > > maybe it >>> > > > > > is a quirk that only affects this device. >>> > > > > > >>> > > > > > Perhaps Jerry can help, since this is his change? >>> > > > > > >>> > > > > > Alexander >>> > > > > >>> > > > > Getting some caffeine in me, and starting to take a look. >>> Adding >>> > > > > Jarkko as well since this might involve the general locality >>> changes. >>> > > > > >>> > > > > Laurent, if I send you a patch with some debugging code >>> added, would >>> > > > > you be able to run it on that system? I wasn't running into >>> issues >>> > > > > on the system I had with a 1.2 device, but I no longer have >>> access >>> > > > > to it. I'll see if I can find one in our labs and reproduce >>> it there. >>> > > > >>> > > > Yes I should be able to do that >>> > > >>> > > Any findings? >>> > > >>> > > /Jarkko >>> > >>> > Okay, finally getting back to this. Looking at the code it isn't >>> clear >>> > to me >>> > why the change is causing this. So while I stare at this some more >>> > Laurent >>> > could you reproduce it with this patch so I can see what the >>> status and >>> > access registers look like? Does anyone else on here happen to have a >>> > Sinosun >>> > tpm device? The systems I have access to with TPM1.2 devices don't >>> have >>> > this >>> > issue. >>> > >>> > --8<-- >>> > >>> > diff --git a/drivers/char/tpm/tpm_tis_core.c >>> > b/drivers/char/tpm/tpm_tis_core.c >>> > index fdde971bc810..7d60a7e4b50a 100644 >>> > --- a/drivers/char/tpm/tpm_tis_core.c >>> > +++ b/drivers/char/tpm/tpm_tis_core.c >>> > @@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct tpm_chip >>> *chip, >>> > const u8 *buf, size_t len) >>> > int rc, status, burstcnt; >>> > size_t count = 0; >>> > bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; >>> > + u8 access; >>> > >>> > status = tpm_tis_status(chip); >>> > if ((status & TPM_STS_COMMAND_READY) == 0) { >>> > @@ -292,6 +293,11 @@ static int tpm_tis_send_data(struct tpm_chip >>> *chip, >>> > const u8 *buf, size_t len) >>> > } >>> > status = tpm_tis_status(chip); >>> > if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { >>> > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), >>> > &access); >>> > + if (rc < 0) >>> > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: read >>> > failure TPM_ACCESS(%d)\n", priv->locality); >>> > + else >>> > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: >>> > locality: %d status: %x access: %x\n", priv->locality, status, >>> access); >>> > rc = -EIO; >>> > goto out_err; >>> > } >>> > @@ -309,6 +315,11 @@ static int tpm_tis_send_data(struct tpm_chip >>> *chip, >>> > const u8 *buf, size_t len) >>> > } >>> > status = tpm_tis_status(chip); >>> > if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { >>> > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), >>> &access); >>> > + if (rc < 0) >>> > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read >>> > failure TPM_ACCESS(%d)\n", priv->locality); >>> > + else >>> > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: >>> locality: >>> > %d status: %x access: %x\n", priv->locality, status, access); >>> > rc = -EIO; >>> > goto out_err; >>> > } >>> >>> Please find here the dmesg output of the patched kernel >> >> At least 0xff is corrupted value in senseful way. CPU fills the read >> with ones for example for unaligned bus read. See table 19 in PC client >> spec. This can happen when you do unaligned read for example. >> >> Maybe TPM is unreachable i.e. powered off. Bit busy with stuff ATM but >> would probably make sense to compare that 0x81 to table 18 in the same >> spec. >> >> /Jarkko > > 0x81 is saying the access register status is valid, and the locality > is not active. That first bit means A Dynamic OS has not been previously > established on the platform. Normally we would see 0xa1, which would > mean valid register status, and the locality is active. FTR, the ownership has been claimed using tpm-tools on linux, but I configured windows 10 (dual-boot) on the machine to do its magic to recognize the tpm chip by entering the owner password manually there, not sure if that matters. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ tpmdd-devel mailing list tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2017-10-23 13:45 ` Jerry Snitselaar @ 2017-10-24 13:51 ` Jarkko Sakkinen -1 siblings, 0 replies; 62+ messages in thread From: Jarkko Sakkinen @ 2017-10-24 13:51 UTC (permalink / raw) To: Jerry Snitselaar Cc: Laurent Bigonville, Alexander.Steffen, tpmdd-devel, linux-integrity On Mon, Oct 23, 2017 at 06:45:15AM -0700, Jerry Snitselaar wrote: > On Mon Oct 23 17, Jarkko Sakkinen wrote: > > On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote: > > > Le 14/10/17 a 10:13, Jerry Snitselaar a ecrit : > > > > On Wed Sep 06 17, Jarkko Sakkinen wrote: > > > > > On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent Bigonville wrote: > > > > > > Le 31/08/17 a 18:40, Jerry Snitselaar a ecrit : > > > > > > > On Thu Aug 31 17, Alexander.Steffen@infineon.com wrote: > > > > > > > > > Le 29/08/17 a 18:35, Laurent Bigonville a ecrit : > > > > > > > > > > Le 29/08/17 a 18:00, Alexander.Steffen@infineon.com a ecrit : > > > > > > > > > >>> An idea how to troubleshoot this? > > > > > > > > > >> Can you run git bisect on the changes between 4.11 and > > > > > > 4.12, so that > > > > > > > > > >> we find the offending commit? It is probably sufficient > > > > > > to limit the > > > > > > > > > >> search to commits that touch something in drivers/char/tpm. > > > > > > > > > > > > > > > > > > > > I'll try and keep you posted. > > > > > > > > > > > > > > > > > > OK I've been able to bisect the problem and the bad commit is: > > > > > > > > > > > > > > > > > > e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad commit > > > > > > > > > commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 > > > > > > > > > Author: Jerry Snitselaar <jsnitsel@redhat.com> > > > > > > > > > Date: Mon Mar 27 08:46:04 2017 -0700 > > > > > > > > > > > > > > > > > > tpm_tis: convert to using locality callbacks > > > > > > > > > > > > > > > > > > This patch converts tpm_tis to use of the new tpm class ops > > > > > > > > > request_locality, and relinquish_locality. > > > > > > > > > > > > > > > > > > With the move to using the callbacks, release_locality is > > > > > > > > > changed so > > > > > > > > > that we now release the locality even if there is no > > > > > > > > > request pending. > > > > > > > > > > > > > > > > > > This required some changes to the tpm_tis_core_init > > > > > > code path to > > > > > > > > > make sure locality is requested when needed: > > > > > > > > > > > > > > > > > > - tpm2_probe code path will end up calling > > > > > > > > > request/release through > > > > > > > > > callbacks, so request_locality prior to > > > > > > tpm2_probe not needed. > > > > > > > > > > > > > > > > > > - probe_itpm makes calls to tpm_tis_send_data which no > > > > > > > > > longer calls > > > > > > > > > request_locality, so add request_locality prior to > > > > > > > > > tpm_tis_send_data > > > > > > > > > calls. Also drop release_locality call in middleof > > > > > > > > > probe_itpm, and > > > > > > > > > keep locality until release_locality called at end of > > > > > > > > > probe_itpm. > > > > > > > > > > > > > > > > > > Cc: Peter Huewe <peterhuewe@gmx.de> > > > > > > > > > Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > > > > > > > > > Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> > > > > > > > > > Cc: Marcel Selhorst <tpmdd@selhorst.net> > > > > > > > > > Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> > > > > > > > > > Reviewed-by: Jarkko Sakkinen > > > > > > <jarkko.sakkinen@linux.intel.com> > > > > > > > > > Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > > > > > > > > > Signed-off-by: Jarkko Sakkinen > > > > > > <jarkko.sakkinen@linux.intel.com> > > > > > > > > > > > > > > > > > > :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 > > > > > > > > > 72f21b446e45ea1003de75902b0553deb99157fd M drivers > > > > > > > > > > > > > > > > > > > > > > > > > I've looked again at the code in question, but could not find > > > > > > > > anything that is obviously wrong there. Locality is now > > > > > > > > requested/released at slightly different points in the process than > > > > > > > > before, but that's it. It does not seem to cause problems with the > > > > > > > > majority of TPMs, since you are the first to report any, so > > > > > > maybe it > > > > > > > > is a quirk that only affects this device. > > > > > > > > > > > > > > > > Perhaps Jerry can help, since this is his change? > > > > > > > > > > > > > > > > Alexander > > > > > > > > > > > > > > Getting some caffeine in me, and starting to take a look. Adding > > > > > > > Jarkko as well since this might involve the general locality changes. > > > > > > > > > > > > > > Laurent, if I send you a patch with some debugging code added, would > > > > > > > you be able to run it on that system? I wasn't running into issues > > > > > > > on the system I had with a 1.2 device, but I no longer have access > > > > > > > to it. I'll see if I can find one in our labs and reproduce it there. > > > > > > > > > > > > Yes I should be able to do that > > > > > > > > > > Any findings? > > > > > > > > > > /Jarkko > > > > > > > > Okay, finally getting back to this. Looking at the code it isn't clear > > > > to me > > > > why the change is causing this. So while I stare at this some more > > > > Laurent > > > > could you reproduce it with this patch so I can see what the status and > > > > access registers look like? Does anyone else on here happen to have a > > > > Sinosun > > > > tpm device? The systems I have access to with TPM1.2 devices don't have > > > > this > > > > issue. > > > > > > > > --8<-- > > > > > > > > diff --git a/drivers/char/tpm/tpm_tis_core.c > > > > b/drivers/char/tpm/tpm_tis_core.c > > > > index fdde971bc810..7d60a7e4b50a 100644 > > > > --- a/drivers/char/tpm/tpm_tis_core.c > > > > +++ b/drivers/char/tpm/tpm_tis_core.c > > > > @@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, > > > > const u8 *buf, size_t len) > > > > int rc, status, burstcnt; > > > > size_t count = 0; > > > > bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; > > > > + u8 access; > > > > > > > > status = tpm_tis_status(chip); > > > > if ((status & TPM_STS_COMMAND_READY) == 0) { > > > > @@ -292,6 +293,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, > > > > const u8 *buf, size_t len) > > > > } > > > > status = tpm_tis_status(chip); > > > > if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { > > > > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), > > > > &access); > > > > + if (rc < 0) > > > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: read > > > > failure TPM_ACCESS(%d)\n", priv->locality); > > > > + else > > > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: > > > > locality: %d status: %x access: %x\n", priv->locality, status, access); > > > > rc = -EIO; > > > > goto out_err; > > > > } > > > > @@ -309,6 +315,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, > > > > const u8 *buf, size_t len) > > > > } > > > > status = tpm_tis_status(chip); > > > > if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { > > > > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), &access); > > > > + if (rc < 0) > > > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read > > > > failure TPM_ACCESS(%d)\n", priv->locality); > > > > + else > > > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: locality: > > > > %d status: %x access: %x\n", priv->locality, status, access); > > > > rc = -EIO; > > > > goto out_err; > > > > } > > > > > > Please find here the dmesg output of the patched kernel > > > > At least 0xff is corrupted value in senseful way. CPU fills the read > > with ones for example for unaligned bus read. See table 19 in PC client > > spec. This can happen when you do unaligned read for example. > > > > Maybe TPM is unreachable i.e. powered off. Bit busy with stuff ATM but > > would probably make sense to compare that 0x81 to table 18 in the same > > spec. > > > > /Jarkko > > 0x81 is saying the access register status is valid, and the locality > is not active. That first bit means A Dynamic OS has not been previously > established on the platform. Normally we would see 0xa1, which would > mean valid register status, and the locality is active. I think the important thing to note here is that STS has bits set that should never be set. So we can conclude that TPM might be either 1. Powered off 2. In some transition state? /Jarkko ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: tpm device not showing up in /dev anymore @ 2017-10-24 13:51 ` Jarkko Sakkinen 0 siblings, 0 replies; 62+ messages in thread From: Jarkko Sakkinen @ 2017-10-24 13:51 UTC (permalink / raw) To: Jerry Snitselaar Cc: linux-integrity-u79uwXL29TY76Z2rM5mHXA, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f On Mon, Oct 23, 2017 at 06:45:15AM -0700, Jerry Snitselaar wrote: > On Mon Oct 23 17, Jarkko Sakkinen wrote: > > On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote: > > > Le 14/10/17 à 10:13, Jerry Snitselaar a écrit : > > > > On Wed Sep 06 17, Jarkko Sakkinen wrote: > > > > > On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent Bigonville wrote: > > > > > > Le 31/08/17 à 18:40, Jerry Snitselaar a écrit : > > > > > > > On Thu Aug 31 17, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org wrote: > > > > > > > > > Le 29/08/17 à 18:35, Laurent Bigonville a écrit : > > > > > > > > > > Le 29/08/17 à 18:00, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org a écrit : > > > > > > > > > >>> An idea how to troubleshoot this? > > > > > > > > > >> Can you run git bisect on the changes between 4.11 and > > > > > > 4.12, so that > > > > > > > > > >> we find the offending commit? It is probably sufficient > > > > > > to limit the > > > > > > > > > >> search to commits that touch something in drivers/char/tpm. > > > > > > > > > > > > > > > > > > > > I'll try and keep you posted. > > > > > > > > > > > > > > > > > > OK I've been able to bisect the problem and the bad commit is: > > > > > > > > > > > > > > > > > > e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad commit > > > > > > > > > commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 > > > > > > > > > Author: Jerry Snitselaar <jsnitsel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > > > > > > > > Date: Mon Mar 27 08:46:04 2017 -0700 > > > > > > > > > > > > > > > > > > tpm_tis: convert to using locality callbacks > > > > > > > > > > > > > > > > > > This patch converts tpm_tis to use of the new tpm class ops > > > > > > > > > request_locality, and relinquish_locality. > > > > > > > > > > > > > > > > > > With the move to using the callbacks, release_locality is > > > > > > > > > changed so > > > > > > > > > that we now release the locality even if there is no > > > > > > > > > request pending. > > > > > > > > > > > > > > > > > > This required some changes to the tpm_tis_core_init > > > > > > code path to > > > > > > > > > make sure locality is requested when needed: > > > > > > > > > > > > > > > > > > - tpm2_probe code path will end up calling > > > > > > > > > request/release through > > > > > > > > > callbacks, so request_locality prior to > > > > > > tpm2_probe not needed. > > > > > > > > > > > > > > > > > > - probe_itpm makes calls to tpm_tis_send_data which no > > > > > > > > > longer calls > > > > > > > > > request_locality, so add request_locality prior to > > > > > > > > > tpm_tis_send_data > > > > > > > > > calls. Also drop release_locality call in middleof > > > > > > > > > probe_itpm, and > > > > > > > > > keep locality until release_locality called at end of > > > > > > > > > probe_itpm. > > > > > > > > > > > > > > > > > > Cc: Peter Huewe <peterhuewe-Mmb7MZpHnFY@public.gmane.org> > > > > > > > > > Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > > > > > > > > > Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> > > > > > > > > > Cc: Marcel Selhorst <tpmdd-yWjUBOtONefk1uMJSBkQmQ@public.gmane.org> > > > > > > > > > Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> > > > > > > > > > Reviewed-by: Jarkko Sakkinen > > > > > > <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> > > > > > > > > > Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > > > > > > > > > Signed-off-by: Jarkko Sakkinen > > > > > > <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> > > > > > > > > > > > > > > > > > > :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 > > > > > > > > > 72f21b446e45ea1003de75902b0553deb99157fd M drivers > > > > > > > > > > > > > > > > > > > > > > > > > I've looked again at the code in question, but could not find > > > > > > > > anything that is obviously wrong there. Locality is now > > > > > > > > requested/released at slightly different points in the process than > > > > > > > > before, but that's it. It does not seem to cause problems with the > > > > > > > > majority of TPMs, since you are the first to report any, so > > > > > > maybe it > > > > > > > > is a quirk that only affects this device. > > > > > > > > > > > > > > > > Perhaps Jerry can help, since this is his change? > > > > > > > > > > > > > > > > Alexander > > > > > > > > > > > > > > Getting some caffeine in me, and starting to take a look. Adding > > > > > > > Jarkko as well since this might involve the general locality changes. > > > > > > > > > > > > > > Laurent, if I send you a patch with some debugging code added, would > > > > > > > you be able to run it on that system? I wasn't running into issues > > > > > > > on the system I had with a 1.2 device, but I no longer have access > > > > > > > to it. I'll see if I can find one in our labs and reproduce it there. > > > > > > > > > > > > Yes I should be able to do that > > > > > > > > > > Any findings? > > > > > > > > > > /Jarkko > > > > > > > > Okay, finally getting back to this. Looking at the code it isn't clear > > > > to me > > > > why the change is causing this. So while I stare at this some more > > > > Laurent > > > > could you reproduce it with this patch so I can see what the status and > > > > access registers look like? Does anyone else on here happen to have a > > > > Sinosun > > > > tpm device? The systems I have access to with TPM1.2 devices don't have > > > > this > > > > issue. > > > > > > > > --8<-- > > > > > > > > diff --git a/drivers/char/tpm/tpm_tis_core.c > > > > b/drivers/char/tpm/tpm_tis_core.c > > > > index fdde971bc810..7d60a7e4b50a 100644 > > > > --- a/drivers/char/tpm/tpm_tis_core.c > > > > +++ b/drivers/char/tpm/tpm_tis_core.c > > > > @@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, > > > > const u8 *buf, size_t len) > > > > int rc, status, burstcnt; > > > > size_t count = 0; > > > > bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; > > > > + u8 access; > > > > > > > > status = tpm_tis_status(chip); > > > > if ((status & TPM_STS_COMMAND_READY) == 0) { > > > > @@ -292,6 +293,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, > > > > const u8 *buf, size_t len) > > > > } > > > > status = tpm_tis_status(chip); > > > > if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { > > > > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), > > > > &access); > > > > + if (rc < 0) > > > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: read > > > > failure TPM_ACCESS(%d)\n", priv->locality); > > > > + else > > > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: > > > > locality: %d status: %x access: %x\n", priv->locality, status, access); > > > > rc = -EIO; > > > > goto out_err; > > > > } > > > > @@ -309,6 +315,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, > > > > const u8 *buf, size_t len) > > > > } > > > > status = tpm_tis_status(chip); > > > > if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { > > > > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), &access); > > > > + if (rc < 0) > > > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read > > > > failure TPM_ACCESS(%d)\n", priv->locality); > > > > + else > > > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: locality: > > > > %d status: %x access: %x\n", priv->locality, status, access); > > > > rc = -EIO; > > > > goto out_err; > > > > } > > > > > > Please find here the dmesg output of the patched kernel > > > > At least 0xff is corrupted value in senseful way. CPU fills the read > > with ones for example for unaligned bus read. See table 19 in PC client > > spec. This can happen when you do unaligned read for example. > > > > Maybe TPM is unreachable i.e. powered off. Bit busy with stuff ATM but > > would probably make sense to compare that 0x81 to table 18 in the same > > spec. > > > > /Jarkko > > 0x81 is saying the access register status is valid, and the locality > is not active. That first bit means A Dynamic OS has not been previously > established on the platform. Normally we would see 0xa1, which would > mean valid register status, and the locality is active. I think the important thing to note here is that STS has bits set that should never be set. So we can conclude that TPM might be either 1. Powered off 2. In some transition state? /Jarkko ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore @ 2017-10-24 14:57 ` Jerry Snitselaar 0 siblings, 0 replies; 62+ messages in thread From: Jerry Snitselaar @ 2017-10-24 14:57 UTC (permalink / raw) To: Jarkko Sakkinen Cc: Laurent Bigonville, Alexander.Steffen, tpmdd-devel, linux-integrity On Tue Oct 24 17, Jarkko Sakkinen wrote: >On Mon, Oct 23, 2017 at 06:45:15AM -0700, Jerry Snitselaar wrote: >> On Mon Oct 23 17, Jarkko Sakkinen wrote: >> > On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote: >> > > Le 14/10/17 a 10:13, Jerry Snitselaar a ecrit : >> > > > On Wed Sep 06 17, Jarkko Sakkinen wrote: >> > > > > On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent Bigonville wrote: >> > > > > > Le 31/08/17 a 18:40, Jerry Snitselaar a ecrit : >> > > > > > > On Thu Aug 31 17, Alexander.Steffen@infineon.com wrote: >> > > > > > > > > Le 29/08/17 a 18:35, Laurent Bigonville a ecrit : >> > > > > > > > > > Le 29/08/17 a 18:00, Alexander.Steffen@infineon.com a ecrit : >> > > > > > > > > >>> An idea how to troubleshoot this? >> > > > > > > > > >> Can you run git bisect on the changes between 4.11 and >> > > > > > 4.12, so that >> > > > > > > > > >> we find the offending commit? It is probably sufficient >> > > > > > to limit the >> > > > > > > > > >> search to commits that touch something in drivers/char/tpm. >> > > > > > > > > > >> > > > > > > > > > I'll try and keep you posted. >> > > > > > > > > >> > > > > > > > > OK I've been able to bisect the problem and the bad commit is: >> > > > > > > > > >> > > > > > > > > e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad commit >> > > > > > > > > commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >> > > > > > > > > Author: Jerry Snitselaar <jsnitsel@redhat.com> >> > > > > > > > > Date: Mon Mar 27 08:46:04 2017 -0700 >> > > > > > > > > >> > > > > > > > > tpm_tis: convert to using locality callbacks >> > > > > > > > > >> > > > > > > > > This patch converts tpm_tis to use of the new tpm class ops >> > > > > > > > > request_locality, and relinquish_locality. >> > > > > > > > > >> > > > > > > > > With the move to using the callbacks, release_locality is >> > > > > > > > > changed so >> > > > > > > > > that we now release the locality even if there is no >> > > > > > > > > request pending. >> > > > > > > > > >> > > > > > > > > This required some changes to the tpm_tis_core_init >> > > > > > code path to >> > > > > > > > > make sure locality is requested when needed: >> > > > > > > > > >> > > > > > > > > - tpm2_probe code path will end up calling >> > > > > > > > > request/release through >> > > > > > > > > callbacks, so request_locality prior to >> > > > > > tpm2_probe not needed. >> > > > > > > > > >> > > > > > > > > - probe_itpm makes calls to tpm_tis_send_data which no >> > > > > > > > > longer calls >> > > > > > > > > request_locality, so add request_locality prior to >> > > > > > > > > tpm_tis_send_data >> > > > > > > > > calls. Also drop release_locality call in middleof >> > > > > > > > > probe_itpm, and >> > > > > > > > > keep locality until release_locality called at end of >> > > > > > > > > probe_itpm. >> > > > > > > > > >> > > > > > > > > Cc: Peter Huewe <peterhuewe@gmx.de> >> > > > > > > > > Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >> > > > > > > > > Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> >> > > > > > > > > Cc: Marcel Selhorst <tpmdd@selhorst.net> >> > > > > > > > > Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> >> > > > > > > > > Reviewed-by: Jarkko Sakkinen >> > > > > > <jarkko.sakkinen@linux.intel.com> >> > > > > > > > > Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >> > > > > > > > > Signed-off-by: Jarkko Sakkinen >> > > > > > <jarkko.sakkinen@linux.intel.com> >> > > > > > > > > >> > > > > > > > > :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >> > > > > > > > > 72f21b446e45ea1003de75902b0553deb99157fd M drivers >> > > > > > > > > >> > > > > > > > >> > > > > > > > I've looked again at the code in question, but could not find >> > > > > > > > anything that is obviously wrong there. Locality is now >> > > > > > > > requested/released at slightly different points in the process than >> > > > > > > > before, but that's it. It does not seem to cause problems with the >> > > > > > > > majority of TPMs, since you are the first to report any, so >> > > > > > maybe it >> > > > > > > > is a quirk that only affects this device. >> > > > > > > > >> > > > > > > > Perhaps Jerry can help, since this is his change? >> > > > > > > > >> > > > > > > > Alexander >> > > > > > > >> > > > > > > Getting some caffeine in me, and starting to take a look. Adding >> > > > > > > Jarkko as well since this might involve the general locality changes. >> > > > > > > >> > > > > > > Laurent, if I send you a patch with some debugging code added, would >> > > > > > > you be able to run it on that system? I wasn't running into issues >> > > > > > > on the system I had with a 1.2 device, but I no longer have access >> > > > > > > to it. I'll see if I can find one in our labs and reproduce it there. >> > > > > > >> > > > > > Yes I should be able to do that >> > > > > >> > > > > Any findings? >> > > > > >> > > > > /Jarkko >> > > > >> > > > Okay, finally getting back to this. Looking at the code it isn't clear >> > > > to me >> > > > why the change is causing this. So while I stare at this some more >> > > > Laurent >> > > > could you reproduce it with this patch so I can see what the status and >> > > > access registers look like? Does anyone else on here happen to have a >> > > > Sinosun >> > > > tpm device? The systems I have access to with TPM1.2 devices don't have >> > > > this >> > > > issue. >> > > > >> > > > --8<-- >> > > > >> > > > diff --git a/drivers/char/tpm/tpm_tis_core.c >> > > > b/drivers/char/tpm/tpm_tis_core.c >> > > > index fdde971bc810..7d60a7e4b50a 100644 >> > > > --- a/drivers/char/tpm/tpm_tis_core.c >> > > > +++ b/drivers/char/tpm/tpm_tis_core.c >> > > > @@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >> > > > const u8 *buf, size_t len) >> > > > int rc, status, burstcnt; >> > > > size_t count = 0; >> > > > bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; >> > > > + u8 access; >> > > > >> > > > status = tpm_tis_status(chip); >> > > > if ((status & TPM_STS_COMMAND_READY) == 0) { >> > > > @@ -292,6 +293,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >> > > > const u8 *buf, size_t len) >> > > > } >> > > > status = tpm_tis_status(chip); >> > > > if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { >> > > > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), >> > > > &access); >> > > > + if (rc < 0) >> > > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: read >> > > > failure TPM_ACCESS(%d)\n", priv->locality); >> > > > + else >> > > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: >> > > > locality: %d status: %x access: %x\n", priv->locality, status, access); >> > > > rc = -EIO; >> > > > goto out_err; >> > > > } >> > > > @@ -309,6 +315,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >> > > > const u8 *buf, size_t len) >> > > > } >> > > > status = tpm_tis_status(chip); >> > > > if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { >> > > > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), &access); >> > > > + if (rc < 0) >> > > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read >> > > > failure TPM_ACCESS(%d)\n", priv->locality); >> > > > + else >> > > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: locality: >> > > > %d status: %x access: %x\n", priv->locality, status, access); >> > > > rc = -EIO; >> > > > goto out_err; >> > > > } >> > > >> > > Please find here the dmesg output of the patched kernel >> > >> > At least 0xff is corrupted value in senseful way. CPU fills the read >> > with ones for example for unaligned bus read. See table 19 in PC client >> > spec. This can happen when you do unaligned read for example. >> > >> > Maybe TPM is unreachable i.e. powered off. Bit busy with stuff ATM but >> > would probably make sense to compare that 0x81 to table 18 in the same >> > spec. >> > >> > /Jarkko >> >> 0x81 is saying the access register status is valid, and the locality >> is not active. That first bit means A Dynamic OS has not been previously >> established on the platform. Normally we would see 0xa1, which would >> mean valid register status, and the locality is active. > >I think the important thing to note here is that STS has bits set that >should never be set. So we can conclude that TPM might be either > >1. Powered off >2. In some transition state? > >/Jarkko If it was powered off would we be getting a valid read from the access register? ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: tpm device not showing up in /dev anymore @ 2017-10-24 14:57 ` Jerry Snitselaar 0 siblings, 0 replies; 62+ messages in thread From: Jerry Snitselaar @ 2017-10-24 14:57 UTC (permalink / raw) To: Jarkko Sakkinen Cc: linux-integrity-u79uwXL29TY76Z2rM5mHXA, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f On Tue Oct 24 17, Jarkko Sakkinen wrote: >On Mon, Oct 23, 2017 at 06:45:15AM -0700, Jerry Snitselaar wrote: >> On Mon Oct 23 17, Jarkko Sakkinen wrote: >> > On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote: >> > > Le 14/10/17 à 10:13, Jerry Snitselaar a écrit : >> > > > On Wed Sep 06 17, Jarkko Sakkinen wrote: >> > > > > On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent Bigonville wrote: >> > > > > > Le 31/08/17 à 18:40, Jerry Snitselaar a écrit : >> > > > > > > On Thu Aug 31 17, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org wrote: >> > > > > > > > > Le 29/08/17 à 18:35, Laurent Bigonville a écrit : >> > > > > > > > > > Le 29/08/17 à 18:00, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org a écrit : >> > > > > > > > > >>> An idea how to troubleshoot this? >> > > > > > > > > >> Can you run git bisect on the changes between 4.11 and >> > > > > > 4.12, so that >> > > > > > > > > >> we find the offending commit? It is probably sufficient >> > > > > > to limit the >> > > > > > > > > >> search to commits that touch something in drivers/char/tpm. >> > > > > > > > > > >> > > > > > > > > > I'll try and keep you posted. >> > > > > > > > > >> > > > > > > > > OK I've been able to bisect the problem and the bad commit is: >> > > > > > > > > >> > > > > > > > > e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad commit >> > > > > > > > > commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >> > > > > > > > > Author: Jerry Snitselaar <jsnitsel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> >> > > > > > > > > Date: Mon Mar 27 08:46:04 2017 -0700 >> > > > > > > > > >> > > > > > > > > tpm_tis: convert to using locality callbacks >> > > > > > > > > >> > > > > > > > > This patch converts tpm_tis to use of the new tpm class ops >> > > > > > > > > request_locality, and relinquish_locality. >> > > > > > > > > >> > > > > > > > > With the move to using the callbacks, release_locality is >> > > > > > > > > changed so >> > > > > > > > > that we now release the locality even if there is no >> > > > > > > > > request pending. >> > > > > > > > > >> > > > > > > > > This required some changes to the tpm_tis_core_init >> > > > > > code path to >> > > > > > > > > make sure locality is requested when needed: >> > > > > > > > > >> > > > > > > > > - tpm2_probe code path will end up calling >> > > > > > > > > request/release through >> > > > > > > > > callbacks, so request_locality prior to >> > > > > > tpm2_probe not needed. >> > > > > > > > > >> > > > > > > > > - probe_itpm makes calls to tpm_tis_send_data which no >> > > > > > > > > longer calls >> > > > > > > > > request_locality, so add request_locality prior to >> > > > > > > > > tpm_tis_send_data >> > > > > > > > > calls. Also drop release_locality call in middleof >> > > > > > > > > probe_itpm, and >> > > > > > > > > keep locality until release_locality called at end of >> > > > > > > > > probe_itpm. >> > > > > > > > > >> > > > > > > > > Cc: Peter Huewe <peterhuewe-Mmb7MZpHnFY@public.gmane.org> >> > > > > > > > > Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >> > > > > > > > > Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> >> > > > > > > > > Cc: Marcel Selhorst <tpmdd-yWjUBOtONefk1uMJSBkQmQ@public.gmane.org> >> > > > > > > > > Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> >> > > > > > > > > Reviewed-by: Jarkko Sakkinen >> > > > > > <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> >> > > > > > > > > Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >> > > > > > > > > Signed-off-by: Jarkko Sakkinen >> > > > > > <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> >> > > > > > > > > >> > > > > > > > > :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >> > > > > > > > > 72f21b446e45ea1003de75902b0553deb99157fd M drivers >> > > > > > > > > >> > > > > > > > >> > > > > > > > I've looked again at the code in question, but could not find >> > > > > > > > anything that is obviously wrong there. Locality is now >> > > > > > > > requested/released at slightly different points in the process than >> > > > > > > > before, but that's it. It does not seem to cause problems with the >> > > > > > > > majority of TPMs, since you are the first to report any, so >> > > > > > maybe it >> > > > > > > > is a quirk that only affects this device. >> > > > > > > > >> > > > > > > > Perhaps Jerry can help, since this is his change? >> > > > > > > > >> > > > > > > > Alexander >> > > > > > > >> > > > > > > Getting some caffeine in me, and starting to take a look. Adding >> > > > > > > Jarkko as well since this might involve the general locality changes. >> > > > > > > >> > > > > > > Laurent, if I send you a patch with some debugging code added, would >> > > > > > > you be able to run it on that system? I wasn't running into issues >> > > > > > > on the system I had with a 1.2 device, but I no longer have access >> > > > > > > to it. I'll see if I can find one in our labs and reproduce it there. >> > > > > > >> > > > > > Yes I should be able to do that >> > > > > >> > > > > Any findings? >> > > > > >> > > > > /Jarkko >> > > > >> > > > Okay, finally getting back to this. Looking at the code it isn't clear >> > > > to me >> > > > why the change is causing this. So while I stare at this some more >> > > > Laurent >> > > > could you reproduce it with this patch so I can see what the status and >> > > > access registers look like? Does anyone else on here happen to have a >> > > > Sinosun >> > > > tpm device? The systems I have access to with TPM1.2 devices don't have >> > > > this >> > > > issue. >> > > > >> > > > --8<-- >> > > > >> > > > diff --git a/drivers/char/tpm/tpm_tis_core.c >> > > > b/drivers/char/tpm/tpm_tis_core.c >> > > > index fdde971bc810..7d60a7e4b50a 100644 >> > > > --- a/drivers/char/tpm/tpm_tis_core.c >> > > > +++ b/drivers/char/tpm/tpm_tis_core.c >> > > > @@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >> > > > const u8 *buf, size_t len) >> > > > int rc, status, burstcnt; >> > > > size_t count = 0; >> > > > bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; >> > > > + u8 access; >> > > > >> > > > status = tpm_tis_status(chip); >> > > > if ((status & TPM_STS_COMMAND_READY) == 0) { >> > > > @@ -292,6 +293,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >> > > > const u8 *buf, size_t len) >> > > > } >> > > > status = tpm_tis_status(chip); >> > > > if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { >> > > > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), >> > > > &access); >> > > > + if (rc < 0) >> > > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: read >> > > > failure TPM_ACCESS(%d)\n", priv->locality); >> > > > + else >> > > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: >> > > > locality: %d status: %x access: %x\n", priv->locality, status, access); >> > > > rc = -EIO; >> > > > goto out_err; >> > > > } >> > > > @@ -309,6 +315,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >> > > > const u8 *buf, size_t len) >> > > > } >> > > > status = tpm_tis_status(chip); >> > > > if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { >> > > > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), &access); >> > > > + if (rc < 0) >> > > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read >> > > > failure TPM_ACCESS(%d)\n", priv->locality); >> > > > + else >> > > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: locality: >> > > > %d status: %x access: %x\n", priv->locality, status, access); >> > > > rc = -EIO; >> > > > goto out_err; >> > > > } >> > > >> > > Please find here the dmesg output of the patched kernel >> > >> > At least 0xff is corrupted value in senseful way. CPU fills the read >> > with ones for example for unaligned bus read. See table 19 in PC client >> > spec. This can happen when you do unaligned read for example. >> > >> > Maybe TPM is unreachable i.e. powered off. Bit busy with stuff ATM but >> > would probably make sense to compare that 0x81 to table 18 in the same >> > spec. >> > >> > /Jarkko >> >> 0x81 is saying the access register status is valid, and the locality >> is not active. That first bit means A Dynamic OS has not been previously >> established on the platform. Normally we would see 0xa1, which would >> mean valid register status, and the locality is active. > >I think the important thing to note here is that STS has bits set that >should never be set. So we can conclude that TPM might be either > >1. Powered off >2. In some transition state? > >/Jarkko If it was powered off would we be getting a valid read from the access register? ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2017-10-24 14:57 ` Jerry Snitselaar @ 2017-10-24 16:07 ` Jarkko Sakkinen -1 siblings, 0 replies; 62+ messages in thread From: Jarkko Sakkinen @ 2017-10-24 16:07 UTC (permalink / raw) To: Jerry Snitselaar Cc: Laurent Bigonville, Alexander.Steffen, tpmdd-devel, linux-integrity On Tue, Oct 24, 2017 at 07:57:06AM -0700, Jerry Snitselaar wrote: > On Tue Oct 24 17, Jarkko Sakkinen wrote: > > On Mon, Oct 23, 2017 at 06:45:15AM -0700, Jerry Snitselaar wrote: > > > On Mon Oct 23 17, Jarkko Sakkinen wrote: > > > > On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote: > > > > > Le 14/10/17 a 10:13, Jerry Snitselaar a ecrit : > > > > > > On Wed Sep 06 17, Jarkko Sakkinen wrote: > > > > > > > On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent Bigonville wrote: > > > > > > > > Le 31/08/17 a 18:40, Jerry Snitselaar a ecrit : > > > > > > > > > On Thu Aug 31 17, Alexander.Steffen@infineon.com wrote: > > > > > > > > > > > Le 29/08/17 a 18:35, Laurent Bigonville a ecrit : > > > > > > > > > > > > Le 29/08/17 a 18:00, Alexander.Steffen@infineon.com a ecrit : > > > > > > > > > > > >>> An idea how to troubleshoot this? > > > > > > > > > > > >> Can you run git bisect on the changes between 4.11 and > > > > > > > > 4.12, so that > > > > > > > > > > > >> we find the offending commit? It is probably sufficient > > > > > > > > to limit the > > > > > > > > > > > >> search to commits that touch something in drivers/char/tpm. > > > > > > > > > > > > > > > > > > > > > > > > I'll try and keep you posted. > > > > > > > > > > > > > > > > > > > > > > OK I've been able to bisect the problem and the bad commit is: > > > > > > > > > > > > > > > > > > > > > > e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad commit > > > > > > > > > > > commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 > > > > > > > > > > > Author: Jerry Snitselaar <jsnitsel@redhat.com> > > > > > > > > > > > Date: Mon Mar 27 08:46:04 2017 -0700 > > > > > > > > > > > > > > > > > > > > > > tpm_tis: convert to using locality callbacks > > > > > > > > > > > > > > > > > > > > > > This patch converts tpm_tis to use of the new tpm class ops > > > > > > > > > > > request_locality, and relinquish_locality. > > > > > > > > > > > > > > > > > > > > > > With the move to using the callbacks, release_locality is > > > > > > > > > > > changed so > > > > > > > > > > > that we now release the locality even if there is no > > > > > > > > > > > request pending. > > > > > > > > > > > > > > > > > > > > > > This required some changes to the tpm_tis_core_init > > > > > > > > code path to > > > > > > > > > > > make sure locality is requested when needed: > > > > > > > > > > > > > > > > > > > > > > - tpm2_probe code path will end up calling > > > > > > > > > > > request/release through > > > > > > > > > > > callbacks, so request_locality prior to > > > > > > > > tpm2_probe not needed. > > > > > > > > > > > > > > > > > > > > > > - probe_itpm makes calls to tpm_tis_send_data which no > > > > > > > > > > > longer calls > > > > > > > > > > > request_locality, so add request_locality prior to > > > > > > > > > > > tpm_tis_send_data > > > > > > > > > > > calls. Also drop release_locality call in middleof > > > > > > > > > > > probe_itpm, and > > > > > > > > > > > keep locality until release_locality called at end of > > > > > > > > > > > probe_itpm. > > > > > > > > > > > > > > > > > > > > > > Cc: Peter Huewe <peterhuewe@gmx.de> > > > > > > > > > > > Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > > > > > > > > > > > Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> > > > > > > > > > > > Cc: Marcel Selhorst <tpmdd@selhorst.net> > > > > > > > > > > > Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> > > > > > > > > > > > Reviewed-by: Jarkko Sakkinen > > > > > > > > <jarkko.sakkinen@linux.intel.com> > > > > > > > > > > > Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > > > > > > > > > > > Signed-off-by: Jarkko Sakkinen > > > > > > > > <jarkko.sakkinen@linux.intel.com> > > > > > > > > > > > > > > > > > > > > > > :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 > > > > > > > > > > > 72f21b446e45ea1003de75902b0553deb99157fd M drivers > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I've looked again at the code in question, but could not find > > > > > > > > > > anything that is obviously wrong there. Locality is now > > > > > > > > > > requested/released at slightly different points in the process than > > > > > > > > > > before, but that's it. It does not seem to cause problems with the > > > > > > > > > > majority of TPMs, since you are the first to report any, so > > > > > > > > maybe it > > > > > > > > > > is a quirk that only affects this device. > > > > > > > > > > > > > > > > > > > > Perhaps Jerry can help, since this is his change? > > > > > > > > > > > > > > > > > > > > Alexander > > > > > > > > > > > > > > > > > > Getting some caffeine in me, and starting to take a look. Adding > > > > > > > > > Jarkko as well since this might involve the general locality changes. > > > > > > > > > > > > > > > > > > Laurent, if I send you a patch with some debugging code added, would > > > > > > > > > you be able to run it on that system? I wasn't running into issues > > > > > > > > > on the system I had with a 1.2 device, but I no longer have access > > > > > > > > > to it. I'll see if I can find one in our labs and reproduce it there. > > > > > > > > > > > > > > > > Yes I should be able to do that > > > > > > > > > > > > > > Any findings? > > > > > > > > > > > > > > /Jarkko > > > > > > > > > > > > Okay, finally getting back to this. Looking at the code it isn't clear > > > > > > to me > > > > > > why the change is causing this. So while I stare at this some more > > > > > > Laurent > > > > > > could you reproduce it with this patch so I can see what the status and > > > > > > access registers look like? Does anyone else on here happen to have a > > > > > > Sinosun > > > > > > tpm device? The systems I have access to with TPM1.2 devices don't have > > > > > > this > > > > > > issue. > > > > > > > > > > > > --8<-- > > > > > > > > > > > > diff --git a/drivers/char/tpm/tpm_tis_core.c > > > > > > b/drivers/char/tpm/tpm_tis_core.c > > > > > > index fdde971bc810..7d60a7e4b50a 100644 > > > > > > --- a/drivers/char/tpm/tpm_tis_core.c > > > > > > +++ b/drivers/char/tpm/tpm_tis_core.c > > > > > > @@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, > > > > > > const u8 *buf, size_t len) > > > > > > int rc, status, burstcnt; > > > > > > size_t count = 0; > > > > > > bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; > > > > > > + u8 access; > > > > > > > > > > > > status = tpm_tis_status(chip); > > > > > > if ((status & TPM_STS_COMMAND_READY) == 0) { > > > > > > @@ -292,6 +293,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, > > > > > > const u8 *buf, size_t len) > > > > > > } > > > > > > status = tpm_tis_status(chip); > > > > > > if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { > > > > > > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), > > > > > > &access); > > > > > > + if (rc < 0) > > > > > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: read > > > > > > failure TPM_ACCESS(%d)\n", priv->locality); > > > > > > + else > > > > > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: > > > > > > locality: %d status: %x access: %x\n", priv->locality, status, access); > > > > > > rc = -EIO; > > > > > > goto out_err; > > > > > > } > > > > > > @@ -309,6 +315,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, > > > > > > const u8 *buf, size_t len) > > > > > > } > > > > > > status = tpm_tis_status(chip); > > > > > > if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { > > > > > > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), &access); > > > > > > + if (rc < 0) > > > > > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read > > > > > > failure TPM_ACCESS(%d)\n", priv->locality); > > > > > > + else > > > > > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: locality: > > > > > > %d status: %x access: %x\n", priv->locality, status, access); > > > > > > rc = -EIO; > > > > > > goto out_err; > > > > > > } > > > > > > > > > > Please find here the dmesg output of the patched kernel > > > > > > > > At least 0xff is corrupted value in senseful way. CPU fills the read > > > > with ones for example for unaligned bus read. See table 19 in PC client > > > > spec. This can happen when you do unaligned read for example. > > > > > > > > Maybe TPM is unreachable i.e. powered off. Bit busy with stuff ATM but > > > > would probably make sense to compare that 0x81 to table 18 in the same > > > > spec. > > > > > > > > /Jarkko > > > > > > 0x81 is saying the access register status is valid, and the locality > > > is not active. That first bit means A Dynamic OS has not been previously > > > established on the platform. Normally we would see 0xa1, which would > > > mean valid register status, and the locality is active. > > > > I think the important thing to note here is that STS has bits set that > > should never be set. So we can conclude that TPM might be either > > > > 1. Powered off > > 2. In some transition state? > > > > /Jarkko > > If it was powered off would we be getting a valid read from the access > register? I think there is no universal answer to that :-) Maybe adding a extra delay would be next test to make? If for random reason it is in-between states... /Jarkko ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: tpm device not showing up in /dev anymore @ 2017-10-24 16:07 ` Jarkko Sakkinen 0 siblings, 0 replies; 62+ messages in thread From: Jarkko Sakkinen @ 2017-10-24 16:07 UTC (permalink / raw) To: Jerry Snitselaar Cc: linux-integrity-u79uwXL29TY76Z2rM5mHXA, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f On Tue, Oct 24, 2017 at 07:57:06AM -0700, Jerry Snitselaar wrote: > On Tue Oct 24 17, Jarkko Sakkinen wrote: > > On Mon, Oct 23, 2017 at 06:45:15AM -0700, Jerry Snitselaar wrote: > > > On Mon Oct 23 17, Jarkko Sakkinen wrote: > > > > On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote: > > > > > Le 14/10/17 à 10:13, Jerry Snitselaar a écrit : > > > > > > On Wed Sep 06 17, Jarkko Sakkinen wrote: > > > > > > > On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent Bigonville wrote: > > > > > > > > Le 31/08/17 à 18:40, Jerry Snitselaar a écrit : > > > > > > > > > On Thu Aug 31 17, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org wrote: > > > > > > > > > > > Le 29/08/17 à 18:35, Laurent Bigonville a écrit : > > > > > > > > > > > > Le 29/08/17 à 18:00, Alexander.Steffen@infineon.com a écrit : > > > > > > > > > > > >>> An idea how to troubleshoot this? > > > > > > > > > > > >> Can you run git bisect on the changes between 4.11 and > > > > > > > > 4.12, so that > > > > > > > > > > > >> we find the offending commit? It is probably sufficient > > > > > > > > to limit the > > > > > > > > > > > >> search to commits that touch something in drivers/char/tpm. > > > > > > > > > > > > > > > > > > > > > > > > I'll try and keep you posted. > > > > > > > > > > > > > > > > > > > > > > OK I've been able to bisect the problem and the bad commit is: > > > > > > > > > > > > > > > > > > > > > > e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad commit > > > > > > > > > > > commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 > > > > > > > > > > > Author: Jerry Snitselaar <jsnitsel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > > > > > > > > > > Date: Mon Mar 27 08:46:04 2017 -0700 > > > > > > > > > > > > > > > > > > > > > > tpm_tis: convert to using locality callbacks > > > > > > > > > > > > > > > > > > > > > > This patch converts tpm_tis to use of the new tpm class ops > > > > > > > > > > > request_locality, and relinquish_locality. > > > > > > > > > > > > > > > > > > > > > > With the move to using the callbacks, release_locality is > > > > > > > > > > > changed so > > > > > > > > > > > that we now release the locality even if there is no > > > > > > > > > > > request pending. > > > > > > > > > > > > > > > > > > > > > > This required some changes to the tpm_tis_core_init > > > > > > > > code path to > > > > > > > > > > > make sure locality is requested when needed: > > > > > > > > > > > > > > > > > > > > > > - tpm2_probe code path will end up calling > > > > > > > > > > > request/release through > > > > > > > > > > > callbacks, so request_locality prior to > > > > > > > > tpm2_probe not needed. > > > > > > > > > > > > > > > > > > > > > > - probe_itpm makes calls to tpm_tis_send_data which no > > > > > > > > > > > longer calls > > > > > > > > > > > request_locality, so add request_locality prior to > > > > > > > > > > > tpm_tis_send_data > > > > > > > > > > > calls. Also drop release_locality call in middleof > > > > > > > > > > > probe_itpm, and > > > > > > > > > > > keep locality until release_locality called at end of > > > > > > > > > > > probe_itpm. > > > > > > > > > > > > > > > > > > > > > > Cc: Peter Huewe <peterhuewe-Mmb7MZpHnFY@public.gmane.org> > > > > > > > > > > > Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > > > > > > > > > > > Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> > > > > > > > > > > > Cc: Marcel Selhorst <tpmdd-yWjUBOtONefk1uMJSBkQmQ@public.gmane.org> > > > > > > > > > > > Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> > > > > > > > > > > > Reviewed-by: Jarkko Sakkinen > > > > > > > > <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> > > > > > > > > > > > Tested-by: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> > > > > > > > > > > > Signed-off-by: Jarkko Sakkinen > > > > > > > > <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> > > > > > > > > > > > > > > > > > > > > > > :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 > > > > > > > > > > > 72f21b446e45ea1003de75902b0553deb99157fd M drivers > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I've looked again at the code in question, but could not find > > > > > > > > > > anything that is obviously wrong there. Locality is now > > > > > > > > > > requested/released at slightly different points in the process than > > > > > > > > > > before, but that's it. It does not seem to cause problems with the > > > > > > > > > > majority of TPMs, since you are the first to report any, so > > > > > > > > maybe it > > > > > > > > > > is a quirk that only affects this device. > > > > > > > > > > > > > > > > > > > > Perhaps Jerry can help, since this is his change? > > > > > > > > > > > > > > > > > > > > Alexander > > > > > > > > > > > > > > > > > > Getting some caffeine in me, and starting to take a look. Adding > > > > > > > > > Jarkko as well since this might involve the general locality changes. > > > > > > > > > > > > > > > > > > Laurent, if I send you a patch with some debugging code added, would > > > > > > > > > you be able to run it on that system? I wasn't running into issues > > > > > > > > > on the system I had with a 1.2 device, but I no longer have access > > > > > > > > > to it. I'll see if I can find one in our labs and reproduce it there. > > > > > > > > > > > > > > > > Yes I should be able to do that > > > > > > > > > > > > > > Any findings? > > > > > > > > > > > > > > /Jarkko > > > > > > > > > > > > Okay, finally getting back to this. Looking at the code it isn't clear > > > > > > to me > > > > > > why the change is causing this. So while I stare at this some more > > > > > > Laurent > > > > > > could you reproduce it with this patch so I can see what the status and > > > > > > access registers look like? Does anyone else on here happen to have a > > > > > > Sinosun > > > > > > tpm device? The systems I have access to with TPM1.2 devices don't have > > > > > > this > > > > > > issue. > > > > > > > > > > > > --8<-- > > > > > > > > > > > > diff --git a/drivers/char/tpm/tpm_tis_core.c > > > > > > b/drivers/char/tpm/tpm_tis_core.c > > > > > > index fdde971bc810..7d60a7e4b50a 100644 > > > > > > --- a/drivers/char/tpm/tpm_tis_core.c > > > > > > +++ b/drivers/char/tpm/tpm_tis_core.c > > > > > > @@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, > > > > > > const u8 *buf, size_t len) > > > > > > int rc, status, burstcnt; > > > > > > size_t count = 0; > > > > > > bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; > > > > > > + u8 access; > > > > > > > > > > > > status = tpm_tis_status(chip); > > > > > > if ((status & TPM_STS_COMMAND_READY) == 0) { > > > > > > @@ -292,6 +293,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, > > > > > > const u8 *buf, size_t len) > > > > > > } > > > > > > status = tpm_tis_status(chip); > > > > > > if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { > > > > > > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), > > > > > > &access); > > > > > > + if (rc < 0) > > > > > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: read > > > > > > failure TPM_ACCESS(%d)\n", priv->locality); > > > > > > + else > > > > > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: > > > > > > locality: %d status: %x access: %x\n", priv->locality, status, access); > > > > > > rc = -EIO; > > > > > > goto out_err; > > > > > > } > > > > > > @@ -309,6 +315,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, > > > > > > const u8 *buf, size_t len) > > > > > > } > > > > > > status = tpm_tis_status(chip); > > > > > > if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { > > > > > > + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), &access); > > > > > > + if (rc < 0) > > > > > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read > > > > > > failure TPM_ACCESS(%d)\n", priv->locality); > > > > > > + else > > > > > > + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: locality: > > > > > > %d status: %x access: %x\n", priv->locality, status, access); > > > > > > rc = -EIO; > > > > > > goto out_err; > > > > > > } > > > > > > > > > > Please find here the dmesg output of the patched kernel > > > > > > > > At least 0xff is corrupted value in senseful way. CPU fills the read > > > > with ones for example for unaligned bus read. See table 19 in PC client > > > > spec. This can happen when you do unaligned read for example. > > > > > > > > Maybe TPM is unreachable i.e. powered off. Bit busy with stuff ATM but > > > > would probably make sense to compare that 0x81 to table 18 in the same > > > > spec. > > > > > > > > /Jarkko > > > > > > 0x81 is saying the access register status is valid, and the locality > > > is not active. That first bit means A Dynamic OS has not been previously > > > established on the platform. Normally we would see 0xa1, which would > > > mean valid register status, and the locality is active. > > > > I think the important thing to note here is that STS has bits set that > > should never be set. So we can conclude that TPM might be either > > > > 1. Powered off > > 2. In some transition state? > > > > /Jarkko > > If it was powered off would we be getting a valid read from the access > register? I think there is no universal answer to that :-) Maybe adding a extra delay would be next test to make? If for random reason it is in-between states... /Jarkko ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore @ 2017-11-09 0:04 ` Laurent Bigonville 0 siblings, 0 replies; 62+ messages in thread From: Laurent Bigonville @ 2017-11-09 0:04 UTC (permalink / raw) To: Jarkko Sakkinen, Jerry Snitselaar Cc: Alexander.Steffen, tpmdd-devel, linux-integrity Le 24/10/17 a 18:07, Jarkko Sakkinen a ecrit : > On Tue, Oct 24, 2017 at 07:57:06AM -0700, Jerry Snitselaar wrote: >> On Tue Oct 24 17, Jarkko Sakkinen wrote: >>> On Mon, Oct 23, 2017 at 06:45:15AM -0700, Jerry Snitselaar wrote: >>>> On Mon Oct 23 17, Jarkko Sakkinen wrote: >>>>> On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote: >>>>>> Le 14/10/17 a 10:13, Jerry Snitselaar a ecrit : >>>>>>> On Wed Sep 06 17, Jarkko Sakkinen wrote: >>>>>>>> On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent Bigonville wrote: >>>>>>>>> Le 31/08/17 a 18:40, Jerry Snitselaar a ecrit : >>>>>>>>>> On Thu Aug 31 17, Alexander.Steffen@infineon.com wrote: >>>>>>>>>>>> Le 29/08/17 a 18:35, Laurent Bigonville a ecrit : >>>>>>>>>>>>> Le 29/08/17 a 18:00, Alexander.Steffen@infineon.com a ecrit : >>>>>>>>>>>>>>> An idea how to troubleshoot this? >>>>>>>>>>>>>> Can you run git bisect on the changes between 4.11 and >>>>>>>>> 4.12, so that >>>>>>>>>>>>>> we find the offending commit? It is probably sufficient >>>>>>>>> to limit the >>>>>>>>>>>>>> search to commits that touch something in drivers/char/tpm. >>>>>>>>>>>>> I'll try and keep you posted. >>>>>>>>>>>> OK I've been able to bisect the problem and the bad commit is: >>>>>>>>>>>> >>>>>>>>>>>> e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad commit >>>>>>>>>>>> commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >>>>>>>>>>>> Author: Jerry Snitselaar <jsnitsel@redhat.com> >>>>>>>>>>>> Date: Mon Mar 27 08:46:04 2017 -0700 >>>>>>>>>>>> >>>>>>>>>>>> tpm_tis: convert to using locality callbacks >>>>>>>>>>>> >>>>>>>>>>>> This patch converts tpm_tis to use of the new tpm class ops >>>>>>>>>>>> request_locality, and relinquish_locality. >>>>>>>>>>>> >>>>>>>>>>>> With the move to using the callbacks, release_locality is >>>>>>>>>>>> changed so >>>>>>>>>>>> that we now release the locality even if there is no >>>>>>>>>>>> request pending. >>>>>>>>>>>> >>>>>>>>>>>> This required some changes to the tpm_tis_core_init >>>>>>>>> code path to >>>>>>>>>>>> make sure locality is requested when needed: >>>>>>>>>>>> >>>>>>>>>>>> - tpm2_probe code path will end up calling >>>>>>>>>>>> request/release through >>>>>>>>>>>> callbacks, so request_locality prior to >>>>>>>>> tpm2_probe not needed. >>>>>>>>>>>> - probe_itpm makes calls to tpm_tis_send_data which no >>>>>>>>>>>> longer calls >>>>>>>>>>>> request_locality, so add request_locality prior to >>>>>>>>>>>> tpm_tis_send_data >>>>>>>>>>>> calls. Also drop release_locality call in middleof >>>>>>>>>>>> probe_itpm, and >>>>>>>>>>>> keep locality until release_locality called at end of >>>>>>>>>>>> probe_itpm. >>>>>>>>>>>> >>>>>>>>>>>> Cc: Peter Huewe <peterhuewe@gmx.de> >>>>>>>>>>>> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>> Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> >>>>>>>>>>>> Cc: Marcel Selhorst <tpmdd@selhorst.net> >>>>>>>>>>>> Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> >>>>>>>>>>>> Reviewed-by: Jarkko Sakkinen >>>>>>>>> <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>> Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>> Signed-off-by: Jarkko Sakkinen >>>>>>>>> <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>> :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >>>>>>>>>>>> 72f21b446e45ea1003de75902b0553deb99157fd M drivers >>>>>>>>>>>> >>>>>>>>>>> I've looked again at the code in question, but could not find >>>>>>>>>>> anything that is obviously wrong there. Locality is now >>>>>>>>>>> requested/released at slightly different points in the process than >>>>>>>>>>> before, but that's it. It does not seem to cause problems with the >>>>>>>>>>> majority of TPMs, since you are the first to report any, so >>>>>>>>> maybe it >>>>>>>>>>> is a quirk that only affects this device. >>>>>>>>>>> >>>>>>>>>>> Perhaps Jerry can help, since this is his change? >>>>>>>>>>> >>>>>>>>>>> Alexander >>>>>>>>>> Getting some caffeine in me, and starting to take a look. Adding >>>>>>>>>> Jarkko as well since this might involve the general locality changes. >>>>>>>>>> >>>>>>>>>> Laurent, if I send you a patch with some debugging code added, would >>>>>>>>>> you be able to run it on that system? I wasn't running into issues >>>>>>>>>> on the system I had with a 1.2 device, but I no longer have access >>>>>>>>>> to it. I'll see if I can find one in our labs and reproduce it there. >>>>>>>>> Yes I should be able to do that >>>>>>>> Any findings? >>>>>>>> >>>>>>>> /Jarkko >>>>>>> Okay, finally getting back to this. Looking at the code it isn't clear >>>>>>> to me >>>>>>> why the change is causing this. So while I stare at this some more >>>>>>> Laurent >>>>>>> could you reproduce it with this patch so I can see what the status and >>>>>>> access registers look like? Does anyone else on here happen to have a >>>>>>> Sinosun >>>>>>> tpm device? The systems I have access to with TPM1.2 devices don't have >>>>>>> this >>>>>>> issue. >>>>>>> >>>>>>> --8<-- >>>>>>> >>>>>>> diff --git a/drivers/char/tpm/tpm_tis_core.c >>>>>>> b/drivers/char/tpm/tpm_tis_core.c >>>>>>> index fdde971bc810..7d60a7e4b50a 100644 >>>>>>> --- a/drivers/char/tpm/tpm_tis_core.c >>>>>>> +++ b/drivers/char/tpm/tpm_tis_core.c >>>>>>> @@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >>>>>>> const u8 *buf, size_t len) >>>>>>> int rc, status, burstcnt; >>>>>>> size_t count = 0; >>>>>>> bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; >>>>>>> + u8 access; >>>>>>> >>>>>>> status = tpm_tis_status(chip); >>>>>>> if ((status & TPM_STS_COMMAND_READY) == 0) { >>>>>>> @@ -292,6 +293,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >>>>>>> const u8 *buf, size_t len) >>>>>>> } >>>>>>> status = tpm_tis_status(chip); >>>>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { >>>>>>> + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), >>>>>>> &access); >>>>>>> + if (rc < 0) >>>>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: read >>>>>>> failure TPM_ACCESS(%d)\n", priv->locality); >>>>>>> + else >>>>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: >>>>>>> locality: %d status: %x access: %x\n", priv->locality, status, access); >>>>>>> rc = -EIO; >>>>>>> goto out_err; >>>>>>> } >>>>>>> @@ -309,6 +315,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >>>>>>> const u8 *buf, size_t len) >>>>>>> } >>>>>>> status = tpm_tis_status(chip); >>>>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { >>>>>>> + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), &access); >>>>>>> + if (rc < 0) >>>>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read >>>>>>> failure TPM_ACCESS(%d)\n", priv->locality); >>>>>>> + else >>>>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: locality: >>>>>>> %d status: %x access: %x\n", priv->locality, status, access); >>>>>>> rc = -EIO; >>>>>>> goto out_err; >>>>>>> } >>>>>> Please find here the dmesg output of the patched kernel >>>>> At least 0xff is corrupted value in senseful way. CPU fills the read >>>>> with ones for example for unaligned bus read. See table 19 in PC client >>>>> spec. This can happen when you do unaligned read for example. >>>>> >>>>> Maybe TPM is unreachable i.e. powered off. Bit busy with stuff ATM but >>>>> would probably make sense to compare that 0x81 to table 18 in the same >>>>> spec. >>>>> >>>>> /Jarkko >>>> 0x81 is saying the access register status is valid, and the locality >>>> is not active. That first bit means A Dynamic OS has not been previously >>>> established on the platform. Normally we would see 0xa1, which would >>>> mean valid register status, and the locality is active. >>> I think the important thing to note here is that STS has bits set that >>> should never be set. So we can conclude that TPM might be either >>> >>> 1. Powered off >>> 2. In some transition state? >>> >>> /Jarkko >> If it was powered off would we be getting a valid read from the access >> register? > I think there is no universal answer to that :-) > > Maybe adding a extra delay would be next test to make? If for random > reason it is in-between states... Any more ideas? The chip is definitely in a weird state :/ I tried several ways to reset the chip (windows, tpm-tools,...). I've been able to reset the chip via the bios (which now shows unowned) but chip is still locked apparently. But still with < 4.12 I'm able to get /some/ information Public EK, PCR,... out of the chip so it's not completely broken... ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: tpm device not showing up in /dev anymore @ 2017-11-09 0:04 ` Laurent Bigonville 0 siblings, 0 replies; 62+ messages in thread From: Laurent Bigonville @ 2017-11-09 0:04 UTC (permalink / raw) To: Jarkko Sakkinen, Jerry Snitselaar Cc: linux-integrity-u79uwXL29TY76Z2rM5mHXA, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Le 24/10/17 à 18:07, Jarkko Sakkinen a écrit : > On Tue, Oct 24, 2017 at 07:57:06AM -0700, Jerry Snitselaar wrote: >> On Tue Oct 24 17, Jarkko Sakkinen wrote: >>> On Mon, Oct 23, 2017 at 06:45:15AM -0700, Jerry Snitselaar wrote: >>>> On Mon Oct 23 17, Jarkko Sakkinen wrote: >>>>> On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote: >>>>>> Le 14/10/17 à 10:13, Jerry Snitselaar a écrit : >>>>>>> On Wed Sep 06 17, Jarkko Sakkinen wrote: >>>>>>>> On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent Bigonville wrote: >>>>>>>>> Le 31/08/17 à 18:40, Jerry Snitselaar a écrit : >>>>>>>>>> On Thu Aug 31 17, Alexander.Steffen@infineon.com wrote: >>>>>>>>>>>> Le 29/08/17 à 18:35, Laurent Bigonville a écrit : >>>>>>>>>>>>> Le 29/08/17 à 18:00, Alexander.Steffen@infineon.com a écrit : >>>>>>>>>>>>>>> An idea how to troubleshoot this? >>>>>>>>>>>>>> Can you run git bisect on the changes between 4.11 and >>>>>>>>> 4.12, so that >>>>>>>>>>>>>> we find the offending commit? It is probably sufficient >>>>>>>>> to limit the >>>>>>>>>>>>>> search to commits that touch something in drivers/char/tpm. >>>>>>>>>>>>> I'll try and keep you posted. >>>>>>>>>>>> OK I've been able to bisect the problem and the bad commit is: >>>>>>>>>>>> >>>>>>>>>>>> e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad commit >>>>>>>>>>>> commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >>>>>>>>>>>> Author: Jerry Snitselaar <jsnitsel@redhat.com> >>>>>>>>>>>> Date: Mon Mar 27 08:46:04 2017 -0700 >>>>>>>>>>>> >>>>>>>>>>>> tpm_tis: convert to using locality callbacks >>>>>>>>>>>> >>>>>>>>>>>> This patch converts tpm_tis to use of the new tpm class ops >>>>>>>>>>>> request_locality, and relinquish_locality. >>>>>>>>>>>> >>>>>>>>>>>> With the move to using the callbacks, release_locality is >>>>>>>>>>>> changed so >>>>>>>>>>>> that we now release the locality even if there is no >>>>>>>>>>>> request pending. >>>>>>>>>>>> >>>>>>>>>>>> This required some changes to the tpm_tis_core_init >>>>>>>>> code path to >>>>>>>>>>>> make sure locality is requested when needed: >>>>>>>>>>>> >>>>>>>>>>>> - tpm2_probe code path will end up calling >>>>>>>>>>>> request/release through >>>>>>>>>>>> callbacks, so request_locality prior to >>>>>>>>> tpm2_probe not needed. >>>>>>>>>>>> - probe_itpm makes calls to tpm_tis_send_data which no >>>>>>>>>>>> longer calls >>>>>>>>>>>> request_locality, so add request_locality prior to >>>>>>>>>>>> tpm_tis_send_data >>>>>>>>>>>> calls. Also drop release_locality call in middleof >>>>>>>>>>>> probe_itpm, and >>>>>>>>>>>> keep locality until release_locality called at end of >>>>>>>>>>>> probe_itpm. >>>>>>>>>>>> >>>>>>>>>>>> Cc: Peter Huewe <peterhuewe@gmx.de> >>>>>>>>>>>> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>> Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> >>>>>>>>>>>> Cc: Marcel Selhorst <tpmdd@selhorst.net> >>>>>>>>>>>> Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> >>>>>>>>>>>> Reviewed-by: Jarkko Sakkinen >>>>>>>>> <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>> Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>> Signed-off-by: Jarkko Sakkinen >>>>>>>>> <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>> :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >>>>>>>>>>>> 72f21b446e45ea1003de75902b0553deb99157fd M drivers >>>>>>>>>>>> >>>>>>>>>>> I've looked again at the code in question, but could not find >>>>>>>>>>> anything that is obviously wrong there. Locality is now >>>>>>>>>>> requested/released at slightly different points in the process than >>>>>>>>>>> before, but that's it. It does not seem to cause problems with the >>>>>>>>>>> majority of TPMs, since you are the first to report any, so >>>>>>>>> maybe it >>>>>>>>>>> is a quirk that only affects this device. >>>>>>>>>>> >>>>>>>>>>> Perhaps Jerry can help, since this is his change? >>>>>>>>>>> >>>>>>>>>>> Alexander >>>>>>>>>> Getting some caffeine in me, and starting to take a look. Adding >>>>>>>>>> Jarkko as well since this might involve the general locality changes. >>>>>>>>>> >>>>>>>>>> Laurent, if I send you a patch with some debugging code added, would >>>>>>>>>> you be able to run it on that system? I wasn't running into issues >>>>>>>>>> on the system I had with a 1.2 device, but I no longer have access >>>>>>>>>> to it. I'll see if I can find one in our labs and reproduce it there. >>>>>>>>> Yes I should be able to do that >>>>>>>> Any findings? >>>>>>>> >>>>>>>> /Jarkko >>>>>>> Okay, finally getting back to this. Looking at the code it isn't clear >>>>>>> to me >>>>>>> why the change is causing this. So while I stare at this some more >>>>>>> Laurent >>>>>>> could you reproduce it with this patch so I can see what the status and >>>>>>> access registers look like? Does anyone else on here happen to have a >>>>>>> Sinosun >>>>>>> tpm device? The systems I have access to with TPM1.2 devices don't have >>>>>>> this >>>>>>> issue. >>>>>>> >>>>>>> --8<-- >>>>>>> >>>>>>> diff --git a/drivers/char/tpm/tpm_tis_core.c >>>>>>> b/drivers/char/tpm/tpm_tis_core.c >>>>>>> index fdde971bc810..7d60a7e4b50a 100644 >>>>>>> --- a/drivers/char/tpm/tpm_tis_core.c >>>>>>> +++ b/drivers/char/tpm/tpm_tis_core.c >>>>>>> @@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >>>>>>> const u8 *buf, size_t len) >>>>>>> int rc, status, burstcnt; >>>>>>> size_t count = 0; >>>>>>> bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; >>>>>>> + u8 access; >>>>>>> >>>>>>> status = tpm_tis_status(chip); >>>>>>> if ((status & TPM_STS_COMMAND_READY) == 0) { >>>>>>> @@ -292,6 +293,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >>>>>>> const u8 *buf, size_t len) >>>>>>> } >>>>>>> status = tpm_tis_status(chip); >>>>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { >>>>>>> + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), >>>>>>> &access); >>>>>>> + if (rc < 0) >>>>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: read >>>>>>> failure TPM_ACCESS(%d)\n", priv->locality); >>>>>>> + else >>>>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: >>>>>>> locality: %d status: %x access: %x\n", priv->locality, status, access); >>>>>>> rc = -EIO; >>>>>>> goto out_err; >>>>>>> } >>>>>>> @@ -309,6 +315,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >>>>>>> const u8 *buf, size_t len) >>>>>>> } >>>>>>> status = tpm_tis_status(chip); >>>>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { >>>>>>> + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), &access); >>>>>>> + if (rc < 0) >>>>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read >>>>>>> failure TPM_ACCESS(%d)\n", priv->locality); >>>>>>> + else >>>>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: locality: >>>>>>> %d status: %x access: %x\n", priv->locality, status, access); >>>>>>> rc = -EIO; >>>>>>> goto out_err; >>>>>>> } >>>>>> Please find here the dmesg output of the patched kernel >>>>> At least 0xff is corrupted value in senseful way. CPU fills the read >>>>> with ones for example for unaligned bus read. See table 19 in PC client >>>>> spec. This can happen when you do unaligned read for example. >>>>> >>>>> Maybe TPM is unreachable i.e. powered off. Bit busy with stuff ATM but >>>>> would probably make sense to compare that 0x81 to table 18 in the same >>>>> spec. >>>>> >>>>> /Jarkko >>>> 0x81 is saying the access register status is valid, and the locality >>>> is not active. That first bit means A Dynamic OS has not been previously >>>> established on the platform. Normally we would see 0xa1, which would >>>> mean valid register status, and the locality is active. >>> I think the important thing to note here is that STS has bits set that >>> should never be set. So we can conclude that TPM might be either >>> >>> 1. Powered off >>> 2. In some transition state? >>> >>> /Jarkko >> If it was powered off would we be getting a valid read from the access >> register? > I think there is no universal answer to that :-) > > Maybe adding a extra delay would be next test to make? If for random > reason it is in-between states... Any more ideas? The chip is definitely in a weird state :/ I tried several ways to reset the chip (windows, tpm-tools,...). I've been able to reset the chip via the bios (which now shows unowned) but chip is still locked apparently. But still with < 4.12 I'm able to get /some/ information Public EK, PCR,... out of the chip so it's not completely broken... ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ tpmdd-devel mailing list tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore @ 2017-11-09 19:58 ` Laurent Bigonville 0 siblings, 0 replies; 62+ messages in thread From: Laurent Bigonville @ 2017-11-09 19:58 UTC (permalink / raw) To: Jarkko Sakkinen, Jerry Snitselaar Cc: Alexander.Steffen, tpmdd-devel, linux-integrity Le 09/11/17 a 01:04, Laurent Bigonville a ecrit : > > > Le 24/10/17 a 18:07, Jarkko Sakkinen a ecrit : >> On Tue, Oct 24, 2017 at 07:57:06AM -0700, Jerry Snitselaar wrote: >>> On Tue Oct 24 17, Jarkko Sakkinen wrote: >>>> On Mon, Oct 23, 2017 at 06:45:15AM -0700, Jerry Snitselaar wrote: >>>>> On Mon Oct 23 17, Jarkko Sakkinen wrote: >>>>>> On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote: >>>>>>> Le 14/10/17 a 10:13, Jerry Snitselaar a ecrit : >>>>>>>> On Wed Sep 06 17, Jarkko Sakkinen wrote: >>>>>>>>> On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent Bigonville >>>>>>>>> wrote: >>>>>>>>>> Le 31/08/17 a 18:40, Jerry Snitselaar a ecrit : >>>>>>>>>>> On Thu Aug 31 17, Alexander.Steffen@infineon.com wrote: >>>>>>>>>>>>> Le 29/08/17 a 18:35, Laurent Bigonville a ecrit : >>>>>>>>>>>>>> Le 29/08/17 a 18:00, Alexander.Steffen@infineon.com a >>>>>>>>>>>>>> ecrit : >>>>>>>>>>>>>>>> An idea how to troubleshoot this? >>>>>>>>>>>>>>> Can you run git bisect on the changes between 4.11 and >>>>>>>>>> 4.12, so that >>>>>>>>>>>>>>> we find the offending commit? It is probably sufficient >>>>>>>>>> to limit the >>>>>>>>>>>>>>> search to commits that touch something in drivers/char/tpm. >>>>>>>>>>>>>> I'll try and keep you posted. >>>>>>>>>>>>> OK I've been able to bisect the problem and the bad commit >>>>>>>>>>>>> is: >>>>>>>>>>>>> >>>>>>>>>>>>> e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad >>>>>>>>>>>>> commit >>>>>>>>>>>>> commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >>>>>>>>>>>>> Author: Jerry Snitselaar <jsnitsel@redhat.com> >>>>>>>>>>>>> Date: Mon Mar 27 08:46:04 2017 -0700 >>>>>>>>>>>>> >>>>>>>>>>>>> tpm_tis: convert to using locality callbacks >>>>>>>>>>>>> >>>>>>>>>>>>> This patch converts tpm_tis to use of the new tpm >>>>>>>>>>>>> class ops >>>>>>>>>>>>> request_locality, and relinquish_locality. >>>>>>>>>>>>> >>>>>>>>>>>>> With the move to using the callbacks, >>>>>>>>>>>>> release_locality is >>>>>>>>>>>>> changed so >>>>>>>>>>>>> that we now release the locality even if there is no >>>>>>>>>>>>> request pending. >>>>>>>>>>>>> >>>>>>>>>>>>> This required some changes to the tpm_tis_core_init >>>>>>>>>> code path to >>>>>>>>>>>>> make sure locality is requested when needed: >>>>>>>>>>>>> >>>>>>>>>>>>> - tpm2_probe code path will end up calling >>>>>>>>>>>>> request/release through >>>>>>>>>>>>> callbacks, so request_locality prior to >>>>>>>>>> tpm2_probe not needed. >>>>>>>>>>>>> - probe_itpm makes calls to tpm_tis_send_data >>>>>>>>>>>>> which no >>>>>>>>>>>>> longer calls >>>>>>>>>>>>> request_locality, so add request_locality prior to >>>>>>>>>>>>> tpm_tis_send_data >>>>>>>>>>>>> calls. Also drop release_locality call in middleof >>>>>>>>>>>>> probe_itpm, and >>>>>>>>>>>>> keep locality until release_locality called at >>>>>>>>>>>>> end of >>>>>>>>>>>>> probe_itpm. >>>>>>>>>>>>> >>>>>>>>>>>>> Cc: Peter Huewe <peterhuewe@gmx.de> >>>>>>>>>>>>> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>> Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> >>>>>>>>>>>>> Cc: Marcel Selhorst <tpmdd@selhorst.net> >>>>>>>>>>>>> Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> >>>>>>>>>>>>> Reviewed-by: Jarkko Sakkinen >>>>>>>>>> <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>> Tested-by: Jarkko Sakkinen >>>>>>>>>>>>> <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>> Signed-off-by: Jarkko Sakkinen >>>>>>>>>> <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>> :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >>>>>>>>>>>>> 72f21b446e45ea1003de75902b0553deb99157fd M drivers >>>>>>>>>>>>> >>>>>>>>>>>> I've looked again at the code in question, but could not find >>>>>>>>>>>> anything that is obviously wrong there. Locality is now >>>>>>>>>>>> requested/released at slightly different points in the >>>>>>>>>>>> process than >>>>>>>>>>>> before, but that's it. It does not seem to cause problems >>>>>>>>>>>> with the >>>>>>>>>>>> majority of TPMs, since you are the first to report any, so >>>>>>>>>> maybe it >>>>>>>>>>>> is a quirk that only affects this device. >>>>>>>>>>>> >>>>>>>>>>>> Perhaps Jerry can help, since this is his change? >>>>>>>>>>>> >>>>>>>>>>>> Alexander >>>>>>>>>>> Getting some caffeine in me, and starting to take a look. >>>>>>>>>>> Adding >>>>>>>>>>> Jarkko as well since this might involve the general locality >>>>>>>>>>> changes. >>>>>>>>>>> >>>>>>>>>>> Laurent, if I send you a patch with some debugging code >>>>>>>>>>> added, would >>>>>>>>>>> you be able to run it on that system? I wasn't running into >>>>>>>>>>> issues >>>>>>>>>>> on the system I had with a 1.2 device, but I no longer have >>>>>>>>>>> access >>>>>>>>>>> to it. I'll see if I can find one in our labs and reproduce >>>>>>>>>>> it there. >>>>>>>>>> Yes I should be able to do that >>>>>>>>> Any findings? >>>>>>>>> >>>>>>>>> /Jarkko >>>>>>>> Okay, finally getting back to this. Looking at the code it >>>>>>>> isn't clear >>>>>>>> to me >>>>>>>> why the change is causing this. So while I stare at this some more >>>>>>>> Laurent >>>>>>>> could you reproduce it with this patch so I can see what the >>>>>>>> status and >>>>>>>> access registers look like? Does anyone else on here happen to >>>>>>>> have a >>>>>>>> Sinosun >>>>>>>> tpm device? The systems I have access to with TPM1.2 devices >>>>>>>> don't have >>>>>>>> this >>>>>>>> issue. >>>>>>>> >>>>>>>> --8<-- >>>>>>>> >>>>>>>> diff --git a/drivers/char/tpm/tpm_tis_core.c >>>>>>>> b/drivers/char/tpm/tpm_tis_core.c >>>>>>>> index fdde971bc810..7d60a7e4b50a 100644 >>>>>>>> --- a/drivers/char/tpm/tpm_tis_core.c >>>>>>>> +++ b/drivers/char/tpm/tpm_tis_core.c >>>>>>>> @@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct >>>>>>>> tpm_chip *chip, >>>>>>>> const u8 *buf, size_t len) >>>>>>>> int rc, status, burstcnt; >>>>>>>> size_t count = 0; >>>>>>>> bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; >>>>>>>> + u8 access; >>>>>>>> >>>>>>>> status = tpm_tis_status(chip); >>>>>>>> if ((status & TPM_STS_COMMAND_READY) == 0) { >>>>>>>> @@ -292,6 +293,11 @@ static int tpm_tis_send_data(struct >>>>>>>> tpm_chip *chip, >>>>>>>> const u8 *buf, size_t len) >>>>>>>> } >>>>>>>> status = tpm_tis_status(chip); >>>>>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { >>>>>>>> + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), >>>>>>>> &access); >>>>>>>> + if (rc < 0) >>>>>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == >>>>>>>> 0: read >>>>>>>> failure TPM_ACCESS(%d)\n", priv->locality); >>>>>>>> + else >>>>>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: >>>>>>>> locality: %d status: %x access: %x\n", priv->locality, status, >>>>>>>> access); >>>>>>>> rc = -EIO; >>>>>>>> goto out_err; >>>>>>>> } >>>>>>>> @@ -309,6 +315,11 @@ static int tpm_tis_send_data(struct >>>>>>>> tpm_chip *chip, >>>>>>>> const u8 *buf, size_t len) >>>>>>>> } >>>>>>>> status = tpm_tis_status(chip); >>>>>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { >>>>>>>> + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), >>>>>>>> &access); >>>>>>>> + if (rc < 0) >>>>>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read >>>>>>>> failure TPM_ACCESS(%d)\n", priv->locality); >>>>>>>> + else >>>>>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: >>>>>>>> locality: >>>>>>>> %d status: %x access: %x\n", priv->locality, status, access); >>>>>>>> rc = -EIO; >>>>>>>> goto out_err; >>>>>>>> } >>>>>>> Please find here the dmesg output of the patched kernel >>>>>> At least 0xff is corrupted value in senseful way. CPU fills the read >>>>>> with ones for example for unaligned bus read. See table 19 in PC >>>>>> client >>>>>> spec. This can happen when you do unaligned read for example. >>>>>> >>>>>> Maybe TPM is unreachable i.e. powered off. Bit busy with stuff >>>>>> ATM but >>>>>> would probably make sense to compare that 0x81 to table 18 in the >>>>>> same >>>>>> spec. >>>>>> >>>>>> /Jarkko >>>>> 0x81 is saying the access register status is valid, and the locality >>>>> is not active. That first bit means A Dynamic OS has not been >>>>> previously >>>>> established on the platform. Normally we would see 0xa1, which would >>>>> mean valid register status, and the locality is active. >>>> I think the important thing to note here is that STS has bits set that >>>> should never be set. So we can conclude that TPM might be either >>>> >>>> 1. Powered off >>>> 2. In some transition state? >>>> >>>> /Jarkko >>> If it was powered off would we be getting a valid read from the access >>> register? >> I think there is no universal answer to that :-) >> >> Maybe adding a extra delay would be next test to make? If for random >> reason it is in-between states... > Any more ideas? > > The chip is definitely in a weird state :/ I tried several ways to > reset the chip (windows, tpm-tools,...). > > I've been able to reset the chip via the bios (which now shows > unowned) but chip is still locked apparently. > > But still with < 4.12 I'm able to get /some/ information Public EK, > PCR,... out of the chip so it's not completely broken... OK correction the TPM is now unlocked (I let the computer running for more than 24h with nothing accessing the TPM) and with 4.9 I've been able to take the ownership again. Under 4.12 I still have the same errors as mentioned originally ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: tpm device not showing up in /dev anymore @ 2017-11-09 19:58 ` Laurent Bigonville 0 siblings, 0 replies; 62+ messages in thread From: Laurent Bigonville @ 2017-11-09 19:58 UTC (permalink / raw) To: Jarkko Sakkinen, Jerry Snitselaar Cc: linux-integrity-u79uwXL29TY76Z2rM5mHXA, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Le 09/11/17 à 01:04, Laurent Bigonville a écrit : > > > Le 24/10/17 à 18:07, Jarkko Sakkinen a écrit : >> On Tue, Oct 24, 2017 at 07:57:06AM -0700, Jerry Snitselaar wrote: >>> On Tue Oct 24 17, Jarkko Sakkinen wrote: >>>> On Mon, Oct 23, 2017 at 06:45:15AM -0700, Jerry Snitselaar wrote: >>>>> On Mon Oct 23 17, Jarkko Sakkinen wrote: >>>>>> On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote: >>>>>>> Le 14/10/17 à 10:13, Jerry Snitselaar a écrit : >>>>>>>> On Wed Sep 06 17, Jarkko Sakkinen wrote: >>>>>>>>> On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent Bigonville >>>>>>>>> wrote: >>>>>>>>>> Le 31/08/17 à 18:40, Jerry Snitselaar a écrit : >>>>>>>>>>> On Thu Aug 31 17, Alexander.Steffen@infineon.com wrote: >>>>>>>>>>>>> Le 29/08/17 à 18:35, Laurent Bigonville a écrit : >>>>>>>>>>>>>> Le 29/08/17 à 18:00, Alexander.Steffen@infineon.com a >>>>>>>>>>>>>> écrit : >>>>>>>>>>>>>>>> An idea how to troubleshoot this? >>>>>>>>>>>>>>> Can you run git bisect on the changes between 4.11 and >>>>>>>>>> 4.12, so that >>>>>>>>>>>>>>> we find the offending commit? It is probably sufficient >>>>>>>>>> to limit the >>>>>>>>>>>>>>> search to commits that touch something in drivers/char/tpm. >>>>>>>>>>>>>> I'll try and keep you posted. >>>>>>>>>>>>> OK I've been able to bisect the problem and the bad commit >>>>>>>>>>>>> is: >>>>>>>>>>>>> >>>>>>>>>>>>> e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad >>>>>>>>>>>>> commit >>>>>>>>>>>>> commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >>>>>>>>>>>>> Author: Jerry Snitselaar <jsnitsel@redhat.com> >>>>>>>>>>>>> Date: Mon Mar 27 08:46:04 2017 -0700 >>>>>>>>>>>>> >>>>>>>>>>>>> tpm_tis: convert to using locality callbacks >>>>>>>>>>>>> >>>>>>>>>>>>> This patch converts tpm_tis to use of the new tpm >>>>>>>>>>>>> class ops >>>>>>>>>>>>> request_locality, and relinquish_locality. >>>>>>>>>>>>> >>>>>>>>>>>>> With the move to using the callbacks, >>>>>>>>>>>>> release_locality is >>>>>>>>>>>>> changed so >>>>>>>>>>>>> that we now release the locality even if there is no >>>>>>>>>>>>> request pending. >>>>>>>>>>>>> >>>>>>>>>>>>> This required some changes to the tpm_tis_core_init >>>>>>>>>> code path to >>>>>>>>>>>>> make sure locality is requested when needed: >>>>>>>>>>>>> >>>>>>>>>>>>> - tpm2_probe code path will end up calling >>>>>>>>>>>>> request/release through >>>>>>>>>>>>> callbacks, so request_locality prior to >>>>>>>>>> tpm2_probe not needed. >>>>>>>>>>>>> - probe_itpm makes calls to tpm_tis_send_data >>>>>>>>>>>>> which no >>>>>>>>>>>>> longer calls >>>>>>>>>>>>> request_locality, so add request_locality prior to >>>>>>>>>>>>> tpm_tis_send_data >>>>>>>>>>>>> calls. Also drop release_locality call in middleof >>>>>>>>>>>>> probe_itpm, and >>>>>>>>>>>>> keep locality until release_locality called at >>>>>>>>>>>>> end of >>>>>>>>>>>>> probe_itpm. >>>>>>>>>>>>> >>>>>>>>>>>>> Cc: Peter Huewe <peterhuewe@gmx.de> >>>>>>>>>>>>> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>> Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> >>>>>>>>>>>>> Cc: Marcel Selhorst <tpmdd@selhorst.net> >>>>>>>>>>>>> Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> >>>>>>>>>>>>> Reviewed-by: Jarkko Sakkinen >>>>>>>>>> <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>> Tested-by: Jarkko Sakkinen >>>>>>>>>>>>> <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>> Signed-off-by: Jarkko Sakkinen >>>>>>>>>> <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>> :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >>>>>>>>>>>>> 72f21b446e45ea1003de75902b0553deb99157fd M drivers >>>>>>>>>>>>> >>>>>>>>>>>> I've looked again at the code in question, but could not find >>>>>>>>>>>> anything that is obviously wrong there. Locality is now >>>>>>>>>>>> requested/released at slightly different points in the >>>>>>>>>>>> process than >>>>>>>>>>>> before, but that's it. It does not seem to cause problems >>>>>>>>>>>> with the >>>>>>>>>>>> majority of TPMs, since you are the first to report any, so >>>>>>>>>> maybe it >>>>>>>>>>>> is a quirk that only affects this device. >>>>>>>>>>>> >>>>>>>>>>>> Perhaps Jerry can help, since this is his change? >>>>>>>>>>>> >>>>>>>>>>>> Alexander >>>>>>>>>>> Getting some caffeine in me, and starting to take a look. >>>>>>>>>>> Adding >>>>>>>>>>> Jarkko as well since this might involve the general locality >>>>>>>>>>> changes. >>>>>>>>>>> >>>>>>>>>>> Laurent, if I send you a patch with some debugging code >>>>>>>>>>> added, would >>>>>>>>>>> you be able to run it on that system? I wasn't running into >>>>>>>>>>> issues >>>>>>>>>>> on the system I had with a 1.2 device, but I no longer have >>>>>>>>>>> access >>>>>>>>>>> to it. I'll see if I can find one in our labs and reproduce >>>>>>>>>>> it there. >>>>>>>>>> Yes I should be able to do that >>>>>>>>> Any findings? >>>>>>>>> >>>>>>>>> /Jarkko >>>>>>>> Okay, finally getting back to this. Looking at the code it >>>>>>>> isn't clear >>>>>>>> to me >>>>>>>> why the change is causing this. So while I stare at this some more >>>>>>>> Laurent >>>>>>>> could you reproduce it with this patch so I can see what the >>>>>>>> status and >>>>>>>> access registers look like? Does anyone else on here happen to >>>>>>>> have a >>>>>>>> Sinosun >>>>>>>> tpm device? The systems I have access to with TPM1.2 devices >>>>>>>> don't have >>>>>>>> this >>>>>>>> issue. >>>>>>>> >>>>>>>> --8<-- >>>>>>>> >>>>>>>> diff --git a/drivers/char/tpm/tpm_tis_core.c >>>>>>>> b/drivers/char/tpm/tpm_tis_core.c >>>>>>>> index fdde971bc810..7d60a7e4b50a 100644 >>>>>>>> --- a/drivers/char/tpm/tpm_tis_core.c >>>>>>>> +++ b/drivers/char/tpm/tpm_tis_core.c >>>>>>>> @@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct >>>>>>>> tpm_chip *chip, >>>>>>>> const u8 *buf, size_t len) >>>>>>>> int rc, status, burstcnt; >>>>>>>> size_t count = 0; >>>>>>>> bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; >>>>>>>> + u8 access; >>>>>>>> >>>>>>>> status = tpm_tis_status(chip); >>>>>>>> if ((status & TPM_STS_COMMAND_READY) == 0) { >>>>>>>> @@ -292,6 +293,11 @@ static int tpm_tis_send_data(struct >>>>>>>> tpm_chip *chip, >>>>>>>> const u8 *buf, size_t len) >>>>>>>> } >>>>>>>> status = tpm_tis_status(chip); >>>>>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { >>>>>>>> + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), >>>>>>>> &access); >>>>>>>> + if (rc < 0) >>>>>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == >>>>>>>> 0: read >>>>>>>> failure TPM_ACCESS(%d)\n", priv->locality); >>>>>>>> + else >>>>>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: >>>>>>>> locality: %d status: %x access: %x\n", priv->locality, status, >>>>>>>> access); >>>>>>>> rc = -EIO; >>>>>>>> goto out_err; >>>>>>>> } >>>>>>>> @@ -309,6 +315,11 @@ static int tpm_tis_send_data(struct >>>>>>>> tpm_chip *chip, >>>>>>>> const u8 *buf, size_t len) >>>>>>>> } >>>>>>>> status = tpm_tis_status(chip); >>>>>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { >>>>>>>> + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), >>>>>>>> &access); >>>>>>>> + if (rc < 0) >>>>>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read >>>>>>>> failure TPM_ACCESS(%d)\n", priv->locality); >>>>>>>> + else >>>>>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: >>>>>>>> locality: >>>>>>>> %d status: %x access: %x\n", priv->locality, status, access); >>>>>>>> rc = -EIO; >>>>>>>> goto out_err; >>>>>>>> } >>>>>>> Please find here the dmesg output of the patched kernel >>>>>> At least 0xff is corrupted value in senseful way. CPU fills the read >>>>>> with ones for example for unaligned bus read. See table 19 in PC >>>>>> client >>>>>> spec. This can happen when you do unaligned read for example. >>>>>> >>>>>> Maybe TPM is unreachable i.e. powered off. Bit busy with stuff >>>>>> ATM but >>>>>> would probably make sense to compare that 0x81 to table 18 in the >>>>>> same >>>>>> spec. >>>>>> >>>>>> /Jarkko >>>>> 0x81 is saying the access register status is valid, and the locality >>>>> is not active. That first bit means A Dynamic OS has not been >>>>> previously >>>>> established on the platform. Normally we would see 0xa1, which would >>>>> mean valid register status, and the locality is active. >>>> I think the important thing to note here is that STS has bits set that >>>> should never be set. So we can conclude that TPM might be either >>>> >>>> 1. Powered off >>>> 2. In some transition state? >>>> >>>> /Jarkko >>> If it was powered off would we be getting a valid read from the access >>> register? >> I think there is no universal answer to that :-) >> >> Maybe adding a extra delay would be next test to make? If for random >> reason it is in-between states... > Any more ideas? > > The chip is definitely in a weird state :/ I tried several ways to > reset the chip (windows, tpm-tools,...). > > I've been able to reset the chip via the bios (which now shows > unowned) but chip is still locked apparently. > > But still with < 4.12 I'm able to get /some/ information Public EK, > PCR,... out of the chip so it's not completely broken... OK correction the TPM is now unlocked (I let the computer running for more than 24h with nothing accessing the TPM) and with 4.9 I've been able to take the ownership again. Under 4.12 I still have the same errors as mentioned originally ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ tpmdd-devel mailing list tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore @ 2017-11-09 23:50 ` Jerry Snitselaar 0 siblings, 0 replies; 62+ messages in thread From: Jerry Snitselaar @ 2017-11-09 23:50 UTC (permalink / raw) To: Laurent Bigonville Cc: Jarkko Sakkinen, Alexander.Steffen, tpmdd-devel, linux-integrity On Thu Nov 09 17, Laurent Bigonville wrote: >Le 09/11/17 a 01:04, Laurent Bigonville a ecrit : >> >> >>Le 24/10/17 a 18:07, Jarkko Sakkinen a ecrit : >>>On Tue, Oct 24, 2017 at 07:57:06AM -0700, Jerry Snitselaar wrote: >>>>On Tue Oct 24 17, Jarkko Sakkinen wrote: >>>>>On Mon, Oct 23, 2017 at 06:45:15AM -0700, Jerry Snitselaar wrote: >>>>>>On Mon Oct 23 17, Jarkko Sakkinen wrote: >>>>>>>On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote: >>>>>>>>Le 14/10/17 a 10:13, Jerry Snitselaar a ecrit : >>>>>>>>>On Wed Sep 06 17, Jarkko Sakkinen wrote: >>>>>>>>>>On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent >>>>>>>>>>Bigonville wrote: >>>>>>>>>>>Le 31/08/17 a 18:40, Jerry Snitselaar a ecrit : >>>>>>>>>>>>On Thu Aug 31 17, Alexander.Steffen@infineon.com wrote: >>>>>>>>>>>>>>Le 29/08/17 a 18:35, Laurent Bigonville a ecrit : >>>>>>>>>>>>>>>Le 29/08/17 a 18:00, >>>>>>>>>>>>>>>Alexander.Steffen@infineon.com a ecrit : >>>>>>>>>>>>>>>>>An idea how to troubleshoot this? >>>>>>>>>>>>>>>>Can you run git bisect on the changes between 4.11 and >>>>>>>>>>>4.12, so that >>>>>>>>>>>>>>>>we find the offending commit? It is probably sufficient >>>>>>>>>>>to limit the >>>>>>>>>>>>>>>>search to commits that touch something in drivers/char/tpm. >>>>>>>>>>>>>>>I'll try and keep you posted. >>>>>>>>>>>>>>OK I've been able to bisect the problem and >>>>>>>>>>>>>>the bad commit is: >>>>>>>>>>>>>> >>>>>>>>>>>>>>e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is >>>>>>>>>>>>>>the first bad commit >>>>>>>>>>>>>>commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >>>>>>>>>>>>>>Author: Jerry Snitselaar <jsnitsel@redhat.com> >>>>>>>>>>>>>>Date: Mon Mar 27 08:46:04 2017 -0700 >>>>>>>>>>>>>> >>>>>>>>>>>>>> tpm_tis: convert to using locality callbacks >>>>>>>>>>>>>> >>>>>>>>>>>>>> This patch converts tpm_tis to use of >>>>>>>>>>>>>>the new tpm class ops >>>>>>>>>>>>>> request_locality, and relinquish_locality. >>>>>>>>>>>>>> >>>>>>>>>>>>>> With the move to using the callbacks, >>>>>>>>>>>>>>release_locality is >>>>>>>>>>>>>>changed so >>>>>>>>>>>>>> that we now release the locality even if there is no >>>>>>>>>>>>>>request pending. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This required some changes to the tpm_tis_core_init >>>>>>>>>>>code path to >>>>>>>>>>>>>> make sure locality is requested when needed: >>>>>>>>>>>>>> >>>>>>>>>>>>>> - tpm2_probe code path will end up calling >>>>>>>>>>>>>>request/release through >>>>>>>>>>>>>> callbacks, so request_locality prior to >>>>>>>>>>>tpm2_probe not needed. >>>>>>>>>>>>>> - probe_itpm makes calls to >>>>>>>>>>>>>>tpm_tis_send_data which no >>>>>>>>>>>>>>longer calls >>>>>>>>>>>>>> request_locality, so add request_locality prior to >>>>>>>>>>>>>>tpm_tis_send_data >>>>>>>>>>>>>> calls. Also drop release_locality call in middleof >>>>>>>>>>>>>>probe_itpm, and >>>>>>>>>>>>>> keep locality until >>>>>>>>>>>>>>release_locality called at end of >>>>>>>>>>>>>>probe_itpm. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cc: Peter Huewe <peterhuewe@gmx.de> >>>>>>>>>>>>>> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>> Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> >>>>>>>>>>>>>> Cc: Marcel Selhorst <tpmdd@selhorst.net> >>>>>>>>>>>>>> Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> >>>>>>>>>>>>>> Reviewed-by: Jarkko Sakkinen >>>>>>>>>>><jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>> Tested-by: Jarkko Sakkinen >>>>>>>>>>>>>><jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>> Signed-off-by: Jarkko Sakkinen >>>>>>>>>>><jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>>:040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >>>>>>>>>>>>>>72f21b446e45ea1003de75902b0553deb99157fd M drivers >>>>>>>>>>>>>> >>>>>>>>>>>>>I've looked again at the code in question, but could not find >>>>>>>>>>>>>anything that is obviously wrong there. Locality is now >>>>>>>>>>>>>requested/released at slightly different >>>>>>>>>>>>>points in the process than >>>>>>>>>>>>>before, but that's it. It does not seem to >>>>>>>>>>>>>cause problems with the >>>>>>>>>>>>>majority of TPMs, since you are the first to report any, so >>>>>>>>>>>maybe it >>>>>>>>>>>>>is a quirk that only affects this device. >>>>>>>>>>>>> >>>>>>>>>>>>>Perhaps Jerry can help, since this is his change? >>>>>>>>>>>>> >>>>>>>>>>>>>Alexander >>>>>>>>>>>>Getting some caffeine in me, and starting to >>>>>>>>>>>>take a look. Adding >>>>>>>>>>>>Jarkko as well since this might involve the >>>>>>>>>>>>general locality changes. >>>>>>>>>>>> >>>>>>>>>>>>Laurent, if I send you a patch with some >>>>>>>>>>>>debugging code added, would >>>>>>>>>>>>you be able to run it on that system? I wasn't >>>>>>>>>>>>running into issues >>>>>>>>>>>>on the system I had with a 1.2 device, but I no >>>>>>>>>>>>longer have access >>>>>>>>>>>>to it. I'll see if I can find one in our labs >>>>>>>>>>>>and reproduce it there. >>>>>>>>>>>Yes I should be able to do that >>>>>>>>>>Any findings? >>>>>>>>>> >>>>>>>>>>/Jarkko >>>>>>>>>Okay, finally getting back to this. Looking at the >>>>>>>>>code it isn't clear >>>>>>>>>to me >>>>>>>>>why the change is causing this. So while I stare at this some more >>>>>>>>>Laurent >>>>>>>>>could you reproduce it with this patch so I can see >>>>>>>>>what the status and >>>>>>>>>access registers look like? Does anyone else on here >>>>>>>>>happen to have a >>>>>>>>>Sinosun >>>>>>>>>tpm device? The systems I have access to with TPM1.2 >>>>>>>>>devices don't have >>>>>>>>>this >>>>>>>>>issue. >>>>>>>>> >>>>>>>>>--8<-- >>>>>>>>> >>>>>>>>>diff --git a/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>b/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>index fdde971bc810..7d60a7e4b50a 100644 >>>>>>>>>--- a/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>+++ b/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>@@ -258,6 +258,7 @@ static int >>>>>>>>>tpm_tis_send_data(struct tpm_chip *chip, >>>>>>>>>const u8 *buf, size_t len) >>>>>>>>> int rc, status, burstcnt; >>>>>>>>> size_t count = 0; >>>>>>>>> bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; >>>>>>>>>+ u8 access; >>>>>>>>> >>>>>>>>> status = tpm_tis_status(chip); >>>>>>>>> if ((status & TPM_STS_COMMAND_READY) == 0) { >>>>>>>>>@@ -292,6 +293,11 @@ static int >>>>>>>>>tpm_tis_send_data(struct tpm_chip *chip, >>>>>>>>>const u8 *buf, size_t len) >>>>>>>>> } >>>>>>>>> status = tpm_tis_status(chip); >>>>>>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { >>>>>>>>>+ rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), >>>>>>>>>&access); >>>>>>>>>+ if (rc < 0) >>>>>>>>>+ dev_info(&chip->dev, >>>>>>>>>"TPM_STS_DATA_EXPECT == 0: read >>>>>>>>>failure TPM_ACCESS(%d)\n", priv->locality); >>>>>>>>>+ else >>>>>>>>>+ dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: >>>>>>>>>locality: %d status: %x access: %x\n", priv->locality, >>>>>>>>>status, access); >>>>>>>>> rc = -EIO; >>>>>>>>> goto out_err; >>>>>>>>> } >>>>>>>>>@@ -309,6 +315,11 @@ static int >>>>>>>>>tpm_tis_send_data(struct tpm_chip *chip, >>>>>>>>>const u8 *buf, size_t len) >>>>>>>>> } >>>>>>>>> status = tpm_tis_status(chip); >>>>>>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { >>>>>>>>>+ rc = tpm_tis_read8(priv, >>>>>>>>>TPM_ACCESS(priv->locality), &access); >>>>>>>>>+ if (rc < 0) >>>>>>>>>+ dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read >>>>>>>>>failure TPM_ACCESS(%d)\n", priv->locality); >>>>>>>>>+ else >>>>>>>>>+ dev_info(&chip->dev, "TPM_STS_DATA_EXPECT >>>>>>>>>!= 0: locality: >>>>>>>>>%d status: %x access: %x\n", priv->locality, status, access); >>>>>>>>> rc = -EIO; >>>>>>>>> goto out_err; >>>>>>>>> } >>>>>>>>Please find here the dmesg output of the patched kernel >>>>>>>At least 0xff is corrupted value in senseful way. CPU fills the read >>>>>>>with ones for example for unaligned bus read. See table 19 >>>>>>>in PC client >>>>>>>spec. This can happen when you do unaligned read for example. >>>>>>> >>>>>>>Maybe TPM is unreachable i.e. powered off. Bit busy with >>>>>>>stuff ATM but >>>>>>>would probably make sense to compare that 0x81 to table 18 >>>>>>>in the same >>>>>>>spec. >>>>>>> >>>>>>>/Jarkko >>>>>>0x81 is saying the access register status is valid, and the locality >>>>>>is not active. That first bit means A Dynamic OS has not >>>>>>been previously >>>>>>established on the platform. Normally we would see 0xa1, which would >>>>>>mean valid register status, and the locality is active. >>>>>I think the important thing to note here is that STS has bits set that >>>>>should never be set. So we can conclude that TPM might be either >>>>> >>>>>1. Powered off >>>>>2. In some transition state? >>>>> >>>>>/Jarkko >>>>If it was powered off would we be getting a valid read from the access >>>>register? >>>I think there is no universal answer to that :-) >>> >>>Maybe adding a extra delay would be next test to make? If for random >>>reason it is in-between states... >>Any more ideas? >> >>The chip is definitely in a weird state :/ I tried several ways to >>reset the chip (windows, tpm-tools,...). >> >>I've been able to reset the chip via the bios (which now shows >>unowned) but chip is still locked apparently. >> >>But still with < 4.12 I'm able to get /some/ information Public EK, >>PCR,... out of the chip so it's not completely broken... > >OK correction the TPM is now unlocked (I let the computer running for >more than 24h with nothing accessing the TPM) and with 4.9 I've been >able to take the ownership again. > >Under 4.12 I still have the same errors as mentioned originally Still thinking about how to attack this. I don't think extending the timeout would change anything because it is reading the register, and thinking the status is valid because it reads 0xff. So it would still have that problem, right? Maybe a sanity check could be added to wait_for_tpm_stat() to first check that it didn't read 0xff before checking for the value it is looking for. Would that make sense Jarkko? diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c index 1d6729be4cd6..8b77fa2003ce 100644 --- a/drivers/char/tpm/tpm-interface.c +++ b/drivers/char/tpm/tpm-interface.c @@ -1087,7 +1087,7 @@ int wait_for_tpm_stat(struct tpm_chip *chip, u8 mask, unsigned long timeout, do { tpm_msleep(TPM_TIMEOUT); status = chip->ops->status(chip); - if ((status & mask) == mask) + if ((status != 0xff) && (status & mask) == mask) return 0; } while (time_before(jiffies, stop)); } ^ permalink raw reply related [flat|nested] 62+ messages in thread
* Re: tpm device not showing up in /dev anymore @ 2017-11-09 23:50 ` Jerry Snitselaar 0 siblings, 0 replies; 62+ messages in thread From: Jerry Snitselaar @ 2017-11-09 23:50 UTC (permalink / raw) To: Laurent Bigonville Cc: linux-integrity-u79uwXL29TY76Z2rM5mHXA, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Jarkko Sakkinen On Thu Nov 09 17, Laurent Bigonville wrote: >Le 09/11/17 à 01:04, Laurent Bigonville a écrit : >> >> >>Le 24/10/17 à 18:07, Jarkko Sakkinen a écrit : >>>On Tue, Oct 24, 2017 at 07:57:06AM -0700, Jerry Snitselaar wrote: >>>>On Tue Oct 24 17, Jarkko Sakkinen wrote: >>>>>On Mon, Oct 23, 2017 at 06:45:15AM -0700, Jerry Snitselaar wrote: >>>>>>On Mon Oct 23 17, Jarkko Sakkinen wrote: >>>>>>>On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote: >>>>>>>>Le 14/10/17 à 10:13, Jerry Snitselaar a écrit : >>>>>>>>>On Wed Sep 06 17, Jarkko Sakkinen wrote: >>>>>>>>>>On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent >>>>>>>>>>Bigonville wrote: >>>>>>>>>>>Le 31/08/17 à 18:40, Jerry Snitselaar a écrit : >>>>>>>>>>>>On Thu Aug 31 17, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org wrote: >>>>>>>>>>>>>>Le 29/08/17 à 18:35, Laurent Bigonville a écrit : >>>>>>>>>>>>>>>Le 29/08/17 à 18:00, >>>>>>>>>>>>>>>Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org a écrit : >>>>>>>>>>>>>>>>>An idea how to troubleshoot this? >>>>>>>>>>>>>>>>Can you run git bisect on the changes between 4.11 and >>>>>>>>>>>4.12, so that >>>>>>>>>>>>>>>>we find the offending commit? It is probably sufficient >>>>>>>>>>>to limit the >>>>>>>>>>>>>>>>search to commits that touch something in drivers/char/tpm. >>>>>>>>>>>>>>>I'll try and keep you posted. >>>>>>>>>>>>>>OK I've been able to bisect the problem and >>>>>>>>>>>>>>the bad commit is: >>>>>>>>>>>>>> >>>>>>>>>>>>>>e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is >>>>>>>>>>>>>>the first bad commit >>>>>>>>>>>>>>commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >>>>>>>>>>>>>>Author: Jerry Snitselaar <jsnitsel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> >>>>>>>>>>>>>>Date: Mon Mar 27 08:46:04 2017 -0700 >>>>>>>>>>>>>> >>>>>>>>>>>>>> tpm_tis: convert to using locality callbacks >>>>>>>>>>>>>> >>>>>>>>>>>>>> This patch converts tpm_tis to use of >>>>>>>>>>>>>>the new tpm class ops >>>>>>>>>>>>>> request_locality, and relinquish_locality. >>>>>>>>>>>>>> >>>>>>>>>>>>>> With the move to using the callbacks, >>>>>>>>>>>>>>release_locality is >>>>>>>>>>>>>>changed so >>>>>>>>>>>>>> that we now release the locality even if there is no >>>>>>>>>>>>>>request pending. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This required some changes to the tpm_tis_core_init >>>>>>>>>>>code path to >>>>>>>>>>>>>> make sure locality is requested when needed: >>>>>>>>>>>>>> >>>>>>>>>>>>>> - tpm2_probe code path will end up calling >>>>>>>>>>>>>>request/release through >>>>>>>>>>>>>> callbacks, so request_locality prior to >>>>>>>>>>>tpm2_probe not needed. >>>>>>>>>>>>>> - probe_itpm makes calls to >>>>>>>>>>>>>>tpm_tis_send_data which no >>>>>>>>>>>>>>longer calls >>>>>>>>>>>>>> request_locality, so add request_locality prior to >>>>>>>>>>>>>>tpm_tis_send_data >>>>>>>>>>>>>> calls. Also drop release_locality call in middleof >>>>>>>>>>>>>>probe_itpm, and >>>>>>>>>>>>>> keep locality until >>>>>>>>>>>>>>release_locality called at end of >>>>>>>>>>>>>>probe_itpm. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cc: Peter Huewe <peterhuewe-Mmb7MZpHnFY@public.gmane.org> >>>>>>>>>>>>>> Cc: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1560@public.gmane.orgtel.com> >>>>>>>>>>>>>> Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> >>>>>>>>>>>>>> Cc: Marcel Selhorst <tpmdd-yWjUBOtONefk1uMJSBkQmQ@public.gmane.org> >>>>>>>>>>>>>> Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> >>>>>>>>>>>>>> Reviewed-by: Jarkko Sakkinen >>>>>>>>>>><jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> >>>>>>>>>>>>>> Tested-by: Jarkko Sakkinen >>>>>>>>>>>>>><jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> >>>>>>>>>>>>>> Signed-off-by: Jarkko Sakkinen >>>>>>>>>>><jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> >>>>>>>>>>>>>>:040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >>>>>>>>>>>>>>72f21b446e45ea1003de75902b0553deb99157fd M drivers >>>>>>>>>>>>>> >>>>>>>>>>>>>I've looked again at the code in question, but could not find >>>>>>>>>>>>>anything that is obviously wrong there. Locality is now >>>>>>>>>>>>>requested/released at slightly different >>>>>>>>>>>>>points in the process than >>>>>>>>>>>>>before, but that's it. It does not seem to >>>>>>>>>>>>>cause problems with the >>>>>>>>>>>>>majority of TPMs, since you are the first to report any, so >>>>>>>>>>>maybe it >>>>>>>>>>>>>is a quirk that only affects this device. >>>>>>>>>>>>> >>>>>>>>>>>>>Perhaps Jerry can help, since this is his change? >>>>>>>>>>>>> >>>>>>>>>>>>>Alexander >>>>>>>>>>>>Getting some caffeine in me, and starting to >>>>>>>>>>>>take a look. Adding >>>>>>>>>>>>Jarkko as well since this might involve the >>>>>>>>>>>>general locality changes. >>>>>>>>>>>> >>>>>>>>>>>>Laurent, if I send you a patch with some >>>>>>>>>>>>debugging code added, would >>>>>>>>>>>>you be able to run it on that system? I wasn't >>>>>>>>>>>>running into issues >>>>>>>>>>>>on the system I had with a 1.2 device, but I no >>>>>>>>>>>>longer have access >>>>>>>>>>>>to it. I'll see if I can find one in our labs >>>>>>>>>>>>and reproduce it there. >>>>>>>>>>>Yes I should be able to do that >>>>>>>>>>Any findings? >>>>>>>>>> >>>>>>>>>>/Jarkko >>>>>>>>>Okay, finally getting back to this. Looking at the >>>>>>>>>code it isn't clear >>>>>>>>>to me >>>>>>>>>why the change is causing this. So while I stare at this some more >>>>>>>>>Laurent >>>>>>>>>could you reproduce it with this patch so I can see >>>>>>>>>what the status and >>>>>>>>>access registers look like? Does anyone else on here >>>>>>>>>happen to have a >>>>>>>>>Sinosun >>>>>>>>>tpm device? The systems I have access to with TPM1.2 >>>>>>>>>devices don't have >>>>>>>>>this >>>>>>>>>issue. >>>>>>>>> >>>>>>>>>--8<-- >>>>>>>>> >>>>>>>>>diff --git a/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>b/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>index fdde971bc810..7d60a7e4b50a 100644 >>>>>>>>>--- a/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>+++ b/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>@@ -258,6 +258,7 @@ static int >>>>>>>>>tpm_tis_send_data(struct tpm_chip *chip, >>>>>>>>>const u8 *buf, size_t len) >>>>>>>>> int rc, status, burstcnt; >>>>>>>>> size_t count = 0; >>>>>>>>> bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; >>>>>>>>>+ u8 access; >>>>>>>>> >>>>>>>>> status = tpm_tis_status(chip); >>>>>>>>> if ((status & TPM_STS_COMMAND_READY) == 0) { >>>>>>>>>@@ -292,6 +293,11 @@ static int >>>>>>>>>tpm_tis_send_data(struct tpm_chip *chip, >>>>>>>>>const u8 *buf, size_t len) >>>>>>>>> } >>>>>>>>> status = tpm_tis_status(chip); >>>>>>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { >>>>>>>>>+ rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), >>>>>>>>>&access); >>>>>>>>>+ if (rc < 0) >>>>>>>>>+ dev_info(&chip->dev, >>>>>>>>>"TPM_STS_DATA_EXPECT == 0: read >>>>>>>>>failure TPM_ACCESS(%d)\n", priv->locality); >>>>>>>>>+ else >>>>>>>>>+ dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: >>>>>>>>>locality: %d status: %x access: %x\n", priv->locality, >>>>>>>>>status, access); >>>>>>>>> rc = -EIO; >>>>>>>>> goto out_err; >>>>>>>>> } >>>>>>>>>@@ -309,6 +315,11 @@ static int >>>>>>>>>tpm_tis_send_data(struct tpm_chip *chip, >>>>>>>>>const u8 *buf, size_t len) >>>>>>>>> } >>>>>>>>> status = tpm_tis_status(chip); >>>>>>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { >>>>>>>>>+ rc = tpm_tis_read8(priv, >>>>>>>>>TPM_ACCESS(priv->locality), &access); >>>>>>>>>+ if (rc < 0) >>>>>>>>>+ dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read >>>>>>>>>failure TPM_ACCESS(%d)\n", priv->locality); >>>>>>>>>+ else >>>>>>>>>+ dev_info(&chip->dev, "TPM_STS_DATA_EXPECT >>>>>>>>>!= 0: locality: >>>>>>>>>%d status: %x access: %x\n", priv->locality, status, access); >>>>>>>>> rc = -EIO; >>>>>>>>> goto out_err; >>>>>>>>> } >>>>>>>>Please find here the dmesg output of the patched kernel >>>>>>>At least 0xff is corrupted value in senseful way. CPU fills the read >>>>>>>with ones for example for unaligned bus read. See table 19 >>>>>>>in PC client >>>>>>>spec. This can happen when you do unaligned read for example. >>>>>>> >>>>>>>Maybe TPM is unreachable i.e. powered off. Bit busy with >>>>>>>stuff ATM but >>>>>>>would probably make sense to compare that 0x81 to table 18 >>>>>>>in the same >>>>>>>spec. >>>>>>> >>>>>>>/Jarkko >>>>>>0x81 is saying the access register status is valid, and the locality >>>>>>is not active. That first bit means A Dynamic OS has not >>>>>>been previously >>>>>>established on the platform. Normally we would see 0xa1, which would >>>>>>mean valid register status, and the locality is active. >>>>>I think the important thing to note here is that STS has bits set that >>>>>should never be set. So we can conclude that TPM might be either >>>>> >>>>>1. Powered off >>>>>2. In some transition state? >>>>> >>>>>/Jarkko >>>>If it was powered off would we be getting a valid read from the access >>>>register? >>>I think there is no universal answer to that :-) >>> >>>Maybe adding a extra delay would be next test to make? If for random >>>reason it is in-between states... >>Any more ideas? >> >>The chip is definitely in a weird state :/ I tried several ways to >>reset the chip (windows, tpm-tools,...). >> >>I've been able to reset the chip via the bios (which now shows >>unowned) but chip is still locked apparently. >> >>But still with < 4.12 I'm able to get /some/ information Public EK, >>PCR,... out of the chip so it's not completely broken... > >OK correction the TPM is now unlocked (I let the computer running for >more than 24h with nothing accessing the TPM) and with 4.9 I've been >able to take the ownership again. > >Under 4.12 I still have the same errors as mentioned originally Still thinking about how to attack this. I don't think extending the timeout would change anything because it is reading the register, and thinking the status is valid because it reads 0xff. So it would still have that problem, right? Maybe a sanity check could be added to wait_for_tpm_stat() to first check that it didn't read 0xff before checking for the value it is looking for. Would that make sense Jarkko? diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c index 1d6729be4cd6..8b77fa2003ce 100644 --- a/drivers/char/tpm/tpm-interface.c +++ b/drivers/char/tpm/tpm-interface.c @@ -1087,7 +1087,7 @@ int wait_for_tpm_stat(struct tpm_chip *chip, u8 mask, unsigned long timeout, do { tpm_msleep(TPM_TIMEOUT); status = chip->ops->status(chip); - if ((status & mask) == mask) + if ((status != 0xff) && (status & mask) == mask) return 0; } while (time_before(jiffies, stop)); } ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ^ permalink raw reply related [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore @ 2017-11-10 2:19 ` Jerry Snitselaar 0 siblings, 0 replies; 62+ messages in thread From: Jerry Snitselaar @ 2017-11-10 2:19 UTC (permalink / raw) To: Laurent Bigonville Cc: Jarkko Sakkinen, Alexander.Steffen, tpmdd-devel, linux-integrity On Thu Nov 09 17, Jerry Snitselaar wrote: >On Thu Nov 09 17, Laurent Bigonville wrote: >>Le 09/11/17 a 01:04, Laurent Bigonville a ecrit : >>> >>> >>>Le 24/10/17 a 18:07, Jarkko Sakkinen a ecrit : >>>>On Tue, Oct 24, 2017 at 07:57:06AM -0700, Jerry Snitselaar wrote: >>>>>On Tue Oct 24 17, Jarkko Sakkinen wrote: >>>>>>On Mon, Oct 23, 2017 at 06:45:15AM -0700, Jerry Snitselaar wrote: >>>>>>>On Mon Oct 23 17, Jarkko Sakkinen wrote: >>>>>>>>On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote: >>>>>>>>>Le 14/10/17 a 10:13, Jerry Snitselaar a ecrit : >>>>>>>>>>On Wed Sep 06 17, Jarkko Sakkinen wrote: >>>>>>>>>>>On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent >>>>>>>>>>>Bigonville wrote: >>>>>>>>>>>>Le 31/08/17 a 18:40, Jerry Snitselaar a ecrit : >>>>>>>>>>>>>On Thu Aug 31 17, Alexander.Steffen@infineon.com wrote: >>>>>>>>>>>>>>>Le 29/08/17 a 18:35, Laurent Bigonville a ecrit : >>>>>>>>>>>>>>>>Le 29/08/17 a 18:00, >>>>>>>>>>>>>>>>Alexander.Steffen@infineon.com a ecrit : >>>>>>>>>>>>>>>>>>An idea how to troubleshoot this? >>>>>>>>>>>>>>>>>Can you run git bisect on the changes between 4.11 and >>>>>>>>>>>>4.12, so that >>>>>>>>>>>>>>>>>we find the offending commit? It is probably sufficient >>>>>>>>>>>>to limit the >>>>>>>>>>>>>>>>>search to commits that touch something in drivers/char/tpm. >>>>>>>>>>>>>>>>I'll try and keep you posted. >>>>>>>>>>>>>>>OK I've been able to bisect the problem >>>>>>>>>>>>>>>and the bad commit is: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >>>>>>>>>>>>>>>is the first bad commit >>>>>>>>>>>>>>>commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >>>>>>>>>>>>>>>Author: Jerry Snitselaar <jsnitsel@redhat.com> >>>>>>>>>>>>>>>Date: Mon Mar 27 08:46:04 2017 -0700 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> tpm_tis: convert to using locality callbacks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This patch converts tpm_tis to use >>>>>>>>>>>>>>>of the new tpm class ops >>>>>>>>>>>>>>> request_locality, and relinquish_locality. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> With the move to using the >>>>>>>>>>>>>>>callbacks, release_locality is >>>>>>>>>>>>>>>changed so >>>>>>>>>>>>>>> that we now release the locality even if there is no >>>>>>>>>>>>>>>request pending. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This required some changes to the tpm_tis_core_init >>>>>>>>>>>>code path to >>>>>>>>>>>>>>> make sure locality is requested when needed: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - tpm2_probe code path will end up calling >>>>>>>>>>>>>>>request/release through >>>>>>>>>>>>>>> callbacks, so request_locality prior to >>>>>>>>>>>>tpm2_probe not needed. >>>>>>>>>>>>>>> - probe_itpm makes calls to >>>>>>>>>>>>>>>tpm_tis_send_data which no >>>>>>>>>>>>>>>longer calls >>>>>>>>>>>>>>> request_locality, so add request_locality prior to >>>>>>>>>>>>>>>tpm_tis_send_data >>>>>>>>>>>>>>> calls. Also drop release_locality call in middleof >>>>>>>>>>>>>>>probe_itpm, and >>>>>>>>>>>>>>> keep locality until >>>>>>>>>>>>>>>release_locality called at end of >>>>>>>>>>>>>>>probe_itpm. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cc: Peter Huewe <peterhuewe@gmx.de> >>>>>>>>>>>>>>> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>>> Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> >>>>>>>>>>>>>>> Cc: Marcel Selhorst <tpmdd@selhorst.net> >>>>>>>>>>>>>>> Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> >>>>>>>>>>>>>>> Reviewed-by: Jarkko Sakkinen >>>>>>>>>>>><jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>>> Tested-by: Jarkko Sakkinen >>>>>>>>>>>>>>><jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>>> Signed-off-by: Jarkko Sakkinen >>>>>>>>>>>><jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>>>:040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >>>>>>>>>>>>>>>72f21b446e45ea1003de75902b0553deb99157fd M drivers >>>>>>>>>>>>>>> >>>>>>>>>>>>>>I've looked again at the code in question, but could not find >>>>>>>>>>>>>>anything that is obviously wrong there. Locality is now >>>>>>>>>>>>>>requested/released at slightly different >>>>>>>>>>>>>>points in the process than >>>>>>>>>>>>>>before, but that's it. It does not seem to >>>>>>>>>>>>>>cause problems with the >>>>>>>>>>>>>>majority of TPMs, since you are the first to report any, so >>>>>>>>>>>>maybe it >>>>>>>>>>>>>>is a quirk that only affects this device. >>>>>>>>>>>>>> >>>>>>>>>>>>>>Perhaps Jerry can help, since this is his change? >>>>>>>>>>>>>> >>>>>>>>>>>>>>Alexander >>>>>>>>>>>>>Getting some caffeine in me, and starting to >>>>>>>>>>>>>take a look. Adding >>>>>>>>>>>>>Jarkko as well since this might involve the >>>>>>>>>>>>>general locality changes. >>>>>>>>>>>>> >>>>>>>>>>>>>Laurent, if I send you a patch with some >>>>>>>>>>>>>debugging code added, would >>>>>>>>>>>>>you be able to run it on that system? I wasn't >>>>>>>>>>>>>running into issues >>>>>>>>>>>>>on the system I had with a 1.2 device, but I >>>>>>>>>>>>>no longer have access >>>>>>>>>>>>>to it. I'll see if I can find one in our labs >>>>>>>>>>>>>and reproduce it there. >>>>>>>>>>>>Yes I should be able to do that >>>>>>>>>>>Any findings? >>>>>>>>>>> >>>>>>>>>>>/Jarkko >>>>>>>>>>Okay, finally getting back to this. Looking at the >>>>>>>>>>code it isn't clear >>>>>>>>>>to me >>>>>>>>>>why the change is causing this. So while I stare at this some more >>>>>>>>>>Laurent >>>>>>>>>>could you reproduce it with this patch so I can see >>>>>>>>>>what the status and >>>>>>>>>>access registers look like? Does anyone else on here >>>>>>>>>>happen to have a >>>>>>>>>>Sinosun >>>>>>>>>>tpm device? The systems I have access to with TPM1.2 >>>>>>>>>>devices don't have >>>>>>>>>>this >>>>>>>>>>issue. >>>>>>>>>> >>>>>>>>>>--8<-- >>>>>>>>>> >>>>>>>>>>diff --git a/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>>b/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>>index fdde971bc810..7d60a7e4b50a 100644 >>>>>>>>>>--- a/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>>+++ b/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>>@@ -258,6 +258,7 @@ static int >>>>>>>>>>tpm_tis_send_data(struct tpm_chip *chip, >>>>>>>>>>const u8 *buf, size_t len) >>>>>>>>>> int rc, status, burstcnt; >>>>>>>>>> size_t count = 0; >>>>>>>>>> bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; >>>>>>>>>>+ u8 access; >>>>>>>>>> >>>>>>>>>> status = tpm_tis_status(chip); >>>>>>>>>> if ((status & TPM_STS_COMMAND_READY) == 0) { >>>>>>>>>>@@ -292,6 +293,11 @@ static int >>>>>>>>>>tpm_tis_send_data(struct tpm_chip *chip, >>>>>>>>>>const u8 *buf, size_t len) >>>>>>>>>> } >>>>>>>>>> status = tpm_tis_status(chip); >>>>>>>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { >>>>>>>>>>+ rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), >>>>>>>>>>&access); >>>>>>>>>>+ if (rc < 0) >>>>>>>>>>+ dev_info(&chip->dev, >>>>>>>>>>"TPM_STS_DATA_EXPECT == 0: read >>>>>>>>>>failure TPM_ACCESS(%d)\n", priv->locality); >>>>>>>>>>+ else >>>>>>>>>>+ dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: >>>>>>>>>>locality: %d status: %x access: %x\n", >>>>>>>>>>priv->locality, status, access); >>>>>>>>>> rc = -EIO; >>>>>>>>>> goto out_err; >>>>>>>>>> } >>>>>>>>>>@@ -309,6 +315,11 @@ static int >>>>>>>>>>tpm_tis_send_data(struct tpm_chip *chip, >>>>>>>>>>const u8 *buf, size_t len) >>>>>>>>>> } >>>>>>>>>> status = tpm_tis_status(chip); >>>>>>>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { >>>>>>>>>>+ rc = tpm_tis_read8(priv, >>>>>>>>>>TPM_ACCESS(priv->locality), &access); >>>>>>>>>>+ if (rc < 0) >>>>>>>>>>+ dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read >>>>>>>>>>failure TPM_ACCESS(%d)\n", priv->locality); >>>>>>>>>>+ else >>>>>>>>>>+ dev_info(&chip->dev, >>>>>>>>>>"TPM_STS_DATA_EXPECT != 0: locality: >>>>>>>>>>%d status: %x access: %x\n", priv->locality, status, access); >>>>>>>>>> rc = -EIO; >>>>>>>>>> goto out_err; >>>>>>>>>> } >>>>>>>>>Please find here the dmesg output of the patched kernel >>>>>>>>At least 0xff is corrupted value in senseful way. CPU fills the read >>>>>>>>with ones for example for unaligned bus read. See table >>>>>>>>19 in PC client >>>>>>>>spec. This can happen when you do unaligned read for example. >>>>>>>> >>>>>>>>Maybe TPM is unreachable i.e. powered off. Bit busy with >>>>>>>>stuff ATM but >>>>>>>>would probably make sense to compare that 0x81 to table >>>>>>>>18 in the same >>>>>>>>spec. >>>>>>>> >>>>>>>>/Jarkko >>>>>>>0x81 is saying the access register status is valid, and the locality >>>>>>>is not active. That first bit means A Dynamic OS has not >>>>>>>been previously >>>>>>>established on the platform. Normally we would see 0xa1, which would >>>>>>>mean valid register status, and the locality is active. >>>>>>I think the important thing to note here is that STS has bits set that >>>>>>should never be set. So we can conclude that TPM might be either >>>>>> >>>>>>1. Powered off >>>>>>2. In some transition state? >>>>>> >>>>>>/Jarkko >>>>>If it was powered off would we be getting a valid read from the access >>>>>register? >>>>I think there is no universal answer to that :-) >>>> >>>>Maybe adding a extra delay would be next test to make? If for random >>>>reason it is in-between states... >>>Any more ideas? >>> >>>The chip is definitely in a weird state :/ I tried several ways to >>>reset the chip (windows, tpm-tools,...). >>> >>>I've been able to reset the chip via the bios (which now shows >>>unowned) but chip is still locked apparently. >>> >>>But still with < 4.12 I'm able to get /some/ information Public >>>EK, PCR,... out of the chip so it's not completely broken... >> >>OK correction the TPM is now unlocked (I let the computer running >>for more than 24h with nothing accessing the TPM) and with 4.9 I've >>been able to take the ownership again. >> >>Under 4.12 I still have the same errors as mentioned originally > > >Still thinking about how to attack this. I don't think extending the timeout >would change anything because it is reading the register, and thinking the >status is valid because it reads 0xff. So it would still have that problem, >right? > >Maybe a sanity check could be added to wait_for_tpm_stat() to >first check that it didn't read 0xff before checking for the value it >is looking for. Would that make sense Jarkko? > >diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c >index 1d6729be4cd6..8b77fa2003ce 100644 >--- a/drivers/char/tpm/tpm-interface.c >+++ b/drivers/char/tpm/tpm-interface.c >@@ -1087,7 +1087,7 @@ int wait_for_tpm_stat(struct tpm_chip *chip, u8 mask, unsigned long timeout, > do { > tpm_msleep(TPM_TIMEOUT); > status = chip->ops->status(chip); >- if ((status & mask) == mask) >+ if ((status != 0xff) && (status & mask) == mask) > return 0; > } while (time_before(jiffies, stop)); > } > Actually I'm reading through the tpm profile spec again, and 6.1 FIFO Interface Locality Usage per Register has a table that I think explains what is going on. Since the access register is showing 0x81, which means access register bits are valid and the locality is not active. Table 39 in 6.1 says in the case where active locality is not set, or set for another locality, TPM_STS_x register reads return FFh. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: tpm device not showing up in /dev anymore @ 2017-11-10 2:19 ` Jerry Snitselaar 0 siblings, 0 replies; 62+ messages in thread From: Jerry Snitselaar @ 2017-11-10 2:19 UTC (permalink / raw) To: Laurent Bigonville Cc: linux-integrity-u79uwXL29TY76Z2rM5mHXA, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Jarkko Sakkinen On Thu Nov 09 17, Jerry Snitselaar wrote: >On Thu Nov 09 17, Laurent Bigonville wrote: >>Le 09/11/17 à 01:04, Laurent Bigonville a écrit : >>> >>> >>>Le 24/10/17 à 18:07, Jarkko Sakkinen a écrit : >>>>On Tue, Oct 24, 2017 at 07:57:06AM -0700, Jerry Snitselaar wrote: >>>>>On Tue Oct 24 17, Jarkko Sakkinen wrote: >>>>>>On Mon, Oct 23, 2017 at 06:45:15AM -0700, Jerry Snitselaar wrote: >>>>>>>On Mon Oct 23 17, Jarkko Sakkinen wrote: >>>>>>>>On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote: >>>>>>>>>Le 14/10/17 à 10:13, Jerry Snitselaar a écrit : >>>>>>>>>>On Wed Sep 06 17, Jarkko Sakkinen wrote: >>>>>>>>>>>On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent >>>>>>>>>>>Bigonville wrote: >>>>>>>>>>>>Le 31/08/17 à 18:40, Jerry Snitselaar a écrit : >>>>>>>>>>>>>On Thu Aug 31 17, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org wrote: >>>>>>>>>>>>>>>Le 29/08/17 à 18:35, Laurent Bigonville a écrit : >>>>>>>>>>>>>>>>Le 29/08/17 à 18:00, >>>>>>>>>>>>>>>>Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org a écrit : >>>>>>>>>>>>>>>>>>An idea how to troubleshoot this? >>>>>>>>>>>>>>>>>Can you run git bisect on the changes between 4.11 and >>>>>>>>>>>>4.12, so that >>>>>>>>>>>>>>>>>we find the offending commit? It is probably sufficient >>>>>>>>>>>>to limit the >>>>>>>>>>>>>>>>>search to commits that touch something in drivers/char/tpm. >>>>>>>>>>>>>>>>I'll try and keep you posted. >>>>>>>>>>>>>>>OK I've been able to bisect the problem >>>>>>>>>>>>>>>and the bad commit is: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >>>>>>>>>>>>>>>is the first bad commit >>>>>>>>>>>>>>>commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >>>>>>>>>>>>>>>Author: Jerry Snitselaar <jsnitsel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> >>>>>>>>>>>>>>>Date: Mon Mar 27 08:46:04 2017 -0700 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> tpm_tis: convert to using locality callbacks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This patch converts tpm_tis to use >>>>>>>>>>>>>>>of the new tpm class ops >>>>>>>>>>>>>>> request_locality, and relinquish_locality. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> With the move to using the >>>>>>>>>>>>>>>callbacks, release_locality is >>>>>>>>>>>>>>>changed so >>>>>>>>>>>>>>> that we now release the locality even if there is no >>>>>>>>>>>>>>>request pending. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This required some changes to the tpm_tis_core_init >>>>>>>>>>>>code path to >>>>>>>>>>>>>>> make sure locality is requested when needed: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - tpm2_probe code path will end up calling >>>>>>>>>>>>>>>request/release through >>>>>>>>>>>>>>> callbacks, so request_locality prior to >>>>>>>>>>>>tpm2_probe not needed. >>>>>>>>>>>>>>> - probe_itpm makes calls to >>>>>>>>>>>>>>>tpm_tis_send_data which no >>>>>>>>>>>>>>>longer calls >>>>>>>>>>>>>>> request_locality, so add request_locality prior to >>>>>>>>>>>>>>>tpm_tis_send_data >>>>>>>>>>>>>>> calls. Also drop release_locality call in middleof >>>>>>>>>>>>>>>probe_itpm, and >>>>>>>>>>>>>>> keep locality until >>>>>>>>>>>>>>>release_locality called at end of >>>>>>>>>>>>>>>probe_itpm. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cc: Peter Huewe <peterhuewe-Mmb7MZpHnFY@public.gmane.org> >>>>>>>>>>>>>>> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>>> Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> >>>>>>>>>>>>>>> Cc: Marcel Selhorst <tpmdd-yWjUBOtONefk1uMJSBkQmQ@public.gmane.org> >>>>>>>>>>>>>>> Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> >>>>>>>>>>>>>>> Reviewed-by: Jarkko Sakkinen >>>>>>>>>>>><jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> >>>>>>>>>>>>>>> Tested-by: Jarkko Sakkinen >>>>>>>>>>>>>>><jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> >>>>>>>>>>>>>>> Signed-off-by: Jarkko Sakkinen >>>>>>>>>>>><jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> >>>>>>>>>>>>>>>:040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >>>>>>>>>>>>>>>72f21b446e45ea1003de75902b0553deb99157fd M drivers >>>>>>>>>>>>>>> >>>>>>>>>>>>>>I've looked again at the code in question, but could not find >>>>>>>>>>>>>>anything that is obviously wrong there. Locality is now >>>>>>>>>>>>>>requested/released at slightly different >>>>>>>>>>>>>>points in the process than >>>>>>>>>>>>>>before, but that's it. It does not seem to >>>>>>>>>>>>>>cause problems with the >>>>>>>>>>>>>>majority of TPMs, since you are the first to report any, so >>>>>>>>>>>>maybe it >>>>>>>>>>>>>>is a quirk that only affects this device. >>>>>>>>>>>>>> >>>>>>>>>>>>>>Perhaps Jerry can help, since this is his change? >>>>>>>>>>>>>> >>>>>>>>>>>>>>Alexander >>>>>>>>>>>>>Getting some caffeine in me, and starting to >>>>>>>>>>>>>take a look. Adding >>>>>>>>>>>>>Jarkko as well since this might involve the >>>>>>>>>>>>>general locality changes. >>>>>>>>>>>>> >>>>>>>>>>>>>Laurent, if I send you a patch with some >>>>>>>>>>>>>debugging code added, would >>>>>>>>>>>>>you be able to run it on that system? I wasn't >>>>>>>>>>>>>running into issues >>>>>>>>>>>>>on the system I had with a 1.2 device, but I >>>>>>>>>>>>>no longer have access >>>>>>>>>>>>>to it. I'll see if I can find one in our labs >>>>>>>>>>>>>and reproduce it there. >>>>>>>>>>>>Yes I should be able to do that >>>>>>>>>>>Any findings? >>>>>>>>>>> >>>>>>>>>>>/Jarkko >>>>>>>>>>Okay, finally getting back to this. Looking at the >>>>>>>>>>code it isn't clear >>>>>>>>>>to me >>>>>>>>>>why the change is causing this. So while I stare at this some more >>>>>>>>>>Laurent >>>>>>>>>>could you reproduce it with this patch so I can see >>>>>>>>>>what the status and >>>>>>>>>>access registers look like? Does anyone else on here >>>>>>>>>>happen to have a >>>>>>>>>>Sinosun >>>>>>>>>>tpm device? The systems I have access to with TPM1.2 >>>>>>>>>>devices don't have >>>>>>>>>>this >>>>>>>>>>issue. >>>>>>>>>> >>>>>>>>>>--8<-- >>>>>>>>>> >>>>>>>>>>diff --git a/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>>b/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>>index fdde971bc810..7d60a7e4b50a 100644 >>>>>>>>>>--- a/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>>+++ b/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>>@@ -258,6 +258,7 @@ static int >>>>>>>>>>tpm_tis_send_data(struct tpm_chip *chip, >>>>>>>>>>const u8 *buf, size_t len) >>>>>>>>>> int rc, status, burstcnt; >>>>>>>>>> size_t count = 0; >>>>>>>>>> bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; >>>>>>>>>>+ u8 access; >>>>>>>>>> >>>>>>>>>> status = tpm_tis_status(chip); >>>>>>>>>> if ((status & TPM_STS_COMMAND_READY) == 0) { >>>>>>>>>>@@ -292,6 +293,11 @@ static int >>>>>>>>>>tpm_tis_send_data(struct tpm_chip *chip, >>>>>>>>>>const u8 *buf, size_t len) >>>>>>>>>> } >>>>>>>>>> status = tpm_tis_status(chip); >>>>>>>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { >>>>>>>>>>+ rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), >>>>>>>>>>&access); >>>>>>>>>>+ if (rc < 0) >>>>>>>>>>+ dev_info(&chip->dev, >>>>>>>>>>"TPM_STS_DATA_EXPECT == 0: read >>>>>>>>>>failure TPM_ACCESS(%d)\n", priv->locality); >>>>>>>>>>+ else >>>>>>>>>>+ dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: >>>>>>>>>>locality: %d status: %x access: %x\n", >>>>>>>>>>priv->locality, status, access); >>>>>>>>>> rc = -EIO; >>>>>>>>>> goto out_err; >>>>>>>>>> } >>>>>>>>>>@@ -309,6 +315,11 @@ static int >>>>>>>>>>tpm_tis_send_data(struct tpm_chip *chip, >>>>>>>>>>const u8 *buf, size_t len) >>>>>>>>>> } >>>>>>>>>> status = tpm_tis_status(chip); >>>>>>>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { >>>>>>>>>>+ rc = tpm_tis_read8(priv, >>>>>>>>>>TPM_ACCESS(priv->locality), &access); >>>>>>>>>>+ if (rc < 0) >>>>>>>>>>+ dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read >>>>>>>>>>failure TPM_ACCESS(%d)\n", priv->locality); >>>>>>>>>>+ else >>>>>>>>>>+ dev_info(&chip->dev, >>>>>>>>>>"TPM_STS_DATA_EXPECT != 0: locality: >>>>>>>>>>%d status: %x access: %x\n", priv->locality, status, access); >>>>>>>>>> rc = -EIO; >>>>>>>>>> goto out_err; >>>>>>>>>> } >>>>>>>>>Please find here the dmesg output of the patched kernel >>>>>>>>At least 0xff is corrupted value in senseful way. CPU fills the read >>>>>>>>with ones for example for unaligned bus read. See table >>>>>>>>19 in PC client >>>>>>>>spec. This can happen when you do unaligned read for example. >>>>>>>> >>>>>>>>Maybe TPM is unreachable i.e. powered off. Bit busy with >>>>>>>>stuff ATM but >>>>>>>>would probably make sense to compare that 0x81 to table >>>>>>>>18 in the same >>>>>>>>spec. >>>>>>>> >>>>>>>>/Jarkko >>>>>>>0x81 is saying the access register status is valid, and the locality >>>>>>>is not active. That first bit means A Dynamic OS has not >>>>>>>been previously >>>>>>>established on the platform. Normally we would see 0xa1, which would >>>>>>>mean valid register status, and the locality is active. >>>>>>I think the important thing to note here is that STS has bits set that >>>>>>should never be set. So we can conclude that TPM might be either >>>>>> >>>>>>1. Powered off >>>>>>2. In some transition state? >>>>>> >>>>>>/Jarkko >>>>>If it was powered off would we be getting a valid read from the access >>>>>register? >>>>I think there is no universal answer to that :-) >>>> >>>>Maybe adding a extra delay would be next test to make? If for random >>>>reason it is in-between states... >>>Any more ideas? >>> >>>The chip is definitely in a weird state :/ I tried several ways to >>>reset the chip (windows, tpm-tools,...). >>> >>>I've been able to reset the chip via the bios (which now shows >>>unowned) but chip is still locked apparently. >>> >>>But still with < 4.12 I'm able to get /some/ information Public >>>EK, PCR,... out of the chip so it's not completely broken... >> >>OK correction the TPM is now unlocked (I let the computer running >>for more than 24h with nothing accessing the TPM) and with 4.9 I've >>been able to take the ownership again. >> >>Under 4.12 I still have the same errors as mentioned originally > > >Still thinking about how to attack this. I don't think extending the timeout >would change anything because it is reading the register, and thinking the >status is valid because it reads 0xff. So it would still have that problem, >right? > >Maybe a sanity check could be added to wait_for_tpm_stat() to >first check that it didn't read 0xff before checking for the value it >is looking for. Would that make sense Jarkko? > >diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c >index 1d6729be4cd6..8b77fa2003ce 100644 >--- a/drivers/char/tpm/tpm-interface.c >+++ b/drivers/char/tpm/tpm-interface.c >@@ -1087,7 +1087,7 @@ int wait_for_tpm_stat(struct tpm_chip *chip, u8 mask, unsigned long timeout, > do { > tpm_msleep(TPM_TIMEOUT); > status = chip->ops->status(chip); >- if ((status & mask) == mask) >+ if ((status != 0xff) && (status & mask) == mask) > return 0; > } while (time_before(jiffies, stop)); > } > Actually I'm reading through the tpm profile spec again, and 6.1 FIFO Interface Locality Usage per Register has a table that I think explains what is going on. Since the access register is showing 0x81, which means access register bits are valid and the locality is not active. Table 39 in 6.1 says in the case where active locality is not set, or set for another locality, TPM_STS_x register reads return FFh. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2017-11-09 19:58 ` Laurent Bigonville (?) (?) @ 2017-11-10 0:28 ` Jerry Snitselaar 2017-11-10 7:07 ` Jerry Snitselaar -1 siblings, 1 reply; 62+ messages in thread From: Jerry Snitselaar @ 2017-11-10 0:28 UTC (permalink / raw) To: Laurent Bigonville; +Cc: Jarkko Sakkinen, Alexander.Steffen, linux-integrity On Thu Nov 09 17, Laurent Bigonville wrote: >Le 09/11/17 a 01:04, Laurent Bigonville a ecrit : >> >> >>Le 24/10/17 a 18:07, Jarkko Sakkinen a ecrit : >>>On Tue, Oct 24, 2017 at 07:57:06AM -0700, Jerry Snitselaar wrote: >>>>On Tue Oct 24 17, Jarkko Sakkinen wrote: >>>>>On Mon, Oct 23, 2017 at 06:45:15AM -0700, Jerry Snitselaar wrote: >>>>>>On Mon Oct 23 17, Jarkko Sakkinen wrote: >>>>>>>On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote: >>>>>>>>Le 14/10/17 a 10:13, Jerry Snitselaar a ecrit : >>>>>>>>>On Wed Sep 06 17, Jarkko Sakkinen wrote: >>>>>>>>>>On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent >>>>>>>>>>Bigonville wrote: >>>>>>>>>>>Le 31/08/17 a 18:40, Jerry Snitselaar a ecrit : >>>>>>>>>>>>On Thu Aug 31 17, Alexander.Steffen@infineon.com wrote: >>>>>>>>>>>>>>Le 29/08/17 a 18:35, Laurent Bigonville a ecrit : >>>>>>>>>>>>>>>Le 29/08/17 a 18:00, >>>>>>>>>>>>>>>Alexander.Steffen@infineon.com a ecrit : >>>>>>>>>>>>>>>>>An idea how to troubleshoot this? >>>>>>>>>>>>>>>>Can you run git bisect on the changes between 4.11 and >>>>>>>>>>>4.12, so that >>>>>>>>>>>>>>>>we find the offending commit? It is probably sufficient >>>>>>>>>>>to limit the >>>>>>>>>>>>>>>>search to commits that touch something in drivers/char/tpm. >>>>>>>>>>>>>>>I'll try and keep you posted. >>>>>>>>>>>>>>OK I've been able to bisect the problem and >>>>>>>>>>>>>>the bad commit is: >>>>>>>>>>>>>> >>>>>>>>>>>>>>e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is >>>>>>>>>>>>>>the first bad commit >>>>>>>>>>>>>>commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >>>>>>>>>>>>>>Author: Jerry Snitselaar <jsnitsel@redhat.com> >>>>>>>>>>>>>>Date: Mon Mar 27 08:46:04 2017 -0700 >>>>>>>>>>>>>> >>>>>>>>>>>>>> tpm_tis: convert to using locality callbacks >>>>>>>>>>>>>> >>>>>>>>>>>>>> This patch converts tpm_tis to use of >>>>>>>>>>>>>>the new tpm class ops >>>>>>>>>>>>>> request_locality, and relinquish_locality. >>>>>>>>>>>>>> >>>>>>>>>>>>>> With the move to using the callbacks, >>>>>>>>>>>>>>release_locality is >>>>>>>>>>>>>>changed so >>>>>>>>>>>>>> that we now release the locality even if there is no >>>>>>>>>>>>>>request pending. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This required some changes to the tpm_tis_core_init >>>>>>>>>>>code path to >>>>>>>>>>>>>> make sure locality is requested when needed: >>>>>>>>>>>>>> >>>>>>>>>>>>>> - tpm2_probe code path will end up calling >>>>>>>>>>>>>>request/release through >>>>>>>>>>>>>> callbacks, so request_locality prior to >>>>>>>>>>>tpm2_probe not needed. >>>>>>>>>>>>>> - probe_itpm makes calls to >>>>>>>>>>>>>>tpm_tis_send_data which no >>>>>>>>>>>>>>longer calls >>>>>>>>>>>>>> request_locality, so add request_locality prior to >>>>>>>>>>>>>>tpm_tis_send_data >>>>>>>>>>>>>> calls. Also drop release_locality call in middleof >>>>>>>>>>>>>>probe_itpm, and >>>>>>>>>>>>>> keep locality until >>>>>>>>>>>>>>release_locality called at end of >>>>>>>>>>>>>>probe_itpm. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cc: Peter Huewe <peterhuewe@gmx.de> >>>>>>>>>>>>>> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>> Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> >>>>>>>>>>>>>> Cc: Marcel Selhorst <tpmdd@selhorst.net> >>>>>>>>>>>>>> Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> >>>>>>>>>>>>>> Reviewed-by: Jarkko Sakkinen >>>>>>>>>>><jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>> Tested-by: Jarkko Sakkinen >>>>>>>>>>>>>><jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>> Signed-off-by: Jarkko Sakkinen >>>>>>>>>>><jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>>:040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >>>>>>>>>>>>>>72f21b446e45ea1003de75902b0553deb99157fd M drivers >>>>>>>>>>>>>> >>>>>>>>>>>>>I've looked again at the code in question, but could not find >>>>>>>>>>>>>anything that is obviously wrong there. Locality is now >>>>>>>>>>>>>requested/released at slightly different >>>>>>>>>>>>>points in the process than >>>>>>>>>>>>>before, but that's it. It does not seem to >>>>>>>>>>>>>cause problems with the >>>>>>>>>>>>>majority of TPMs, since you are the first to report any, so >>>>>>>>>>>maybe it >>>>>>>>>>>>>is a quirk that only affects this device. >>>>>>>>>>>>> >>>>>>>>>>>>>Perhaps Jerry can help, since this is his change? >>>>>>>>>>>>> >>>>>>>>>>>>>Alexander >>>>>>>>>>>>Getting some caffeine in me, and starting to >>>>>>>>>>>>take a look. Adding >>>>>>>>>>>>Jarkko as well since this might involve the >>>>>>>>>>>>general locality changes. >>>>>>>>>>>> >>>>>>>>>>>>Laurent, if I send you a patch with some >>>>>>>>>>>>debugging code added, would >>>>>>>>>>>>you be able to run it on that system? I wasn't >>>>>>>>>>>>running into issues >>>>>>>>>>>>on the system I had with a 1.2 device, but I no >>>>>>>>>>>>longer have access >>>>>>>>>>>>to it. I'll see if I can find one in our labs >>>>>>>>>>>>and reproduce it there. >>>>>>>>>>>Yes I should be able to do that >>>>>>>>>>Any findings? >>>>>>>>>> >>>>>>>>>>/Jarkko >>>>>>>>>Okay, finally getting back to this. Looking at the >>>>>>>>>code it isn't clear >>>>>>>>>to me >>>>>>>>>why the change is causing this. So while I stare at this some more >>>>>>>>>Laurent >>>>>>>>>could you reproduce it with this patch so I can see >>>>>>>>>what the status and >>>>>>>>>access registers look like? Does anyone else on here >>>>>>>>>happen to have a >>>>>>>>>Sinosun >>>>>>>>>tpm device? The systems I have access to with TPM1.2 >>>>>>>>>devices don't have >>>>>>>>>this >>>>>>>>>issue. >>>>>>>>> >>>>>>>>>--8<-- >>>>>>>>> >>>>>>>>>diff --git a/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>b/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>index fdde971bc810..7d60a7e4b50a 100644 >>>>>>>>>--- a/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>+++ b/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>@@ -258,6 +258,7 @@ static int >>>>>>>>>tpm_tis_send_data(struct tpm_chip *chip, >>>>>>>>>const u8 *buf, size_t len) >>>>>>>>> int rc, status, burstcnt; >>>>>>>>> size_t count = 0; >>>>>>>>> bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; >>>>>>>>>+ u8 access; >>>>>>>>> >>>>>>>>> status = tpm_tis_status(chip); >>>>>>>>> if ((status & TPM_STS_COMMAND_READY) == 0) { >>>>>>>>>@@ -292,6 +293,11 @@ static int >>>>>>>>>tpm_tis_send_data(struct tpm_chip *chip, >>>>>>>>>const u8 *buf, size_t len) >>>>>>>>> } >>>>>>>>> status = tpm_tis_status(chip); >>>>>>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { >>>>>>>>>+ rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), >>>>>>>>>&access); >>>>>>>>>+ if (rc < 0) >>>>>>>>>+ dev_info(&chip->dev, >>>>>>>>>"TPM_STS_DATA_EXPECT == 0: read >>>>>>>>>failure TPM_ACCESS(%d)\n", priv->locality); >>>>>>>>>+ else >>>>>>>>>+ dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: >>>>>>>>>locality: %d status: %x access: %x\n", priv->locality, >>>>>>>>>status, access); >>>>>>>>> rc = -EIO; >>>>>>>>> goto out_err; >>>>>>>>> } >>>>>>>>>@@ -309,6 +315,11 @@ static int >>>>>>>>>tpm_tis_send_data(struct tpm_chip *chip, >>>>>>>>>const u8 *buf, size_t len) >>>>>>>>> } >>>>>>>>> status = tpm_tis_status(chip); >>>>>>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { >>>>>>>>>+ rc = tpm_tis_read8(priv, >>>>>>>>>TPM_ACCESS(priv->locality), &access); >>>>>>>>>+ if (rc < 0) >>>>>>>>>+ dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read >>>>>>>>>failure TPM_ACCESS(%d)\n", priv->locality); >>>>>>>>>+ else >>>>>>>>>+ dev_info(&chip->dev, "TPM_STS_DATA_EXPECT >>>>>>>>>!= 0: locality: >>>>>>>>>%d status: %x access: %x\n", priv->locality, status, access); >>>>>>>>> rc = -EIO; >>>>>>>>> goto out_err; >>>>>>>>> } >>>>>>>>Please find here the dmesg output of the patched kernel >>>>>>>At least 0xff is corrupted value in senseful way. CPU fills the read >>>>>>>with ones for example for unaligned bus read. See table 19 >>>>>>>in PC client >>>>>>>spec. This can happen when you do unaligned read for example. >>>>>>> >>>>>>>Maybe TPM is unreachable i.e. powered off. Bit busy with >>>>>>>stuff ATM but >>>>>>>would probably make sense to compare that 0x81 to table 18 >>>>>>>in the same >>>>>>>spec. >>>>>>> >>>>>>>/Jarkko >>>>>>0x81 is saying the access register status is valid, and the locality >>>>>>is not active. That first bit means A Dynamic OS has not >>>>>>been previously >>>>>>established on the platform. Normally we would see 0xa1, which would >>>>>>mean valid register status, and the locality is active. >>>>>I think the important thing to note here is that STS has bits set that >>>>>should never be set. So we can conclude that TPM might be either >>>>> >>>>>1. Powered off >>>>>2. In some transition state? >>>>> >>>>>/Jarkko >>>>If it was powered off would we be getting a valid read from the access >>>>register? >>>I think there is no universal answer to that :-) >>> >>>Maybe adding a extra delay would be next test to make? If for random >>>reason it is in-between states... >>Any more ideas? >> >>The chip is definitely in a weird state :/ I tried several ways to >>reset the chip (windows, tpm-tools,...). >> >>I've been able to reset the chip via the bios (which now shows >>unowned) but chip is still locked apparently. >> >>But still with < 4.12 I'm able to get /some/ information Public EK, >>PCR,... out of the chip so it's not completely broken... > >OK correction the TPM is now unlocked (I let the computer running for >more than 24h with nothing accessing the TPM) and with 4.9 I've been >able to take the ownership again. > >Under 4.12 I still have the same errors as mentioned originally Hi Laurent, Would it be possible for you to run ftrace from boot with the following kernel parameters: ftrace=function_graph ftrace_filter=tpm* and then send me the results of 'cat /sys/kernel/debug/tracing/trace' ? ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2017-11-10 0:28 ` [tpmdd-devel] " Jerry Snitselaar @ 2017-11-10 7:07 ` Jerry Snitselaar 2017-11-10 8:21 ` Laurent Bigonville 0 siblings, 1 reply; 62+ messages in thread From: Jerry Snitselaar @ 2017-11-10 7:07 UTC (permalink / raw) To: Laurent Bigonville; +Cc: Jarkko Sakkinen, Alexander.Steffen, linux-integrity On Thu Nov 09 17, Jerry Snitselaar wrote: >On Thu Nov 09 17, Laurent Bigonville wrote: >>Le 09/11/17 a 01:04, Laurent Bigonville a ecrit : >>> >>> >>>Le 24/10/17 a 18:07, Jarkko Sakkinen a ecrit : >>>>On Tue, Oct 24, 2017 at 07:57:06AM -0700, Jerry Snitselaar wrote: >>>>>On Tue Oct 24 17, Jarkko Sakkinen wrote: >>>>>>On Mon, Oct 23, 2017 at 06:45:15AM -0700, Jerry Snitselaar wrote: >>>>>>>On Mon Oct 23 17, Jarkko Sakkinen wrote: >>>>>>>>On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote: >>>>>>>>>Le 14/10/17 a 10:13, Jerry Snitselaar a ecrit : >>>>>>>>>>On Wed Sep 06 17, Jarkko Sakkinen wrote: >>>>>>>>>>>On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent >>>>>>>>>>>Bigonville wrote: >>>>>>>>>>>>Le 31/08/17 a 18:40, Jerry Snitselaar a ecrit : >>>>>>>>>>>>>On Thu Aug 31 17, Alexander.Steffen@infineon.com wrote: >>>>>>>>>>>>>>>Le 29/08/17 a 18:35, Laurent Bigonville a ecrit : >>>>>>>>>>>>>>>>Le 29/08/17 a 18:00, >>>>>>>>>>>>>>>>Alexander.Steffen@infineon.com a ecrit : >>>>>>>>>>>>>>>>>>An idea how to troubleshoot this? >>>>>>>>>>>>>>>>>Can you run git bisect on the changes between 4.11 and >>>>>>>>>>>>4.12, so that >>>>>>>>>>>>>>>>>we find the offending commit? It is probably sufficient >>>>>>>>>>>>to limit the >>>>>>>>>>>>>>>>>search to commits that touch something in drivers/char/tpm. >>>>>>>>>>>>>>>>I'll try and keep you posted. >>>>>>>>>>>>>>>OK I've been able to bisect the problem >>>>>>>>>>>>>>>and the bad commit is: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >>>>>>>>>>>>>>>is the first bad commit >>>>>>>>>>>>>>>commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >>>>>>>>>>>>>>>Author: Jerry Snitselaar <jsnitsel@redhat.com> >>>>>>>>>>>>>>>Date: Mon Mar 27 08:46:04 2017 -0700 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> tpm_tis: convert to using locality callbacks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This patch converts tpm_tis to use >>>>>>>>>>>>>>>of the new tpm class ops >>>>>>>>>>>>>>> request_locality, and relinquish_locality. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> With the move to using the >>>>>>>>>>>>>>>callbacks, release_locality is >>>>>>>>>>>>>>>changed so >>>>>>>>>>>>>>> that we now release the locality even if there is no >>>>>>>>>>>>>>>request pending. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This required some changes to the tpm_tis_core_init >>>>>>>>>>>>code path to >>>>>>>>>>>>>>> make sure locality is requested when needed: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - tpm2_probe code path will end up calling >>>>>>>>>>>>>>>request/release through >>>>>>>>>>>>>>> callbacks, so request_locality prior to >>>>>>>>>>>>tpm2_probe not needed. >>>>>>>>>>>>>>> - probe_itpm makes calls to >>>>>>>>>>>>>>>tpm_tis_send_data which no >>>>>>>>>>>>>>>longer calls >>>>>>>>>>>>>>> request_locality, so add request_locality prior to >>>>>>>>>>>>>>>tpm_tis_send_data >>>>>>>>>>>>>>> calls. Also drop release_locality call in middleof >>>>>>>>>>>>>>>probe_itpm, and >>>>>>>>>>>>>>> keep locality until >>>>>>>>>>>>>>>release_locality called at end of >>>>>>>>>>>>>>>probe_itpm. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cc: Peter Huewe <peterhuewe@gmx.de> >>>>>>>>>>>>>>> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>>> Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> >>>>>>>>>>>>>>> Cc: Marcel Selhorst <tpmdd@selhorst.net> >>>>>>>>>>>>>>> Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> >>>>>>>>>>>>>>> Reviewed-by: Jarkko Sakkinen >>>>>>>>>>>><jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>>> Tested-by: Jarkko Sakkinen >>>>>>>>>>>>>>><jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>>> Signed-off-by: Jarkko Sakkinen >>>>>>>>>>>><jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>>>:040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >>>>>>>>>>>>>>>72f21b446e45ea1003de75902b0553deb99157fd M drivers >>>>>>>>>>>>>>> >>>>>>>>>>>>>>I've looked again at the code in question, but could not find >>>>>>>>>>>>>>anything that is obviously wrong there. Locality is now >>>>>>>>>>>>>>requested/released at slightly different >>>>>>>>>>>>>>points in the process than >>>>>>>>>>>>>>before, but that's it. It does not seem to >>>>>>>>>>>>>>cause problems with the >>>>>>>>>>>>>>majority of TPMs, since you are the first to report any, so >>>>>>>>>>>>maybe it >>>>>>>>>>>>>>is a quirk that only affects this device. >>>>>>>>>>>>>> >>>>>>>>>>>>>>Perhaps Jerry can help, since this is his change? >>>>>>>>>>>>>> >>>>>>>>>>>>>>Alexander >>>>>>>>>>>>>Getting some caffeine in me, and starting to >>>>>>>>>>>>>take a look. Adding >>>>>>>>>>>>>Jarkko as well since this might involve the >>>>>>>>>>>>>general locality changes. >>>>>>>>>>>>> >>>>>>>>>>>>>Laurent, if I send you a patch with some >>>>>>>>>>>>>debugging code added, would >>>>>>>>>>>>>you be able to run it on that system? I wasn't >>>>>>>>>>>>>running into issues >>>>>>>>>>>>>on the system I had with a 1.2 device, but I >>>>>>>>>>>>>no longer have access >>>>>>>>>>>>>to it. I'll see if I can find one in our labs >>>>>>>>>>>>>and reproduce it there. >>>>>>>>>>>>Yes I should be able to do that >>>>>>>>>>>Any findings? >>>>>>>>>>> >>>>>>>>>>>/Jarkko >>>>>>>>>>Okay, finally getting back to this. Looking at the >>>>>>>>>>code it isn't clear >>>>>>>>>>to me >>>>>>>>>>why the change is causing this. So while I stare at this some more >>>>>>>>>>Laurent >>>>>>>>>>could you reproduce it with this patch so I can see >>>>>>>>>>what the status and >>>>>>>>>>access registers look like? Does anyone else on here >>>>>>>>>>happen to have a >>>>>>>>>>Sinosun >>>>>>>>>>tpm device? The systems I have access to with TPM1.2 >>>>>>>>>>devices don't have >>>>>>>>>>this >>>>>>>>>>issue. >>>>>>>>>> >>>>>>>>>>--8<-- >>>>>>>>>> >>>>>>>>>>diff --git a/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>>b/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>>index fdde971bc810..7d60a7e4b50a 100644 >>>>>>>>>>--- a/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>>+++ b/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>>@@ -258,6 +258,7 @@ static int >>>>>>>>>>tpm_tis_send_data(struct tpm_chip *chip, >>>>>>>>>>const u8 *buf, size_t len) >>>>>>>>>> int rc, status, burstcnt; >>>>>>>>>> size_t count = 0; >>>>>>>>>> bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; >>>>>>>>>>+ u8 access; >>>>>>>>>> >>>>>>>>>> status = tpm_tis_status(chip); >>>>>>>>>> if ((status & TPM_STS_COMMAND_READY) == 0) { >>>>>>>>>>@@ -292,6 +293,11 @@ static int >>>>>>>>>>tpm_tis_send_data(struct tpm_chip *chip, >>>>>>>>>>const u8 *buf, size_t len) >>>>>>>>>> } >>>>>>>>>> status = tpm_tis_status(chip); >>>>>>>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { >>>>>>>>>>+ rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), >>>>>>>>>>&access); >>>>>>>>>>+ if (rc < 0) >>>>>>>>>>+ dev_info(&chip->dev, >>>>>>>>>>"TPM_STS_DATA_EXPECT == 0: read >>>>>>>>>>failure TPM_ACCESS(%d)\n", priv->locality); >>>>>>>>>>+ else >>>>>>>>>>+ dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: >>>>>>>>>>locality: %d status: %x access: %x\n", >>>>>>>>>>priv->locality, status, access); >>>>>>>>>> rc = -EIO; >>>>>>>>>> goto out_err; >>>>>>>>>> } >>>>>>>>>>@@ -309,6 +315,11 @@ static int >>>>>>>>>>tpm_tis_send_data(struct tpm_chip *chip, >>>>>>>>>>const u8 *buf, size_t len) >>>>>>>>>> } >>>>>>>>>> status = tpm_tis_status(chip); >>>>>>>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { >>>>>>>>>>+ rc = tpm_tis_read8(priv, >>>>>>>>>>TPM_ACCESS(priv->locality), &access); >>>>>>>>>>+ if (rc < 0) >>>>>>>>>>+ dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read >>>>>>>>>>failure TPM_ACCESS(%d)\n", priv->locality); >>>>>>>>>>+ else >>>>>>>>>>+ dev_info(&chip->dev, >>>>>>>>>>"TPM_STS_DATA_EXPECT != 0: locality: >>>>>>>>>>%d status: %x access: %x\n", priv->locality, status, access); >>>>>>>>>> rc = -EIO; >>>>>>>>>> goto out_err; >>>>>>>>>> } >>>>>>>>>Please find here the dmesg output of the patched kernel >>>>>>>>At least 0xff is corrupted value in senseful way. CPU fills the read >>>>>>>>with ones for example for unaligned bus read. See table >>>>>>>>19 in PC client >>>>>>>>spec. This can happen when you do unaligned read for example. >>>>>>>> >>>>>>>>Maybe TPM is unreachable i.e. powered off. Bit busy with >>>>>>>>stuff ATM but >>>>>>>>would probably make sense to compare that 0x81 to table >>>>>>>>18 in the same >>>>>>>>spec. >>>>>>>> >>>>>>>>/Jarkko >>>>>>>0x81 is saying the access register status is valid, and the locality >>>>>>>is not active. That first bit means A Dynamic OS has not >>>>>>>been previously >>>>>>>established on the platform. Normally we would see 0xa1, which would >>>>>>>mean valid register status, and the locality is active. >>>>>>I think the important thing to note here is that STS has bits set that >>>>>>should never be set. So we can conclude that TPM might be either >>>>>> >>>>>>1. Powered off >>>>>>2. In some transition state? >>>>>> >>>>>>/Jarkko >>>>>If it was powered off would we be getting a valid read from the access >>>>>register? >>>>I think there is no universal answer to that :-) >>>> >>>>Maybe adding a extra delay would be next test to make? If for random >>>>reason it is in-between states... >>>Any more ideas? >>> >>>The chip is definitely in a weird state :/ I tried several ways to >>>reset the chip (windows, tpm-tools,...). >>> >>>I've been able to reset the chip via the bios (which now shows >>>unowned) but chip is still locked apparently. >>> >>>But still with < 4.12 I'm able to get /some/ information Public >>>EK, PCR,... out of the chip so it's not completely broken... >> >>OK correction the TPM is now unlocked (I let the computer running >>for more than 24h with nothing accessing the TPM) and with 4.9 I've >>been able to take the ownership again. >> >>Under 4.12 I still have the same errors as mentioned originally > >Hi Laurent, > >Would it be possible for you to run ftrace from boot with the following kernel parameters: > >ftrace=function_graph ftrace_filter=tpm* > actually 'ftrace=function_graph ftrace_filter=tpm*,*locality,wait_for_tpm_stat' would be better >and then send me the results of 'cat /sys/kernel/debug/tracing/trace' ? ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2017-11-10 7:07 ` Jerry Snitselaar @ 2017-11-10 8:21 ` Laurent Bigonville 2017-11-10 20:53 ` Jerry Snitselaar 0 siblings, 1 reply; 62+ messages in thread From: Laurent Bigonville @ 2017-11-10 8:21 UTC (permalink / raw) To: Jerry Snitselaar; +Cc: Jarkko Sakkinen, Alexander.Steffen, linux-integrity [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: multipart/mixed; boundary="------------D033D66A59EE10C39792CEF7", Size: 11188 bytes --] Le 10/11/17 a 08:07, Jerry Snitselaar a ecrit : > On Thu Nov 09 17, Jerry Snitselaar wrote: >> On Thu Nov 09 17, Laurent Bigonville wrote: >>> Le 09/11/17 a 01:04, Laurent Bigonville a ecrit : >>>> >>>> >>>> Le 24/10/17 a 18:07, Jarkko Sakkinen a ecrit : >>>>> On Tue, Oct 24, 2017 at 07:57:06AM -0700, Jerry Snitselaar wrote: >>>>>> On Tue Oct 24 17, Jarkko Sakkinen wrote: >>>>>>> On Mon, Oct 23, 2017 at 06:45:15AM -0700, Jerry Snitselaar wrote: >>>>>>>> On Mon Oct 23 17, Jarkko Sakkinen wrote: >>>>>>>>> On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville >>>>>>>>> wrote: >>>>>>>>>> Le 14/10/17 a 10:13, Jerry Snitselaar a ecrit : >>>>>>>>>>> On Wed Sep 06 17, Jarkko Sakkinen wrote: >>>>>>>>>>>> On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent >>>>>>>>>>>> Bigonville wrote: >>>>>>>>>>>>> Le 31/08/17 a 18:40, Jerry Snitselaar a ecrit : >>>>>>>>>>>>>> On Thu Aug 31 17, Alexander.Steffen@infineon.com wrote: >>>>>>>>>>>>>>>> Le 29/08/17 a 18:35, Laurent Bigonville a ecrit : >>>>>>>>>>>>>>>>> Le 29/08/17 a 18:00, Alexander.Steffen@infineon.com a >>>>>>>>>>>>>>>>> ecrit : >>>>>>>>>>>>>>>>>>> An idea how to troubleshoot this? >>>>>>>>>>>>>>>>>> Can you run git bisect on the changes between 4.11 and >>>>>>>>>>>>> 4.12, so that >>>>>>>>>>>>>>>>>> we find the offending commit? It is probably sufficient >>>>>>>>>>>>> to limit the >>>>>>>>>>>>>>>>>> search to commits that touch something in >>>>>>>>>>>>>>>>>> drivers/char/tpm. >>>>>>>>>>>>>>>>> I'll try and keep you posted. >>>>>>>>>>>>>>>> OK I've been able to bisect the problem and the bad >>>>>>>>>>>>>>>> commit is: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first >>>>>>>>>>>>>>>> bad commit >>>>>>>>>>>>>>>> commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >>>>>>>>>>>>>>>> Author: Jerry Snitselaar <jsnitsel@redhat.com> >>>>>>>>>>>>>>>> Date: Mon Mar 27 08:46:04 2017 -0700 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> tpm_tis: convert to using locality callbacks >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This patch converts tpm_tis to use of the new tpm >>>>>>>>>>>>>>>> class ops >>>>>>>>>>>>>>>> request_locality, and relinquish_locality. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> With the move to using the callbacks, >>>>>>>>>>>>>>>> release_locality is >>>>>>>>>>>>>>>> changed so >>>>>>>>>>>>>>>> that we now release the locality even if there is no >>>>>>>>>>>>>>>> request pending. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This required some changes to the tpm_tis_core_init >>>>>>>>>>>>> code path to >>>>>>>>>>>>>>>> make sure locality is requested when needed: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - tpm2_probe code path will end up calling >>>>>>>>>>>>>>>> request/release through >>>>>>>>>>>>>>>> callbacks, so request_locality prior to >>>>>>>>>>>>> tpm2_probe not needed. >>>>>>>>>>>>>>>> - probe_itpm makes calls to tpm_tis_send_data >>>>>>>>>>>>>>>> which no >>>>>>>>>>>>>>>> longer calls >>>>>>>>>>>>>>>> request_locality, so add request_locality >>>>>>>>>>>>>>>> prior to >>>>>>>>>>>>>>>> tpm_tis_send_data >>>>>>>>>>>>>>>> calls. Also drop release_locality call in >>>>>>>>>>>>>>>> middleof >>>>>>>>>>>>>>>> probe_itpm, and >>>>>>>>>>>>>>>> keep locality until release_locality called >>>>>>>>>>>>>>>> at end of >>>>>>>>>>>>>>>> probe_itpm. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Cc: Peter Huewe <peterhuewe@gmx.de> >>>>>>>>>>>>>>>> Cc: Jarkko Sakkinen >>>>>>>>>>>>>>>> <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>>>> Cc: Jason Gunthorpe >>>>>>>>>>>>>>>> <jgunthorpe@obsidianresearch.com> >>>>>>>>>>>>>>>> Cc: Marcel Selhorst <tpmdd@selhorst.net> >>>>>>>>>>>>>>>> Signed-off-by: Jerry Snitselaar >>>>>>>>>>>>>>>> <jsnitsel@redhat.com> >>>>>>>>>>>>>>>> Reviewed-by: Jarkko Sakkinen >>>>>>>>>>>>> <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>>>> Tested-by: Jarkko Sakkinen >>>>>>>>>>>>>>>> <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>>>> Signed-off-by: Jarkko Sakkinen >>>>>>>>>>>>> <jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>>>> :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >>>>>>>>>>>>>>>> 72f21b446e45ea1003de75902b0553deb99157fd M drivers >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've looked again at the code in question, but could not >>>>>>>>>>>>>>> find >>>>>>>>>>>>>>> anything that is obviously wrong there. Locality is now >>>>>>>>>>>>>>> requested/released at slightly different points in the >>>>>>>>>>>>>>> process than >>>>>>>>>>>>>>> before, but that's it. It does not seem to cause >>>>>>>>>>>>>>> problems with the >>>>>>>>>>>>>>> majority of TPMs, since you are the first to report any, so >>>>>>>>>>>>> maybe it >>>>>>>>>>>>>>> is a quirk that only affects this device. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Perhaps Jerry can help, since this is his change? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Alexander >>>>>>>>>>>>>> Getting some caffeine in me, and starting to take a look. >>>>>>>>>>>>>> Adding >>>>>>>>>>>>>> Jarkko as well since this might involve the general >>>>>>>>>>>>>> locality changes. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Laurent, if I send you a patch with some debugging code >>>>>>>>>>>>>> added, would >>>>>>>>>>>>>> you be able to run it on that system? I wasn't running >>>>>>>>>>>>>> into issues >>>>>>>>>>>>>> on the system I had with a 1.2 device, but I no longer >>>>>>>>>>>>>> have access >>>>>>>>>>>>>> to it. I'll see if I can find one in our labs and >>>>>>>>>>>>>> reproduce it there. >>>>>>>>>>>>> Yes I should be able to do that >>>>>>>>>>>> Any findings? >>>>>>>>>>>> >>>>>>>>>>>> /Jarkko >>>>>>>>>>> Okay, finally getting back to this. Looking at the code it >>>>>>>>>>> isn't clear >>>>>>>>>>> to me >>>>>>>>>>> why the change is causing this. So while I stare at this >>>>>>>>>>> some more >>>>>>>>>>> Laurent >>>>>>>>>>> could you reproduce it with this patch so I can see what the >>>>>>>>>>> status and >>>>>>>>>>> access registers look like? Does anyone else on here happen >>>>>>>>>>> to have a >>>>>>>>>>> Sinosun >>>>>>>>>>> tpm device? The systems I have access to with TPM1.2 devices >>>>>>>>>>> don't have >>>>>>>>>>> this >>>>>>>>>>> issue. >>>>>>>>>>> >>>>>>>>>>> --8<-- >>>>>>>>>>> >>>>>>>>>>> diff --git a/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>>> b/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>>> index fdde971bc810..7d60a7e4b50a 100644 >>>>>>>>>>> --- a/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>>> +++ b/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>>> @@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct >>>>>>>>>>> tpm_chip *chip, >>>>>>>>>>> const u8 *buf, size_t len) >>>>>>>>>>> int rc, status, burstcnt; >>>>>>>>>>> size_t count = 0; >>>>>>>>>>> bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; >>>>>>>>>>> + u8 access; >>>>>>>>>>> >>>>>>>>>>> status = tpm_tis_status(chip); >>>>>>>>>>> if ((status & TPM_STS_COMMAND_READY) == 0) { >>>>>>>>>>> @@ -292,6 +293,11 @@ static int tpm_tis_send_data(struct >>>>>>>>>>> tpm_chip *chip, >>>>>>>>>>> const u8 *buf, size_t len) >>>>>>>>>>> } >>>>>>>>>>> status = tpm_tis_status(chip); >>>>>>>>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { >>>>>>>>>>> + rc = tpm_tis_read8(priv, >>>>>>>>>>> TPM_ACCESS(priv->locality), >>>>>>>>>>> &access); >>>>>>>>>>> + if (rc < 0) >>>>>>>>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT >>>>>>>>>>> == 0: read >>>>>>>>>>> failure TPM_ACCESS(%d)\n", priv->locality); >>>>>>>>>>> + else >>>>>>>>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT >>>>>>>>>>> == 0: >>>>>>>>>>> locality: %d status: %x access: %x\n", priv->locality, >>>>>>>>>>> status, access); >>>>>>>>>>> rc = -EIO; >>>>>>>>>>> goto out_err; >>>>>>>>>>> } >>>>>>>>>>> @@ -309,6 +315,11 @@ static int tpm_tis_send_data(struct >>>>>>>>>>> tpm_chip *chip, >>>>>>>>>>> const u8 *buf, size_t len) >>>>>>>>>>> } >>>>>>>>>>> status = tpm_tis_status(chip); >>>>>>>>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { >>>>>>>>>>> + rc = tpm_tis_read8(priv, >>>>>>>>>>> TPM_ACCESS(priv->locality), &access); >>>>>>>>>>> + if (rc < 0) >>>>>>>>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: >>>>>>>>>>> read >>>>>>>>>>> failure TPM_ACCESS(%d)\n", priv->locality); >>>>>>>>>>> + else >>>>>>>>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: >>>>>>>>>>> locality: >>>>>>>>>>> %d status: %x access: %x\n", priv->locality, status, access); >>>>>>>>>>> rc = -EIO; >>>>>>>>>>> goto out_err; >>>>>>>>>>> } >>>>>>>>>> Please find here the dmesg output of the patched kernel >>>>>>>>> At least 0xff is corrupted value in senseful way. CPU fills >>>>>>>>> the read >>>>>>>>> with ones for example for unaligned bus read. See table 19 in >>>>>>>>> PC client >>>>>>>>> spec. This can happen when you do unaligned read for example. >>>>>>>>> >>>>>>>>> Maybe TPM is unreachable i.e. powered off. Bit busy with stuff >>>>>>>>> ATM but >>>>>>>>> would probably make sense to compare that 0x81 to table 18 in >>>>>>>>> the same >>>>>>>>> spec. >>>>>>>>> >>>>>>>>> /Jarkko >>>>>>>> 0x81 is saying the access register status is valid, and the >>>>>>>> locality >>>>>>>> is not active. That first bit means A Dynamic OS has not been >>>>>>>> previously >>>>>>>> established on the platform. Normally we would see 0xa1, which >>>>>>>> would >>>>>>>> mean valid register status, and the locality is active. >>>>>>> I think the important thing to note here is that STS has bits >>>>>>> set that >>>>>>> should never be set. So we can conclude that TPM might be either >>>>>>> >>>>>>> 1. Powered off >>>>>>> 2. In some transition state? >>>>>>> >>>>>>> /Jarkko >>>>>> If it was powered off would we be getting a valid read from the >>>>>> access >>>>>> register? >>>>> I think there is no universal answer to that :-) >>>>> >>>>> Maybe adding a extra delay would be next test to make? If for random >>>>> reason it is in-between states... >>>> Any more ideas? >>>> >>>> The chip is definitely in a weird state :/ I tried several ways to >>>> reset the chip (windows, tpm-tools,...). >>>> >>>> I've been able to reset the chip via the bios (which now shows >>>> unowned) but chip is still locked apparently. >>>> >>>> But still with < 4.12 I'm able to get /some/ information Public EK, >>>> PCR,... out of the chip so it's not completely broken... >>> >>> OK correction the TPM is now unlocked (I let the computer running >>> for more than 24h with nothing accessing the TPM) and with 4.9 I've >>> been able to take the ownership again. >>> >>> Under 4.12 I still have the same errors as mentioned originally >> >> Hi Laurent, >> >> Would it be possible for you to run ftrace from boot with the >> following kernel parameters: >> >> ftrace=function_graph ftrace_filter=tpm* >> > > actually 'ftrace=function_graph > ftrace_filter=tpm*,*locality,wait_for_tpm_stat' would be better > >> and then send me the results of 'cat /sys/kernel/debug/tracing/trace' ? Here you are. [ Part 2, Text/PLAIN (Name: "trace.txt") ~8 KB. ] [ Unable to print this part. ] ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2017-11-10 8:21 ` Laurent Bigonville @ 2017-11-10 20:53 ` Jerry Snitselaar 2017-11-11 15:45 ` Jason Gunthorpe 2017-11-14 14:43 ` Jarkko Sakkinen 0 siblings, 2 replies; 62+ messages in thread From: Jerry Snitselaar @ 2017-11-10 20:53 UTC (permalink / raw) To: Laurent Bigonville; +Cc: Jarkko Sakkinen, Alexander.Steffen, linux-integrity On Fri Nov 10 17, Laurent Bigonville wrote: >Le 10/11/17 a 08:07, Jerry Snitselaar a ecrit : >>On Thu Nov 09 17, Jerry Snitselaar wrote: >>>On Thu Nov 09 17, Laurent Bigonville wrote: >>>>Le 09/11/17 a 01:04, Laurent Bigonville a ecrit : >>>>> >>>>> >>>>>Le 24/10/17 a 18:07, Jarkko Sakkinen a ecrit : >>>>>>On Tue, Oct 24, 2017 at 07:57:06AM -0700, Jerry Snitselaar wrote: >>>>>>>On Tue Oct 24 17, Jarkko Sakkinen wrote: >>>>>>>>On Mon, Oct 23, 2017 at 06:45:15AM -0700, Jerry Snitselaar wrote: >>>>>>>>>On Mon Oct 23 17, Jarkko Sakkinen wrote: >>>>>>>>>>On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent >>>>>>>>>>Bigonville wrote: >>>>>>>>>>>Le 14/10/17 a 10:13, Jerry Snitselaar a ecrit : >>>>>>>>>>>>On Wed Sep 06 17, Jarkko Sakkinen wrote: >>>>>>>>>>>>>On Fri, Sep 01, 2017 at 02:10:18PM +0200, >>>>>>>>>>>>>Laurent Bigonville wrote: >>>>>>>>>>>>>>Le 31/08/17 a 18:40, Jerry Snitselaar a ecrit : >>>>>>>>>>>>>>>On Thu Aug 31 17, Alexander.Steffen@infineon.com wrote: >>>>>>>>>>>>>>>>>Le 29/08/17 a 18:35, Laurent Bigonville a ecrit : >>>>>>>>>>>>>>>>>>Le 29/08/17 a 18:00, >>>>>>>>>>>>>>>>>>Alexander.Steffen@infineon.com a >>>>>>>>>>>>>>>>>>ecrit : >>>>>>>>>>>>>>>>>>>>An idea how to troubleshoot this? >>>>>>>>>>>>>>>>>>>Can you run git bisect on the changes between 4.11 and >>>>>>>>>>>>>>4.12, so that >>>>>>>>>>>>>>>>>>>we find the offending commit? It is probably sufficient >>>>>>>>>>>>>>to limit the >>>>>>>>>>>>>>>>>>>search to commits that touch >>>>>>>>>>>>>>>>>>>something in drivers/char/tpm. >>>>>>>>>>>>>>>>>>I'll try and keep you posted. >>>>>>>>>>>>>>>>>OK I've been able to bisect the >>>>>>>>>>>>>>>>>problem and the bad commit is: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >>>>>>>>>>>>>>>>>is the first bad commit >>>>>>>>>>>>>>>>>commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >>>>>>>>>>>>>>>>>Author: Jerry Snitselaar <jsnitsel@redhat.com> >>>>>>>>>>>>>>>>>Date: Mon Mar 27 08:46:04 2017 -0700 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> tpm_tis: convert to using locality callbacks >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This patch converts tpm_tis to >>>>>>>>>>>>>>>>>use of the new tpm class ops >>>>>>>>>>>>>>>>> request_locality, and relinquish_locality. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> With the move to using the >>>>>>>>>>>>>>>>>callbacks, release_locality is >>>>>>>>>>>>>>>>>changed so >>>>>>>>>>>>>>>>> that we now release the locality even if there is no >>>>>>>>>>>>>>>>>request pending. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This required some changes to the tpm_tis_core_init >>>>>>>>>>>>>>code path to >>>>>>>>>>>>>>>>> make sure locality is requested when needed: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - tpm2_probe code path will end up calling >>>>>>>>>>>>>>>>>request/release through >>>>>>>>>>>>>>>>> callbacks, so request_locality prior to >>>>>>>>>>>>>>tpm2_probe not needed. >>>>>>>>>>>>>>>>> - probe_itpm makes calls to >>>>>>>>>>>>>>>>>tpm_tis_send_data which no >>>>>>>>>>>>>>>>>longer calls >>>>>>>>>>>>>>>>> request_locality, so add >>>>>>>>>>>>>>>>>request_locality prior to >>>>>>>>>>>>>>>>>tpm_tis_send_data >>>>>>>>>>>>>>>>> calls. Also drop >>>>>>>>>>>>>>>>>release_locality call in middleof >>>>>>>>>>>>>>>>>probe_itpm, and >>>>>>>>>>>>>>>>> keep locality until >>>>>>>>>>>>>>>>>release_locality called at end of >>>>>>>>>>>>>>>>>probe_itpm. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Cc: Peter Huewe <peterhuewe@gmx.de> >>>>>>>>>>>>>>>>> Cc: Jarkko Sakkinen >>>>>>>>>>>>>>>>><jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>>>>> Cc: Jason Gunthorpe >>>>>>>>>>>>>>>>><jgunthorpe@obsidianresearch.com> >>>>>>>>>>>>>>>>> Cc: Marcel Selhorst <tpmdd@selhorst.net> >>>>>>>>>>>>>>>>> Signed-off-by: Jerry Snitselaar >>>>>>>>>>>>>>>>><jsnitsel@redhat.com> >>>>>>>>>>>>>>>>> Reviewed-by: Jarkko Sakkinen >>>>>>>>>>>>>><jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>>>>>Tested-by: Jarkko Sakkinen >>>>>>>>>>>>>>>>><jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>>>>> Signed-off-by: Jarkko Sakkinen >>>>>>>>>>>>>><jarkko.sakkinen@linux.intel.com> >>>>>>>>>>>>>>>>>:040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >>>>>>>>>>>>>>>>>72f21b446e45ea1003de75902b0553deb99157fd M drivers >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>I've looked again at the code in >>>>>>>>>>>>>>>>question, but could not find >>>>>>>>>>>>>>>>anything that is obviously wrong there. Locality is now >>>>>>>>>>>>>>>>requested/released at slightly different >>>>>>>>>>>>>>>>points in the process than >>>>>>>>>>>>>>>>before, but that's it. It does not seem >>>>>>>>>>>>>>>>to cause problems with the >>>>>>>>>>>>>>>>majority of TPMs, since you are the first to report any, so >>>>>>>>>>>>>>maybe it >>>>>>>>>>>>>>>>is a quirk that only affects this device. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>Perhaps Jerry can help, since this is his change? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>Alexander >>>>>>>>>>>>>>>Getting some caffeine in me, and starting >>>>>>>>>>>>>>>to take a look. Adding >>>>>>>>>>>>>>>Jarkko as well since this might involve >>>>>>>>>>>>>>>the general locality changes. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>Laurent, if I send you a patch with some >>>>>>>>>>>>>>>debugging code added, would >>>>>>>>>>>>>>>you be able to run it on that system? I >>>>>>>>>>>>>>>wasn't running into issues >>>>>>>>>>>>>>>on the system I had with a 1.2 device, but >>>>>>>>>>>>>>>I no longer have access >>>>>>>>>>>>>>>to it. I'll see if I can find one in our >>>>>>>>>>>>>>>labs and reproduce it there. >>>>>>>>>>>>>>Yes I should be able to do that >>>>>>>>>>>>>Any findings? >>>>>>>>>>>>> >>>>>>>>>>>>>/Jarkko >>>>>>>>>>>>Okay, finally getting back to this. Looking at >>>>>>>>>>>>the code it isn't clear >>>>>>>>>>>>to me >>>>>>>>>>>>why the change is causing this. So while I stare >>>>>>>>>>>>at this some more >>>>>>>>>>>>Laurent >>>>>>>>>>>>could you reproduce it with this patch so I can >>>>>>>>>>>>see what the status and >>>>>>>>>>>>access registers look like? Does anyone else on >>>>>>>>>>>>here happen to have a >>>>>>>>>>>>Sinosun >>>>>>>>>>>>tpm device? The systems I have access to with >>>>>>>>>>>>TPM1.2 devices don't have >>>>>>>>>>>>this >>>>>>>>>>>>issue. >>>>>>>>>>>> >>>>>>>>>>>>--8<-- >>>>>>>>>>>> >>>>>>>>>>>>diff --git a/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>>>>b/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>>>>index fdde971bc810..7d60a7e4b50a 100644 >>>>>>>>>>>>--- a/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>>>>+++ b/drivers/char/tpm/tpm_tis_core.c >>>>>>>>>>>>@@ -258,6 +258,7 @@ static int >>>>>>>>>>>>tpm_tis_send_data(struct tpm_chip *chip, >>>>>>>>>>>>const u8 *buf, size_t len) >>>>>>>>>>>> int rc, status, burstcnt; >>>>>>>>>>>> size_t count = 0; >>>>>>>>>>>> bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; >>>>>>>>>>>>+ u8 access; >>>>>>>>>>>> >>>>>>>>>>>> status = tpm_tis_status(chip); >>>>>>>>>>>> if ((status & TPM_STS_COMMAND_READY) == 0) { >>>>>>>>>>>>@@ -292,6 +293,11 @@ static int >>>>>>>>>>>>tpm_tis_send_data(struct tpm_chip *chip, >>>>>>>>>>>>const u8 *buf, size_t len) >>>>>>>>>>>> } >>>>>>>>>>>> status = tpm_tis_status(chip); >>>>>>>>>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { >>>>>>>>>>>>+ rc = tpm_tis_read8(priv, >>>>>>>>>>>>TPM_ACCESS(priv->locality), >>>>>>>>>>>>&access); >>>>>>>>>>>>+ if (rc < 0) >>>>>>>>>>>>+ dev_info(&chip->dev, >>>>>>>>>>>>"TPM_STS_DATA_EXPECT == 0: read >>>>>>>>>>>>failure TPM_ACCESS(%d)\n", priv->locality); >>>>>>>>>>>>+ else >>>>>>>>>>>>+ dev_info(&chip->dev, >>>>>>>>>>>>"TPM_STS_DATA_EXPECT == 0: >>>>>>>>>>>>locality: %d status: %x access: %x\n", >>>>>>>>>>>>priv->locality, status, access); >>>>>>>>>>>> rc = -EIO; >>>>>>>>>>>> goto out_err; >>>>>>>>>>>> } >>>>>>>>>>>>@@ -309,6 +315,11 @@ static int >>>>>>>>>>>>tpm_tis_send_data(struct tpm_chip *chip, >>>>>>>>>>>>const u8 *buf, size_t len) >>>>>>>>>>>> } >>>>>>>>>>>> status = tpm_tis_status(chip); >>>>>>>>>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { >>>>>>>>>>>>+ rc = tpm_tis_read8(priv, >>>>>>>>>>>>TPM_ACCESS(priv->locality), &access); >>>>>>>>>>>>+ if (rc < 0) >>>>>>>>>>>>+ dev_info(&chip->dev, >>>>>>>>>>>>"TPM_STS_DATA_EXPECT != 0: read >>>>>>>>>>>>failure TPM_ACCESS(%d)\n", priv->locality); >>>>>>>>>>>>+ else >>>>>>>>>>>>+ dev_info(&chip->dev, >>>>>>>>>>>>"TPM_STS_DATA_EXPECT != 0: locality: >>>>>>>>>>>>%d status: %x access: %x\n", priv->locality, status, access); >>>>>>>>>>>> rc = -EIO; >>>>>>>>>>>> goto out_err; >>>>>>>>>>>> } >>>>>>>>>>>Please find here the dmesg output of the patched kernel >>>>>>>>>>At least 0xff is corrupted value in senseful way. >>>>>>>>>>CPU fills the read >>>>>>>>>>with ones for example for unaligned bus read. See >>>>>>>>>>table 19 in PC client >>>>>>>>>>spec. This can happen when you do unaligned read for example. >>>>>>>>>> >>>>>>>>>>Maybe TPM is unreachable i.e. powered off. Bit busy >>>>>>>>>>with stuff ATM but >>>>>>>>>>would probably make sense to compare that 0x81 to >>>>>>>>>>table 18 in the same >>>>>>>>>>spec. >>>>>>>>>> >>>>>>>>>>/Jarkko >>>>>>>>>0x81 is saying the access register status is valid, >>>>>>>>>and the locality >>>>>>>>>is not active. That first bit means A Dynamic OS has >>>>>>>>>not been previously >>>>>>>>>established on the platform. Normally we would see >>>>>>>>>0xa1, which would >>>>>>>>>mean valid register status, and the locality is active. >>>>>>>>I think the important thing to note here is that STS has >>>>>>>>bits set that >>>>>>>>should never be set. So we can conclude that TPM might be either >>>>>>>> >>>>>>>>1. Powered off >>>>>>>>2. In some transition state? >>>>>>>> >>>>>>>>/Jarkko >>>>>>>If it was powered off would we be getting a valid read >>>>>>>from the access >>>>>>>register? >>>>>>I think there is no universal answer to that :-) >>>>>> >>>>>>Maybe adding a extra delay would be next test to make? If for random >>>>>>reason it is in-between states... >>>>>Any more ideas? >>>>> >>>>>The chip is definitely in a weird state :/ I tried several >>>>>ways to reset the chip (windows, tpm-tools,...). >>>>> >>>>>I've been able to reset the chip via the bios (which now shows >>>>>unowned) but chip is still locked apparently. >>>>> >>>>>But still with < 4.12 I'm able to get /some/ information >>>>>Public EK, PCR,... out of the chip so it's not completely >>>>>broken... >>>> >>>>OK correction the TPM is now unlocked (I let the computer >>>>running for more than 24h with nothing accessing the TPM) and >>>>with 4.9 I've been able to take the ownership again. >>>> >>>>Under 4.12 I still have the same errors as mentioned originally >>> >>>Hi Laurent, >>> >>>Would it be possible for you to run ftrace from boot with the >>>following kernel parameters: >>> >>>ftrace=function_graph ftrace_filter=tpm* >>> >> >>actually 'ftrace=function_graph >>ftrace_filter=tpm*,*locality,wait_for_tpm_stat' would be better >> >>>and then send me the results of 'cat /sys/kernel/debug/tracing/trace' ? >Here you are. Thank you Laurent. A few interesting things here: ># tracer: function_graph ># ># CPU DURATION FUNCTION CALLS ># | | | | | | | > 1) 4.510 us | tpm_init(); > 1) | tpm_tis_pnp_init() { > 1) | tpm_tis_init.part.3() { > 1) | tpm_tis_core_init() { > 1) | tpmm_chip_alloc() { > 1) 3.935 us | tpm_chip_alloc(); > 1) 4.787 us | } > 1) 0.199 us | tpm_tcg_read_bytes(); > 1) 0.217 us | tpm_tcg_read32(); > 1) 0.117 us | tpm_tcg_write32(); > 1) | tpm2_probe() { > 1) | tpm_transmit_cmd() { > 1) | tpm_transmit() { > 1) | request_locality() { > 1) | check_locality() { > 1) 0.045 us | tpm_tcg_read_bytes(); > 1) 1.708 us | } > 1) 2.077 us | } So it goes request locality, does check to see if the locality is already active and it is, so doesn't go through the process of requesting the locality. > 1) 0.168 us | tpm2_prepare_space(); > 1) | tpm_tis_send() { > 1) | tpm_tis_send_main() { > 1) | tpm_tis_send_data() { > 1) 0.045 us | tpm_tcg_read_bytes(); > 1) 0.044 us | tpm_tcg_read32(); > 1) 1.723 us | tpm_tcg_write_bytes(); > 1) | wait_for_tpm_stat() { > 1) | tpm_tis_status() { > 1) 0.042 us | tpm_tcg_read_bytes(); > 1) 5.163 us | } > 1) | tpm_tis_status() { > 1) 0.167 us | tpm_tcg_read_bytes(); > 1) 2.182 us | } > 1) | tpm_tis_status() { > 1) 0.194 us | tpm_tcg_read_bytes(); > 1) 2.452 us | } > 1) * 30406.24 us | } > 1) 0.088 us | tpm_tcg_read_bytes(); > 1) 0.123 us | tpm_tcg_write_bytes(); > 1) | wait_for_tpm_stat() { > 1) | tpm_tis_status() { > 1) 0.084 us | tpm_tcg_read_bytes(); > 1) 1.940 us | } > 1) | tpm_tis_status() { > 1) 0.170 us | tpm_tcg_read_bytes(); > 1) 2.217 us | } > 1) * 16000.74 us | } > 1) 0.084 us | tpm_tcg_read_bytes(); > 1) * 46425.66 us | } > 1) 0.115 us | tpm_tcg_write_bytes(); > 1) * 46426.85 us | } > 1) * 46427.35 us | } > 1) | tpm_tis_status() { > 1) 1.389 us | tpm_tcg_read_bytes(); > 1) 1.909 us | } > 1) 0.095 us | tpm_tis_req_canceled(); > 1) | tpm_tis_status() { > 1) 0.187 us | tpm_tcg_read_bytes(); > 1) 2.110 us | } > 1) | tpm_tis_recv() { > 1) | wait_for_tpm_stat() { > 1) | tpm_tis_status() { > 1) 0.082 us | tpm_tcg_read_bytes(); > 1) 1.898 us | } > 1) 2.425 us | } > 1) 0.102 us | tpm_tcg_read32(); > 1) 5.453 us | tpm_tcg_read_bytes(); > 1) | wait_for_tpm_stat() { > 1) | tpm_tis_status() { > 1) 0.092 us | tpm_tcg_read_bytes(); > 1) 1.858 us | } > 1) 2.332 us | } > 1) 0.077 us | tpm_tcg_read_bytes(); > 1) 0.112 us | tpm_tcg_write_bytes(); > 1) + 25.466 us | } > 1) 0.152 us | tpm2_commit_space(); > 1) | release_locality() { > 1) 0.080 us | tpm_tcg_write_bytes(); > 1) 0.672 us | } Releases the locality as it comes back out of tpm_transmit_cmd > 1) * 62349.91 us | } > 1) * 62350.38 us | } > 1) * 62350.87 us | } > 1) 0.070 us | tpm_tcg_read32(); > 1) 0.073 us | tpm_tcg_read_bytes(); > 1) 0.096 us | tpm_tcg_read16(); > 1) 0.042 us | tpm_tcg_read32(); > 1) | tpm_chip_register() { > 1) | tpm1_auto_startup() { > 1) | tpm_get_timeouts() { > 1) | tpm_get_timeouts.part.6() { > 1) | tpm_getcap() { > 1) | tpm_transmit_cmd() { > 1) | tpm_transmit() { > 1) | request_locality() { > 1) | check_locality() { > 1) 0.091 us | tpm_tcg_read_bytes(); > 1) 1.680 us | } > 1) 1.973 us | } Goes to request the locality again, but once again the check sees that the locality is already active, so doesn't go through process of requesting the locality. Very odd. > 1) 0.072 us | tpm2_prepare_space(); > 1) | tpm_tis_send() { > 1) | tpm_tis_send_main() { > 1) | tpm_tis_send_data() { > 1) 0.043 us | tpm_tcg_read_bytes(); tpm_tis_stat inlined? > 1) 0.071 us | tpm_tcg_write_bytes(); tpm_tis_ready inlined? > 1) | wait_for_tpm_stat() { > 1) | tpm_tis_status() { > 1) 0.042 us | tpm_tcg_read_bytes(); > 1) 1.634 us | } > 1) | tpm_tis_status() { > 1) 0.183 us | tpm_tcg_read_bytes(); > 1) 2.121 us | } > 1) * 15942.66 us | } The wait_for_tpm_stat does its loop twice checking the status register so at this point apparently it isn't reading 0xff. > 1) 0.108 us | tpm_tcg_read32(); This read is get_burstcount. > 1) 1.773 us | tpm_tcg_write_bytes(); > 1) | wait_for_tpm_stat() { > 1) | tpm_tis_status() { > 1) 0.082 us | tpm_tcg_read_bytes(); > 1) 5.011 us | } > 1) 5.618 us | } > 1) 0.077 us | tpm_tcg_read_bytes(); tpm_tis_status inlined? > 1) 0.090 us | tpm_tcg_write_bytes(); Come out of loop and write last byte > 1) | wait_for_tpm_stat() { > 1) | tpm_tis_status() { > 1) 0.080 us | tpm_tcg_read_bytes(); > 1) 1.921 us | } > 1) 2.376 us | } > 1) 0.077 us | tpm_tcg_read_bytes(); inlined tpm_tis_status again? Here is where it sees data is still expected and errors out. With that debugging patch at this point it was showing that the locality was not active. Also didn't show that the tpm had been seized by another locality. > 1) 0.080 us | tpm_tcg_write_bytes(); tpm_tis_ready inlined? in out_err > 1) * 15970.97 us | } > 1) * 15971.39 us | } > 1) * 15971.81 us | } > 1) | release_locality() { > 1) 0.103 us | tpm_tcg_write_bytes(); > 1) 0.535 us | } > 1) * 16023.04 us | } > 1) * 16023.35 us | } > 1) * 16024.79 us | } > 1) * 16067.18 us | } > 1) * 16067.67 us | } > 1) * 16068.10 us | } > 1) * 16068.47 us | } > 1) * 78448.69 us | } > 1) * 78455.45 us | } > 1) * 78456.71 us | } > 1) 0.564 us | tpm_dev_release(); > 0) | tpm_pcr_read() { > 0) 0.225 us | tpm_chip_find_get(); > 0) 0.734 us | } I wonder if it is possible that the release locality from the probe isn't completing on the chip until after the request/check that happens at the beginning of the tpm_get_timeouts. Perhaps we need something like wait_for_tpm_stat for the access register, and verifying that locality was released before returning out of release_locality? Any thoughts? ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2017-11-10 20:53 ` Jerry Snitselaar @ 2017-11-11 15:45 ` Jason Gunthorpe 2017-11-11 19:12 ` Jerry Snitselaar 2017-11-14 14:43 ` Jarkko Sakkinen 1 sibling, 1 reply; 62+ messages in thread From: Jason Gunthorpe @ 2017-11-11 15:45 UTC (permalink / raw) To: Jerry Snitselaar Cc: Laurent Bigonville, Jarkko Sakkinen, Alexander.Steffen, linux-integrity On Fri, Nov 10, 2017 at 01:53:00PM -0700, Jerry Snitselaar wrote: > I wonder if it is possible that the release locality from the probe > isn't completing on the chip until after the request/check that > happens at the beginning of the tpm_get_timeouts. Perhaps we need > something like wait_for_tpm_stat for the access register, and > verifying that locality was released before returning out of > release_locality? This is not a bad guess.. Adding a largish delay after release_locality might be interesting too. Are we sure our tis request/release process is even right? Another options is that the 'check if already in locality' doesn't work on this chip, or isn't coded right... Jason ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2017-11-11 15:45 ` Jason Gunthorpe @ 2017-11-11 19:12 ` Jerry Snitselaar 2017-11-11 19:46 ` Jason Gunthorpe 0 siblings, 1 reply; 62+ messages in thread From: Jerry Snitselaar @ 2017-11-11 19:12 UTC (permalink / raw) To: Jason Gunthorpe Cc: Laurent Bigonville, Jarkko Sakkinen, Alexander.Steffen, linux-integrity On Sat Nov 11 17, Jason Gunthorpe wrote: >On Fri, Nov 10, 2017 at 01:53:00PM -0700, Jerry Snitselaar wrote: > >> I wonder if it is possible that the release locality from the probe >> isn't completing on the chip until after the request/check that >> happens at the beginning of the tpm_get_timeouts. Perhaps we need >> something like wait_for_tpm_stat for the access register, and >> verifying that locality was released before returning out of >> release_locality? > >This is not a bad guess.. Adding a largish delay after >release_locality might be interesting too. > >Are we sure our tis request/release process is even right? Another At this point, no? :) The tpm1.2 and tpm2.0 tis devices I have access to seem to behave properly, and the traces look like I'd expect, but that doesn't prove anything. I think the check_locality code is okay since it is looking at the access register for the desired locality and seeing if the active locality and valid register bits are set. According to the fifo interface locality usage per register chart, the access register should always return correct values unlike the status register. For request_locality, currently it sets the request use bit in the access register, and then does check_locality potentially up until timeout a. Looking at the spec, it could take longer than timeout a if there is another active locality. It can take up until timeout a from the point where that locality relinquishes the tpm. So that could possibly be improved. Before the release_locality code would only actually release the locality if the request use bit was set. So after it grabbed the locality during probe it probably never released it. The idea with the new code was to release it when it was no longer needed so another requester would be able to take the tpm without having to wait for it to be released. With the old code I think it would have to wait either until the next time release_locality was called, or attempt to seize the tpm with the seize bit in the access register. I need to read through the spec some more, but does the tpm ever force a change when the request use bit is set, or does it leave it up to the software to deal with it and only gets involved in the case where the seize bit has been set? /me goes back to reading specs >options is that the 'check if already in locality' doesn't work on >this chip, or isn't coded right... > >Jason ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2017-11-11 19:12 ` Jerry Snitselaar @ 2017-11-11 19:46 ` Jason Gunthorpe 2017-11-11 20:31 ` Jerry Snitselaar 2017-11-14 14:55 ` Jarkko Sakkinen 0 siblings, 2 replies; 62+ messages in thread From: Jason Gunthorpe @ 2017-11-11 19:46 UTC (permalink / raw) To: Jerry Snitselaar Cc: Laurent Bigonville, Jarkko Sakkinen, Alexander.Steffen, linux-integrity On Sat, Nov 11, 2017 at 12:12:57PM -0700, Jerry Snitselaar wrote: > Before the release_locality code would only actually release the > locality if the request use bit was set. So after it grabbed the > locality during probe it probably never released it. The idea with the > new code was to release it when it was no longer needed so another > requester would be able to take the tpm without having to wait for it > to be released. If I recall, this was so that system level things outside linux could access the TPM properly?? > With the old code I think it would have to wait either > until the next time release_locality was called, or attempt to seize > the tpm with the seize bit in the access register. I need to read > through the spec some more, but does the tpm ever force a change when > the request use bit is set, or does it leave it up to the software > to deal with it and only gets involved in the case where the seize > bit has been set? Do we handle these cases? Maybe something like that has happened.. Jason ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2017-11-11 19:46 ` Jason Gunthorpe @ 2017-11-11 20:31 ` Jerry Snitselaar 2017-11-14 0:26 ` Laurent Bigonville 2017-11-14 14:59 ` Jarkko Sakkinen 2017-11-14 14:55 ` Jarkko Sakkinen 1 sibling, 2 replies; 62+ messages in thread From: Jerry Snitselaar @ 2017-11-11 20:31 UTC (permalink / raw) To: Jason Gunthorpe Cc: Laurent Bigonville, Jarkko Sakkinen, Alexander.Steffen, linux-integrity On Sat Nov 11 17, Jason Gunthorpe wrote: >On Sat, Nov 11, 2017 at 12:12:57PM -0700, Jerry Snitselaar wrote: > >> Before the release_locality code would only actually release the >> locality if the request use bit was set. So after it grabbed the >> locality during probe it probably never released it. The idea with the >> new code was to release it when it was no longer needed so another >> requester would be able to take the tpm without having to wait for it >> to be released. > >If I recall, this was so that system level things outside linux could >access the TPM properly?? > Yes, that is what drove this initially. I believe Jarkko was also thinking of the possibility in the future where something like a vm could request a locality as well, but that is just a hazy recollection of emails from back then. >> With the old code I think it would have to wait either >> until the next time release_locality was called, or attempt to seize >> the tpm with the seize bit in the access register. I need to read >> through the spec some more, but does the tpm ever force a change when >> the request use bit is set, or does it leave it up to the software >> to deal with it and only gets involved in the case where the seize >> bit has been set? > >Do we handle these cases? Maybe something like that has happened.. > >Jason If that is what happened in this case we should see the beenSeized bit set in the access register (assuming the chip is doing things properly), but it only had the tpmRegValidSts and tpmEstablishment bits set. There is code in the interrupt handling that notices if the locality changes if the chip has that capability, but I don't think there is anything that deals with the seize bit. Another thing to be looked at. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2017-11-11 20:31 ` Jerry Snitselaar @ 2017-11-14 0:26 ` Laurent Bigonville 2017-11-14 2:45 ` Jason Gunthorpe 2017-11-14 14:59 ` Jarkko Sakkinen 1 sibling, 1 reply; 62+ messages in thread From: Laurent Bigonville @ 2017-11-14 0:26 UTC (permalink / raw) To: Jerry Snitselaar, Jason Gunthorpe Cc: Jarkko Sakkinen, Alexander.Steffen, linux-integrity Le 11/11/17 a 21:31, Jerry Snitselaar a ecrit : > On Sat Nov 11 17, Jason Gunthorpe wrote: >> On Sat, Nov 11, 2017 at 12:12:57PM -0700, Jerry Snitselaar wrote: >> >>> Before the release_locality code would only actually release the >>> locality if the request use bit was set. So after it grabbed the >>> locality during probe it probably never released it. The idea with the >>> new code was to release it when it was no longer needed so another >>> requester would be able to take the tpm without having to wait for it >>> to be released. >> >> If I recall, this was so that system level things outside linux could >> access the TPM properly?? >> > > Yes, that is what drove this initially. I believe Jarkko was also > thinking of the possibility in the future where something like a vm > could request a locality as well, but that is just a hazy recollection > of emails from back then. > >>> With the old code I think it would have to wait either >>> until the next time release_locality was called, or attempt to seize >>> the tpm with the seize bit in the access register. I need to read >>> through the spec some more, but does the tpm ever force a change when >>> the request use bit is set, or does it leave it up to the software >>> to deal with it and only gets involved in the case where the seize >>> bit has been set? >> >> Do we handle these cases? Maybe something like that has happened.. >> >> Jason > > If that is what happened in this case we should see the beenSeized bit > set in the access register (assuming the chip is doing things properly), > but it only had the tpmRegValidSts and tpmEstablishment bits set. > > There is code in the interrupt handling that notices if the locality > changes if the chip has that capability, but I don't think there is > anything that deals with the seize bit. Another thing to be looked > at. I don't know if it's relevant, I was looking at the different tpm_* tools and tpm_nvinfo is giving me errors with 4.9: $ sudo tpm_nvinfo -l debug Tspi_Context_Create success Tspi_Context_Connect success Tspi_Context_GetTpmObject success Tspi_TPM_GetCapability success NVRAM index : 0x00000000 (0) Tspi_TPM_GetCapability failed: 0x00000002 - layer=tpm, code=0002 (2), Bad memory index NVRAM index : 0x10000001 (268435457) Tspi_TPM_GetCapability failed: 0x00000002 - layer=tpm, code=0002 (2), Bad memory index NVRAM index : 0xffffffff (4294967295) Tspi_TPM_GetCapability failed: 0x00000002 - layer=tpm, code=0002 (2), Bad memory index Tspi_Context_FreeMemory success Tspi_Context_Close success ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2017-11-14 0:26 ` Laurent Bigonville @ 2017-11-14 2:45 ` Jason Gunthorpe 0 siblings, 0 replies; 62+ messages in thread From: Jason Gunthorpe @ 2017-11-14 2:45 UTC (permalink / raw) To: Laurent Bigonville Cc: Jerry Snitselaar, Jarkko Sakkinen, Alexander.Steffen, linux-integrity On Tue, Nov 14, 2017 at 01:26:16AM +0100, Laurent Bigonville wrote: > I don't know if it's relevant, I was looking at the different tpm_* tools > and tpm_nvinfo is giving me errors with 4.9: This looks like good communication with the chip to me, just the chip refusing to run the command for whatever reason? Jason ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2017-11-11 20:31 ` Jerry Snitselaar 2017-11-14 0:26 ` Laurent Bigonville @ 2017-11-14 14:59 ` Jarkko Sakkinen 2017-11-14 15:17 ` James Bottomley 1 sibling, 1 reply; 62+ messages in thread From: Jarkko Sakkinen @ 2017-11-14 14:59 UTC (permalink / raw) To: Jerry Snitselaar Cc: Jason Gunthorpe, Laurent Bigonville, Alexander.Steffen, linux-integrity On Sat, Nov 11, 2017 at 01:31:32PM -0700, Jerry Snitselaar wrote: > On Sat Nov 11 17, Jason Gunthorpe wrote: > > On Sat, Nov 11, 2017 at 12:12:57PM -0700, Jerry Snitselaar wrote: > > > > > Before the release_locality code would only actually release the > > > locality if the request use bit was set. So after it grabbed the > > > locality during probe it probably never released it. The idea with the > > > new code was to release it when it was no longer needed so another > > > requester would be able to take the tpm without having to wait for it > > > to be released. > > > > If I recall, this was so that system level things outside linux could > > access the TPM properly?? > > > > Yes, that is what drove this initially. I believe Jarkko was also > thinking of the possibility in the future where something like a vm > could request a locality as well, but that is just a hazy recollection > of emails from back then. This was something I recall discussing in LPC 2016 in the hallway at least :-) A tidbit but it could make sense to tie it to VMM, not VM. > > > > With the old code I think it would have to wait either > > > until the next time release_locality was called, or attempt to seize > > > the tpm with the seize bit in the access register. I need to read > > > through the spec some more, but does the tpm ever force a change when > > > the request use bit is set, or does it leave it up to the software > > > to deal with it and only gets involved in the case where the seize > > > bit has been set? > > > > Do we handle these cases? Maybe something like that has happened.. > > > > Jason > > If that is what happened in this case we should see the beenSeized bit > set in the access register (assuming the chip is doing things properly), > but it only had the tpmRegValidSts and tpmEstablishment bits set. > > There is code in the interrupt handling that notices if the locality > changes if the chip has that capability, but I don't think there is > anything that deals with the seize bit. Another thing to be looked > at. For me it is hard to understand who is the 3rd party who would be using other locality and accessing TPM after OS handover in the regression in question. /Jarkko ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2017-11-14 14:59 ` Jarkko Sakkinen @ 2017-11-14 15:17 ` James Bottomley 2017-11-17 13:16 ` Jarkko Sakkinen 0 siblings, 1 reply; 62+ messages in thread From: James Bottomley @ 2017-11-14 15:17 UTC (permalink / raw) To: Jarkko Sakkinen, Jerry Snitselaar Cc: Jason Gunthorpe, Laurent Bigonville, Alexander.Steffen, linux-integrity On Tue, 2017-11-14 at 16:59 +0200, Jarkko Sakkinen wrote: > On Sat, Nov 11, 2017 at 01:31:32PM -0700, Jerry Snitselaar wrote: > > > > On Sat Nov 11 17, Jason Gunthorpe wrote: > > > > > > On Sat, Nov 11, 2017 at 12:12:57PM -0700, Jerry Snitselaar wrote: > > > > > > > > > > > Before the release_locality code would only actually release > > > > the locality if the request use bit was set. So after it > > > > grabbed the locality during probe it probably never released > > > > it. The idea with the new code was to release it when it was no > > > > longer needed so another requester would be able to take the > > > > tpm without having to wait for it to be released. > > > > > > If I recall, this was so that system level things outside linux > > > could access the TPM properly?? > > > > > > > Yes, that is what drove this initially. I believe Jarkko was also > > thinking of the possibility in the future where something like a vm > > could request a locality as well, but that is just a hazy > > recollection of emails from back then. > > This was something I recall discussing in LPC 2016 in the hallway at > least :-) A tidbit but it could make sense to tie it to VMM, not VM. I think we should be extremely wary of different localities before we have a cast iron definition of what they mean. All the TPM PC spec says is that locality 4 is reserved for firmware (meaning the kernel should have no access) and it implies there's a privilege hierarchy, making 4 the most privileged and 0 the least but leaves all the definition to the OS. Since we only have four other localities to play with, we need a global definition of what they mean in Linux (and who protects them) otherwise we'll get conflicting uses. What does Windows use them for? James ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2017-11-14 15:17 ` James Bottomley @ 2017-11-17 13:16 ` Jarkko Sakkinen 2018-01-02 23:54 ` Laurent Bigonville 0 siblings, 1 reply; 62+ messages in thread From: Jarkko Sakkinen @ 2017-11-17 13:16 UTC (permalink / raw) To: James Bottomley Cc: Jerry Snitselaar, Jason Gunthorpe, Laurent Bigonville, Alexander.Steffen, linux-integrity On Tue, Nov 14, 2017 at 07:17:11AM -0800, James Bottomley wrote: > On Tue, 2017-11-14 at 16:59 +0200, Jarkko Sakkinen wrote: > > On Sat, Nov 11, 2017 at 01:31:32PM -0700, Jerry Snitselaar wrote: > > > > > > On Sat Nov 11 17, Jason Gunthorpe wrote: > > > > > > > > On Sat, Nov 11, 2017 at 12:12:57PM -0700, Jerry Snitselaar wrote: > > > > > > > > > > > > > > Before the release_locality code would only actually release > > > > > the locality if the request use bit was set. So after it > > > > > grabbed the locality during probe it probably never released > > > > > it. The idea with the new code was to release it when it was no > > > > > longer needed so another requester would be able to take the > > > > > tpm without having to wait for it to be released. > > > > > > > > If I recall, this was so that system level things outside linux > > > > could access the TPM properly?? > > > > > > > > > > Yes, that is what drove this initially. I believe Jarkko was also > > > thinking of the possibility in the future where something like a vm > > > could request a locality as well, but that is just a hazy > > > recollection of emails from back then. > > > > This was something I recall discussing in LPC 2016 in the hallway at > > least :-) A tidbit but it could make sense to tie it to VMM, not VM. > > I think we should be extremely wary of different localities before we > have a cast iron definition of what they mean. All the TPM PC spec > says is that locality 4 is reserved for firmware (meaning the kernel > should have no access) and it implies there's a privilege hierarchy, > making 4 the most privileged and 0 the least but leaves all the > definition to the OS. Since we only have four other localities to play > with, we need a global definition of what they mean in Linux (and who > protects them) otherwise we'll get conflicting uses. What does Windows > use them for? > > James No idea. If I had to guess, they use only one locality for OS as this what PTT/fTPM had when it didn't have localities. At least their implementation works with only one locality. /Jarkko ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2017-11-17 13:16 ` Jarkko Sakkinen @ 2018-01-02 23:54 ` Laurent Bigonville 2018-01-03 0:33 ` Jerry Snitselaar 0 siblings, 1 reply; 62+ messages in thread From: Laurent Bigonville @ 2018-01-02 23:54 UTC (permalink / raw) To: Jarkko Sakkinen, James Bottomley Cc: Jerry Snitselaar, Jason Gunthorpe, Alexander.Steffen, linux-integrity Le 17/11/17 a 14:16, Jarkko Sakkinen a ecrit : > On Tue, Nov 14, 2017 at 07:17:11AM -0800, James Bottomley wrote: >> On Tue, 2017-11-14 at 16:59 +0200, Jarkko Sakkinen wrote: >>> On Sat, Nov 11, 2017 at 01:31:32PM -0700, Jerry Snitselaar wrote: >>>> On Sat Nov 11 17, Jason Gunthorpe wrote: >>>>> On Sat, Nov 11, 2017 at 12:12:57PM -0700, Jerry Snitselaar wrote: >>>>> >>>>>> Before the release_locality code would only actually release >>>>>> the locality if the request use bit was set. So after it >>>>>> grabbed the locality during probe it probably never released >>>>>> it. The idea with the new code was to release it when it was no >>>>>> longer needed so another requester would be able to take the >>>>>> tpm without having to wait for it to be released. >>>>> If I recall, this was so that system level things outside linux >>>>> could access the TPM properly?? >>>>> >>>> Yes, that is what drove this initially. I believe Jarkko was also >>>> thinking of the possibility in the future where something like a vm >>>> could request a locality as well, but that is just a hazy >>>> recollection of emails from back then. >>> This was something I recall discussing in LPC 2016 in the hallway at >>> least :-) A tidbit but it could make sense to tie it to VMM, not VM. >> I think we should be extremely wary of different localities before we >> have a cast iron definition of what they mean. All the TPM PC spec >> says is that locality 4 is reserved for firmware (meaning the kernel >> should have no access) and it implies there's a privilege hierarchy, >> making 4 the most privileged and 0 the least but leaves all the >> definition to the OS. Since we only have four other localities to play >> with, we need a global definition of what they mean in Linux (and who >> protects them) otherwise we'll get conflicting uses. What does Windows >> use them for? >> >> James > No idea. If I had to guess, they use only one locality for OS as this > what PTT/fTPM had when it didn't have localities. At least their > implementation works with only one locality. > No more idea then? :( ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2018-01-02 23:54 ` Laurent Bigonville @ 2018-01-03 0:33 ` Jerry Snitselaar 2018-01-05 19:01 ` Laurent Bigonville 2018-02-09 10:53 ` Laurent Bigonville 0 siblings, 2 replies; 62+ messages in thread From: Jerry Snitselaar @ 2018-01-03 0:33 UTC (permalink / raw) To: Laurent Bigonville Cc: Jarkko Sakkinen, James Bottomley, Jason Gunthorpe, Alexander.Steffen, linux-integrity On Wed Jan 03 18, Laurent Bigonville wrote: >Le 17/11/17 a 14:16, Jarkko Sakkinen a ecrit : >>On Tue, Nov 14, 2017 at 07:17:11AM -0800, James Bottomley wrote: >>>On Tue, 2017-11-14 at 16:59 +0200, Jarkko Sakkinen wrote: >>>>On Sat, Nov 11, 2017 at 01:31:32PM -0700, Jerry Snitselaar wrote: >>>>>On Sat Nov 11 17, Jason Gunthorpe wrote: >>>>>>On Sat, Nov 11, 2017 at 12:12:57PM -0700, Jerry Snitselaar wrote: >>>>>> >>>>>>>Before the release_locality code would only actually release >>>>>>>the locality if the request use bit was set. So after it >>>>>>>grabbed the locality during probe it probably never released >>>>>>>it. The idea with the new code was to release it when it was no >>>>>>>longer needed so another requester would be able to take the >>>>>>>tpm without having to wait for it to be released. >>>>>>If I recall, this was so that system level things outside linux >>>>>>could access the TPM properly?? >>>>>> >>>>>Yes, that is what drove this initially. I believe Jarkko was also >>>>>thinking of the possibility in the future where something like a vm >>>>>could request a locality as well, but that is just a hazy >>>>>recollection of emails from back then. >>>>This was something I recall discussing in LPC 2016 in the hallway at >>>>least :-) A tidbit but it could make sense to tie it to VMM, not VM. >>>I think we should be extremely wary of different localities before we >>>have a cast iron definition of what they mean. All the TPM PC spec >>>says is that locality 4 is reserved for firmware (meaning the kernel >>>should have no access) and it implies there's a privilege hierarchy, >>>making 4 the most privileged and 0 the least but leaves all the >>>definition to the OS. Since we only have four other localities to play >>>with, we need a global definition of what they mean in Linux (and who >>>protects them) otherwise we'll get conflicting uses. What does Windows >>>use them for? >>> >>>James >>No idea. If I had to guess, they use only one locality for OS as this >>what PTT/fTPM had when it didn't have localities. At least their >>implementation works with only one locality. >> > >No more idea then? :( Hi Laurent, Can you try the following debug patch (earlier idea of adding a sleep to allow tpm to complete state transition): --8<-- diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c index fdde971bc810..6a9325b02059 100644 --- a/drivers/char/tpm/tpm_tis_core.c +++ b/drivers/char/tpm/tpm_tis_core.c @@ -80,6 +80,7 @@ static void release_locality(struct tpm_chip *chip, int l) struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev); tpm_tis_write8(priv, TPM_ACCESS(l), TPM_ACCESS_ACTIVE_LOCALITY); + tpm_msleep(200); } static int request_locality(struct tpm_chip *chip, int l) -- 2.15.0 ^ permalink raw reply related [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2018-01-03 0:33 ` Jerry Snitselaar @ 2018-01-05 19:01 ` Laurent Bigonville 2018-02-09 10:53 ` Laurent Bigonville 1 sibling, 0 replies; 62+ messages in thread From: Laurent Bigonville @ 2018-01-05 19:01 UTC (permalink / raw) To: Jerry Snitselaar Cc: Jarkko Sakkinen, James Bottomley, Jason Gunthorpe, Alexander.Steffen, linux-integrity Le 03/01/18 a 01:33, Jerry Snitselaar a ecrit : > On Wed Jan 03 18, Laurent Bigonville wrote: >> Le 17/11/17 a 14:16, Jarkko Sakkinen a ecrit : >>> On Tue, Nov 14, 2017 at 07:17:11AM -0800, James Bottomley wrote: >>>> On Tue, 2017-11-14 at 16:59 +0200, Jarkko Sakkinen wrote: >>>>> On Sat, Nov 11, 2017 at 01:31:32PM -0700, Jerry Snitselaar wrote: >>>>>> On Sat Nov 11 17, Jason Gunthorpe wrote: >>>>>>> On Sat, Nov 11, 2017 at 12:12:57PM -0700, Jerry Snitselaar wrote: >>>>>>> >>>>>>>> Before the release_locality code would only actually release >>>>>>>> the locality if the request use bit was set. So after it >>>>>>>> grabbed the locality during probe it probably never released >>>>>>>> it. The idea with the new code was to release it when it was no >>>>>>>> longer needed so another requester would be able to take the >>>>>>>> tpm without having to wait for it to be released. >>>>>>> If I recall, this was so that system level things outside linux >>>>>>> could access the TPM properly?? >>>>>>> >>>>>> Yes, that is what drove this initially. I believe Jarkko was also >>>>>> thinking of the possibility in the future where something like a vm >>>>>> could request a locality as well, but that is just a hazy >>>>>> recollection of emails from back then. >>>>> This was something I recall discussing in LPC 2016 in the hallway at >>>>> least :-) A tidbit but it could make sense to tie it to VMM, not VM. >>>> I think we should be extremely wary of different localities before we >>>> have a cast iron definition of what they mean. All the TPM PC spec >>>> says is that locality 4 is reserved for firmware (meaning the kernel >>>> should have no access) and it implies there's a privilege hierarchy, >>>> making 4 the most privileged and 0 the least but leaves all the >>>> definition to the OS. Since we only have four other localities to >>>> play >>>> with, we need a global definition of what they mean in Linux (and who >>>> protects them) otherwise we'll get conflicting uses. What does >>>> Windows >>>> use them for? >>>> >>>> James >>> No idea. If I had to guess, they use only one locality for OS as this >>> what PTT/fTPM had when it didn't have localities. At least their >>> implementation works with only one locality. >>> >> >> No more idea then? :( > > Hi Laurent, > > Can you try the following debug patch (earlier idea of adding a sleep > to allow > tpm to complete state transition): > > --8<-- > > diff --git a/drivers/char/tpm/tpm_tis_core.c > b/drivers/char/tpm/tpm_tis_core.c > index fdde971bc810..6a9325b02059 100644 > --- a/drivers/char/tpm/tpm_tis_core.c > +++ b/drivers/char/tpm/tpm_tis_core.c > @@ -80,6 +80,7 @@ static void release_locality(struct tpm_chip *chip, > int l) > struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev); > > tpm_tis_write8(priv, TPM_ACCESS(l), TPM_ACCESS_ACTIVE_LOCALITY); > + tpm_msleep(200); > } > > static int request_locality(struct tpm_chip *chip, int l) Thanks, With that patch the device is showing up again in /dev and I tpm_sealdata is working as well ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2018-01-03 0:33 ` Jerry Snitselaar 2018-01-05 19:01 ` Laurent Bigonville @ 2018-02-09 10:53 ` Laurent Bigonville 2018-02-14 11:44 ` Jarkko Sakkinen 1 sibling, 1 reply; 62+ messages in thread From: Laurent Bigonville @ 2018-02-09 10:53 UTC (permalink / raw) To: Jerry Snitselaar Cc: Jarkko Sakkinen, James Bottomley, Jason Gunthorpe, Alexander.Steffen, linux-integrity I don't remember if I replied to this, re-posting to be sure: Le 03/01/18 a 01:33, Jerry Snitselaar a ecrit : > Hi Laurent, > > Can you try the following debug patch (earlier idea of adding a sleep > to allow > tpm to complete state transition): > > --8<-- > > diff --git a/drivers/char/tpm/tpm_tis_core.c > b/drivers/char/tpm/tpm_tis_core.c > index fdde971bc810..6a9325b02059 100644 > --- a/drivers/char/tpm/tpm_tis_core.c > +++ b/drivers/char/tpm/tpm_tis_core.c > @@ -80,6 +80,7 @@ static void release_locality(struct tpm_chip *chip, > int l) > struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev); > > tpm_tis_write8(priv, TPM_ACCESS(l), TPM_ACCESS_ACTIVE_LOCALITY); > + tpm_msleep(200); > } > > static int request_locality(struct tpm_chip *chip, int l) I tried the patch and this is working. Would that be a viable solution? Kind regards, Laurent Bigonville ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2018-02-09 10:53 ` Laurent Bigonville @ 2018-02-14 11:44 ` Jarkko Sakkinen 2018-03-09 17:24 ` Laurent Bigonville 0 siblings, 1 reply; 62+ messages in thread From: Jarkko Sakkinen @ 2018-02-14 11:44 UTC (permalink / raw) To: Laurent Bigonville Cc: Jerry Snitselaar, James Bottomley, Jason Gunthorpe, Alexander.Steffen, linux-integrity On Fri, Feb 09, 2018 at 11:53:55AM +0100, Laurent Bigonville wrote: > I don't remember if I replied to this, re-posting to be sure: > > Le 03/01/18 a 01:33, Jerry Snitselaar a ecrit : > > Hi Laurent, > > > > Can you try the following debug patch (earlier idea of adding a sleep to > > allow > > tpm to complete state transition): > > > > --8<-- > > > > diff --git a/drivers/char/tpm/tpm_tis_core.c > > b/drivers/char/tpm/tpm_tis_core.c > > index fdde971bc810..6a9325b02059 100644 > > --- a/drivers/char/tpm/tpm_tis_core.c > > +++ b/drivers/char/tpm/tpm_tis_core.c > > @@ -80,6 +80,7 @@ static void release_locality(struct tpm_chip *chip, > > int l) > > struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev); > > > > tpm_tis_write8(priv, TPM_ACCESS(l), TPM_ACCESS_ACTIVE_LOCALITY); > > + tpm_msleep(200); > > } > > > > static int request_locality(struct tpm_chip *chip, int l) > > I tried the patch and this is working. > > Would that be a viable solution? > > Kind regards, > > Laurent Bigonville According to the PC client specification in the section 5.5.2.3: "For commands indicated as short or medium duration (i.e., those that do not cause key generation), the TPM SHALL respond to an abort within TIMEOUT_A. For commands indicated as lon g duration or those that cause key generation, the TPM SHALL respond to a request to abort the command within TIMEOUT B" The section 5.5.2.4 describing the access register does not give much more light to this i.e. what the expected duration maximum is when there is no command executing. /Jarkko ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2018-02-14 11:44 ` Jarkko Sakkinen @ 2018-03-09 17:24 ` Laurent Bigonville 2018-03-15 16:24 ` Jarkko Sakkinen 0 siblings, 1 reply; 62+ messages in thread From: Laurent Bigonville @ 2018-03-09 17:24 UTC (permalink / raw) To: Jarkko Sakkinen Cc: Jerry Snitselaar, James Bottomley, Jason Gunthorpe, Alexander.Steffen, linux-integrity Le 14/02/18 a 12:44, Jarkko Sakkinen a ecrit : > On Fri, Feb 09, 2018 at 11:53:55AM +0100, Laurent Bigonville wrote: >> I don't remember if I replied to this, re-posting to be sure: >> >> Le 03/01/18 a 01:33, Jerry Snitselaar a ecrit : >>> Hi Laurent, >>> >>> Can you try the following debug patch (earlier idea of adding a sleep to >>> allow >>> tpm to complete state transition): >>> >>> --8<-- >>> >>> diff --git a/drivers/char/tpm/tpm_tis_core.c >>> b/drivers/char/tpm/tpm_tis_core.c >>> index fdde971bc810..6a9325b02059 100644 >>> --- a/drivers/char/tpm/tpm_tis_core.c >>> +++ b/drivers/char/tpm/tpm_tis_core.c >>> @@ -80,6 +80,7 @@ static void release_locality(struct tpm_chip *chip, >>> int l) >>> struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev); >>> >>> tpm_tis_write8(priv, TPM_ACCESS(l), TPM_ACCESS_ACTIVE_LOCALITY); >>> + tpm_msleep(200); >>> } >>> >>> static int request_locality(struct tpm_chip *chip, int l) >> I tried the patch and this is working. >> >> Would that be a viable solution? >> >> Kind regards, >> >> Laurent Bigonville > According to the PC client specification in the section 5.5.2.3: > > "For commands indicated as short or medium duration (i.e., those that do > not cause key generation), the TPM SHALL respond to an abort within > TIMEOUT_A. For commands indicated as lon g duration or those that cause > key generation, the TPM SHALL respond to a request to abort the command > within TIMEOUT B" > > The section 5.5.2.4 describing the access register does not give much > more light to this i.e. what the expected duration maximum is when there > is no command executing. The duration that that was in your patch seems to work, cannot this be implemented? I'm quite surprised I'm the only one impacted by this... ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2018-03-09 17:24 ` Laurent Bigonville @ 2018-03-15 16:24 ` Jarkko Sakkinen 2018-05-03 11:38 ` Laurent Bigonville 0 siblings, 1 reply; 62+ messages in thread From: Jarkko Sakkinen @ 2018-03-15 16:24 UTC (permalink / raw) To: Laurent Bigonville, Jerry Snitselaar Cc: James Bottomley, Jason Gunthorpe, Alexander.Steffen, linux-integrity On Fri, 2018-03-09 at 18:24 +0100, Laurent Bigonville wrote: > The duration that that was in your patch seems to work, cannot this be > implemented? > > I'm quite surprised I'm the only one impacted by this... Sorry it took so long time response but I had forgotten so too many details. After re-reading (PHEW!) the whole thread I'm thinking if we could use section 5.5.2.4 as a reference to select a timeout of TIMEOUT_A (albeit it is for request locality) and use Jerry's suggestion to put wait_for_tpm_stat() there? Opinions? /Jarkko ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2018-03-15 16:24 ` Jarkko Sakkinen @ 2018-05-03 11:38 ` Laurent Bigonville 2018-05-03 17:43 ` Jerry Snitselaar 2018-05-04 8:18 ` Jarkko Sakkinen 0 siblings, 2 replies; 62+ messages in thread From: Laurent Bigonville @ 2018-05-03 11:38 UTC (permalink / raw) To: Jarkko Sakkinen, Jerry Snitselaar Cc: James Bottomley, Jason Gunthorpe, Alexander.Steffen, linux-integrity Le 15/03/18 a 17:24, Jarkko Sakkinen a ecrit : > On Fri, 2018-03-09 at 18:24 +0100, Laurent Bigonville wrote: >> The duration that that was in your patch seems to work, cannot this be >> implemented? >> >> I'm quite surprised I'm the only one impacted by this... > Sorry it took so long time response but I had forgotten so too many > details. > > After re-reading (PHEW!) the whole thread I'm thinking if we could > use section 5.5.2.4 as a reference to select a timeout of TIMEOUT_A > (albeit it is for request locality) and use Jerry's suggestion to > put wait_for_tpm_stat() there? Opinions? Hey, Sorry to bother you again, but are there any progress on getting this mainlined? Kind regards, Laurent Bigonville ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2018-05-03 11:38 ` Laurent Bigonville @ 2018-05-03 17:43 ` Jerry Snitselaar 2018-05-04 8:20 ` Jarkko Sakkinen 2018-05-04 8:18 ` Jarkko Sakkinen 1 sibling, 1 reply; 62+ messages in thread From: Jerry Snitselaar @ 2018-05-03 17:43 UTC (permalink / raw) To: Laurent Bigonville Cc: Jarkko Sakkinen, James Bottomley, Jason Gunthorpe, Alexander.Steffen, linux-integrity On Thu May 03 18, Laurent Bigonville wrote: >Le 15/03/18 a 17:24, Jarkko Sakkinen a ecrit : >>On Fri, 2018-03-09 at 18:24 +0100, Laurent Bigonville wrote: >>>The duration that that was in your patch seems to work, cannot this be >>>implemented? >>> >>>I'm quite surprised I'm the only one impacted by this... >>Sorry it took so long time response but I had forgotten so too many >>details. >> >>After re-reading (PHEW!) the whole thread I'm thinking if we could >>use section 5.5.2.4 as a reference to select a timeout of TIMEOUT_A >>(albeit it is for request locality) and use Jerry's suggestion to >>put wait_for_tpm_stat() there? Opinions? >Hey, > >Sorry to bother you again, but are there any progress on getting this >mainlined? > >Kind regards, > >Laurent Bigonville Jarkko would something like this work? Building it to test on tpm2.0 system right now. I don't have access to a system with a tpm1.2 tis device at the moment. I tested a patch similar to this based on the slightly older code that is currently in the rhel kernel and it seemed work fine. release_locality was still a void function back then, so might have to think more about the return values here and checking them. Also wondering if release_locality, check_locality, and wait_for_tpm_stat can be refactored since they would all have basically the same chunk of code. Jerry diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c index 5a1f47b43947..31ee154450eb 100644 --- a/drivers/char/tpm/tpm_tis_core.c +++ b/drivers/char/tpm/tpm_tis_core.c @@ -143,12 +143,56 @@ static bool check_locality(struct tpm_chip *chip, int l) return false; } +static bool locality_inactive(struct tpm_chip *chip, int l) +{ + struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev); + int rc; + u8 access; + + rc = tpm_tis_read8(priv, TPM_ACCESS(l), &access); + if (rc < 0) + return false; + + if ((access & (TPM_ACCESS_VALID | TPM_ACCESS_ACTIVE_LOCALITY)) == TPM_ACCESS_VALID) + return true; + + return false; +} + static int release_locality(struct tpm_chip *chip, int l) { struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev); + unsigned long stop, timeout; + long rc; tpm_tis_write8(priv, TPM_ACCESS(l), TPM_ACCESS_ACTIVE_LOCALITY); + stop = jiffies + chip->timeout_a; + + if (chip->flags & TPM_CHIP_FLAG_IRQ) { +again: + timeout = stop - jiffies; + if ((long)timeout <= 0) + return -1; + + rc = wait_event_interruptible_timeout(priv->int_queue, + (locality_inactive(chip, l)), + timeout); + + if (rc > 0) + return rc; + + if (rc == -ERESTARTSYS && freezing(current)) { + clear_thread_flag(TIF_SIGPENDING); + goto again; + } + } else { + do { + if (locality_inactive(chip, l)) + return 0; + tpm_msleep(TPM_TIMEOUT); + } while (time_before(jiffies, stop)); + } return 0; } ^ permalink raw reply related [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2018-05-03 17:43 ` Jerry Snitselaar @ 2018-05-04 8:20 ` Jarkko Sakkinen 0 siblings, 0 replies; 62+ messages in thread From: Jarkko Sakkinen @ 2018-05-04 8:20 UTC (permalink / raw) To: Jerry Snitselaar Cc: Laurent Bigonville, James Bottomley, Jason Gunthorpe, Alexander.Steffen, linux-integrity On Thu, May 03, 2018 at 10:43:11AM -0700, Jerry Snitselaar wrote: > On Thu May 03 18, Laurent Bigonville wrote: > > Le 15/03/18 a 17:24, Jarkko Sakkinen a ecrit : > > > On Fri, 2018-03-09 at 18:24 +0100, Laurent Bigonville wrote: > > > > The duration that that was in your patch seems to work, cannot this be > > > > implemented? > > > > > > > > I'm quite surprised I'm the only one impacted by this... > > > Sorry it took so long time response but I had forgotten so too many > > > details. > > > > > > After re-reading (PHEW!) the whole thread I'm thinking if we could > > > use section 5.5.2.4 as a reference to select a timeout of TIMEOUT_A > > > (albeit it is for request locality) and use Jerry's suggestion to > > > put wait_for_tpm_stat() there? Opinions? > > Hey, > > > > Sorry to bother you again, but are there any progress on getting this > > mainlined? > > > > Kind regards, > > > > Laurent Bigonville > > Jarkko would something like this work? Building it to test on tpm2.0 system right now. > I don't have access to a system with a tpm1.2 tis device at the moment. I tested a > patch similar to this based on the slightly older code that is currently in the > rhel kernel and it seemed work fine. release_locality was still a void function > back then, so might have to think more about the return values here and checking > them. Also wondering if release_locality, check_locality, and wait_for_tpm_stat > can be refactored since they would all have basically the same chunk of code. > > Jerry > > diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c > index 5a1f47b43947..31ee154450eb 100644 > --- a/drivers/char/tpm/tpm_tis_core.c > +++ b/drivers/char/tpm/tpm_tis_core.c > @@ -143,12 +143,56 @@ static bool check_locality(struct tpm_chip *chip, int l) > return false; > } > > +static bool locality_inactive(struct tpm_chip *chip, int l) > +{ > + struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev); > + int rc; > + u8 access; > + > + rc = tpm_tis_read8(priv, TPM_ACCESS(l), &access); > + if (rc < 0) > + return false; > + > + if ((access & (TPM_ACCESS_VALID | TPM_ACCESS_ACTIVE_LOCALITY)) == TPM_ACCESS_VALID) > + return true; > + > + return false; > +} > + > static int release_locality(struct tpm_chip *chip, int l) > { > struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev); > + unsigned long stop, timeout; > + long rc; > > tpm_tis_write8(priv, TPM_ACCESS(l), TPM_ACCESS_ACTIVE_LOCALITY); > > + stop = jiffies + chip->timeout_a; > + > + if (chip->flags & TPM_CHIP_FLAG_IRQ) { > +again: > + timeout = stop - jiffies; > + if ((long)timeout <= 0) > + return -1; > + > + rc = wait_event_interruptible_timeout(priv->int_queue, > + (locality_inactive(chip, l)), > + timeout); > + > + if (rc > 0) > + return rc; > + > + if (rc == -ERESTARTSYS && freezing(current)) { > + clear_thread_flag(TIF_SIGPENDING); > + goto again; > + } > + } else { > + do { > + if (locality_inactive(chip, l)) > + return 0; > + tpm_msleep(TPM_TIMEOUT); > + } while (time_before(jiffies, stop)); > + } Maybe have the second branch first with a return statement and convert the thing going on in the first branch as a loop? /Jarkko ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2018-05-03 11:38 ` Laurent Bigonville 2018-05-03 17:43 ` Jerry Snitselaar @ 2018-05-04 8:18 ` Jarkko Sakkinen 2018-05-04 14:22 ` Jerry Snitselaar 1 sibling, 1 reply; 62+ messages in thread From: Jarkko Sakkinen @ 2018-05-04 8:18 UTC (permalink / raw) To: Laurent Bigonville Cc: Jerry Snitselaar, James Bottomley, Jason Gunthorpe, Alexander.Steffen, linux-integrity On Thu, May 03, 2018 at 01:38:17PM +0200, Laurent Bigonville wrote: > Le 15/03/18 a 17:24, Jarkko Sakkinen a ecrit : > > On Fri, 2018-03-09 at 18:24 +0100, Laurent Bigonville wrote: > > > The duration that that was in your patch seems to work, cannot this be > > > implemented? > > > > > > I'm quite surprised I'm the only one impacted by this... > > Sorry it took so long time response but I had forgotten so too many > > details. > > > > After re-reading (PHEW!) the whole thread I'm thinking if we could > > use section 5.5.2.4 as a reference to select a timeout of TIMEOUT_A > > (albeit it is for request locality) and use Jerry's suggestion to > > put wait_for_tpm_stat() there? Opinions? > Hey, > > Sorry to bother you again, but are there any progress on getting this > mainlined? > > Kind regards, > > Laurent Bigonville Sorry for not doing anything. Jerry, do you want to send patch? /Jarkko ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2018-05-04 8:18 ` Jarkko Sakkinen @ 2018-05-04 14:22 ` Jerry Snitselaar 0 siblings, 0 replies; 62+ messages in thread From: Jerry Snitselaar @ 2018-05-04 14:22 UTC (permalink / raw) To: Jarkko Sakkinen Cc: Laurent Bigonville, James Bottomley, Jason Gunthorpe, Alexander.Steffen, linux-integrity On Fri May 04 18, Jarkko Sakkinen wrote: >On Thu, May 03, 2018 at 01:38:17PM +0200, Laurent Bigonville wrote: >> Le 15/03/18 a 17:24, Jarkko Sakkinen a ecrit : >> > On Fri, 2018-03-09 at 18:24 +0100, Laurent Bigonville wrote: >> > > The duration that that was in your patch seems to work, cannot this be >> > > implemented? >> > > >> > > I'm quite surprised I'm the only one impacted by this... >> > Sorry it took so long time response but I had forgotten so too many >> > details. >> > >> > After re-reading (PHEW!) the whole thread I'm thinking if we could >> > use section 5.5.2.4 as a reference to select a timeout of TIMEOUT_A >> > (albeit it is for request locality) and use Jerry's suggestion to >> > put wait_for_tpm_stat() there? Opinions? >> Hey, >> >> Sorry to bother you again, but are there any progress on getting this >> mainlined? >> >> Kind regards, >> >> Laurent Bigonville > >Sorry for not doing anything. Jerry, do you want to send patch? > >/Jarkko Yes. I'll send a patch today. Jerry ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2017-11-11 19:46 ` Jason Gunthorpe 2017-11-11 20:31 ` Jerry Snitselaar @ 2017-11-14 14:55 ` Jarkko Sakkinen 1 sibling, 0 replies; 62+ messages in thread From: Jarkko Sakkinen @ 2017-11-14 14:55 UTC (permalink / raw) To: Jason Gunthorpe Cc: Jerry Snitselaar, Laurent Bigonville, Alexander.Steffen, linux-integrity On Sat, Nov 11, 2017 at 12:46:47PM -0700, Jason Gunthorpe wrote: > On Sat, Nov 11, 2017 at 12:12:57PM -0700, Jerry Snitselaar wrote: > > > Before the release_locality code would only actually release the > > locality if the request use bit was set. So after it grabbed the > > locality during probe it probably never released it. The idea with the > > new code was to release it when it was no longer needed so another > > requester would be able to take the tpm without having to wait for it > > to be released. > > If I recall, this was so that system level things outside linux could > access the TPM properly?? > > > With the old code I think it would have to wait either > > until the next time release_locality was called, or attempt to seize > > the tpm with the seize bit in the access register. I need to read > > through the spec some more, but does the tpm ever force a change when > > the request use bit is set, or does it leave it up to the software > > to deal with it and only gets involved in the case where the seize > > bit has been set? > > Do we handle these cases? Maybe something like that has happened.. > > Jason At least the driver works with TXT properly that uses locality 2. The locality stuff for tpm_crb has bee made to work sanely with TXT. /Jarkko ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore 2017-11-10 20:53 ` Jerry Snitselaar 2017-11-11 15:45 ` Jason Gunthorpe @ 2017-11-14 14:43 ` Jarkko Sakkinen 1 sibling, 0 replies; 62+ messages in thread From: Jarkko Sakkinen @ 2017-11-14 14:43 UTC (permalink / raw) To: Jerry Snitselaar; +Cc: Laurent Bigonville, Alexander.Steffen, linux-integrity On Fri, Nov 10, 2017 at 01:53:00PM -0700, Jerry Snitselaar wrote: > On Fri Nov 10 17, Laurent Bigonville wrote: > > Le 10/11/17 a 08:07, Jerry Snitselaar a ecrit : > > > On Thu Nov 09 17, Jerry Snitselaar wrote: > > > > On Thu Nov 09 17, Laurent Bigonville wrote: > > > > > Le 09/11/17 a 01:04, Laurent Bigonville a ecrit : > > > > > > > > > > > > > > > > > > Le 24/10/17 a 18:07, Jarkko Sakkinen a ecrit : > > > > > > > On Tue, Oct 24, 2017 at 07:57:06AM -0700, Jerry Snitselaar wrote: > > > > > > > > On Tue Oct 24 17, Jarkko Sakkinen wrote: > > > > > > > > > On Mon, Oct 23, 2017 at 06:45:15AM -0700, Jerry Snitselaar wrote: > > > > > > > > > > On Mon Oct 23 17, Jarkko Sakkinen wrote: > > > > > > > > > > > On Sat, Oct 21, 2017 at 10:53:55AM > > > > > > > > > > > +0200, Laurent Bigonville wrote: > > > > > > > > > > > > Le 14/10/17 a 10:13, Jerry Snitselaar a ecrit : > > > > > > > > > > > > > On Wed Sep 06 17, Jarkko Sakkinen wrote: > > > > > > > > > > > > > > On Fri, Sep 01, 2017 at > > > > > > > > > > > > > > 02:10:18PM +0200, > > > > > > > > > > > > > > Laurent Bigonville > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Le 31/08/17 a 18:40, Jerry Snitselaar a ecrit : > > > > > > > > > > > > > > > > On Thu Aug 31 17, Alexander.Steffen@infineon.com wrote: > > > > > > > > > > > > > > > > > > Le 29/08/17 a 18:35, Laurent Bigonville a ecrit : > > > > > > > > > > > > > > > > > > > Le > > > > > > > > > > > > > > > > > > > 29/08/17 > > > > > > > > > > > > > > > > > > > a > > > > > > > > > > > > > > > > > > > 18:00, > > > > > > > > > > > > > > > > > > > Alexander.Steffen@infineon.com > > > > > > > > > > > > > > > > > > > a > > > > > > > > > > > > > > > > > > > ecrit : > > > > > > > > > > > > > > > > > > > > > An idea how to troubleshoot this? > > > > > > > > > > > > > > > > > > > > Can you run git bisect on the changes between 4.11 and > > > > > > > > > > > > > > > 4.12, so that > > > > > > > > > > > > > > > > > > > > we find the offending commit? It is probably sufficient > > > > > > > > > > > > > > > to limit the > > > > > > > > > > > > > > > > > > > > search > > > > > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > > > commits > > > > > > > > > > > > > > > > > > > > that > > > > > > > > > > > > > > > > > > > > touch > > > > > > > > > > > > > > > > > > > > something > > > > > > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > > > > > drivers/char/tpm. > > > > > > > > > > > > > > > > > > > I'll try and keep you posted. > > > > > > > > > > > > > > > > > > OK I've > > > > > > > > > > > > > > > > > > been > > > > > > > > > > > > > > > > > > able to > > > > > > > > > > > > > > > > > > bisect > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > problem > > > > > > > > > > > > > > > > > > and the > > > > > > > > > > > > > > > > > > bad > > > > > > > > > > > > > > > > > > commit > > > > > > > > > > > > > > > > > > is: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 > > > > > > > > > > > > > > > > > > is the > > > > > > > > > > > > > > > > > > first > > > > > > > > > > > > > > > > > > bad > > > > > > > > > > > > > > > > > > commit > > > > > > > > > > > > > > > > > > commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 > > > > > > > > > > > > > > > > > > Author: Jerry Snitselaar <jsnitsel@redhat.com> > > > > > > > > > > > > > > > > > > Date: Mon Mar 27 08:46:04 2017 -0700 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > tpm_tis: convert to using locality callbacks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This > > > > > > > > > > > > > > > > > > patch > > > > > > > > > > > > > > > > > > converts > > > > > > > > > > > > > > > > > > tpm_tis > > > > > > > > > > > > > > > > > > to use > > > > > > > > > > > > > > > > > > of the > > > > > > > > > > > > > > > > > > new tpm > > > > > > > > > > > > > > > > > > class > > > > > > > > > > > > > > > > > > ops > > > > > > > > > > > > > > > > > > request_locality, and relinquish_locality. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > With the > > > > > > > > > > > > > > > > > > move to > > > > > > > > > > > > > > > > > > using > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > callbacks, > > > > > > > > > > > > > > > > > > release_locality > > > > > > > > > > > > > > > > > > is > > > > > > > > > > > > > > > > > > changed so > > > > > > > > > > > > > > > > > > that we now release the locality even if there is no > > > > > > > > > > > > > > > > > > request pending. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This required some changes to the tpm_tis_core_init > > > > > > > > > > > > > > > code path to > > > > > > > > > > > > > > > > > > make sure locality is requested when needed: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - tpm2_probe code path will end up calling > > > > > > > > > > > > > > > > > > request/release through > > > > > > > > > > > > > > > > > > callbacks, so request_locality prior to > > > > > > > > > > > > > > > tpm2_probe not needed. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > > > > > > > > > > > > probe_itpm > > > > > > > > > > > > > > > > > > makes > > > > > > > > > > > > > > > > > > calls to > > > > > > > > > > > > > > > > > > tpm_tis_send_data > > > > > > > > > > > > > > > > > > which no > > > > > > > > > > > > > > > > > > longer calls > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > request_locality, > > > > > > > > > > > > > > > > > > so add > > > > > > > > > > > > > > > > > > request_locality > > > > > > > > > > > > > > > > > > prior to > > > > > > > > > > > > > > > > > > tpm_tis_send_data > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > calls. > > > > > > > > > > > > > > > > > > Also > > > > > > > > > > > > > > > > > > drop > > > > > > > > > > > > > > > > > > release_locality > > > > > > > > > > > > > > > > > > call in > > > > > > > > > > > > > > > > > > middleof > > > > > > > > > > > > > > > > > > probe_itpm, and > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > keep > > > > > > > > > > > > > > > > > > locality > > > > > > > > > > > > > > > > > > until > > > > > > > > > > > > > > > > > > release_locality > > > > > > > > > > > > > > > > > > called > > > > > > > > > > > > > > > > > > at end > > > > > > > > > > > > > > > > > > of > > > > > > > > > > > > > > > > > > probe_itpm. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: Peter Huewe <peterhuewe@gmx.de> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: > > > > > > > > > > > > > > > > > > Jarkko > > > > > > > > > > > > > > > > > > Sakkinen > > > > > > > > > > > > > > > > > > <jarkko.sakkinen@linux.intel.com> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cc: > > > > > > > > > > > > > > > > > > Jason > > > > > > > > > > > > > > > > > > Gunthorpe > > > > > > > > > > > > > > > > > > <jgunthorpe@obsidianresearch.com> > > > > > > > > > > > > > > > > > > Cc: Marcel Selhorst <tpmdd@selhorst.net> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: > > > > > > > > > > > > > > > > > > Jerry > > > > > > > > > > > > > > > > > > Snitselaar > > > > > > > > > > > > > > > > > > <jsnitsel@redhat.com> > > > > > > > > > > > > > > > > > > Reviewed-by: Jarkko Sakkinen > > > > > > > > > > > > > > > <jarkko.sakkinen@linux.intel.com> > > > > > > > > > > > > > > > > > > Tested-by: > > > > > > > > > > > > > > > > > > Jarkko > > > > > > > > > > > > > > > > > > Sakkinen > > > > > > > > > > > > > > > > > > <jarkko.sakkinen@linux.intel.com> > > > > > > > > > > > > > > > > > > Signed-off-by: Jarkko Sakkinen > > > > > > > > > > > > > > > <jarkko.sakkinen@linux.intel.com> > > > > > > > > > > > > > > > > > > :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 > > > > > > > > > > > > > > > > > > 72f21b446e45ea1003de75902b0553deb99157fd M drivers > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I've looked > > > > > > > > > > > > > > > > > again at the > > > > > > > > > > > > > > > > > code in > > > > > > > > > > > > > > > > > question, > > > > > > > > > > > > > > > > > but could > > > > > > > > > > > > > > > > > not find > > > > > > > > > > > > > > > > > anything that is obviously wrong there. Locality is now > > > > > > > > > > > > > > > > > requested/released > > > > > > > > > > > > > > > > > at slightly > > > > > > > > > > > > > > > > > different > > > > > > > > > > > > > > > > > points in > > > > > > > > > > > > > > > > > the process > > > > > > > > > > > > > > > > > than > > > > > > > > > > > > > > > > > before, but > > > > > > > > > > > > > > > > > that's it. > > > > > > > > > > > > > > > > > It does not > > > > > > > > > > > > > > > > > seem to > > > > > > > > > > > > > > > > > cause > > > > > > > > > > > > > > > > > problems > > > > > > > > > > > > > > > > > with the > > > > > > > > > > > > > > > > > majority of TPMs, since you are the first to report any, so > > > > > > > > > > > > > > > maybe it > > > > > > > > > > > > > > > > > is a quirk that only affects this device. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Perhaps Jerry can help, since this is his change? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Alexander > > > > > > > > > > > > > > > > Getting some > > > > > > > > > > > > > > > > caffeine in me, > > > > > > > > > > > > > > > > and starting to > > > > > > > > > > > > > > > > take a look. > > > > > > > > > > > > > > > > Adding > > > > > > > > > > > > > > > > Jarkko as well > > > > > > > > > > > > > > > > since this might > > > > > > > > > > > > > > > > involve the > > > > > > > > > > > > > > > > general locality > > > > > > > > > > > > > > > > changes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Laurent, if I > > > > > > > > > > > > > > > > send you a patch > > > > > > > > > > > > > > > > with some > > > > > > > > > > > > > > > > debugging code > > > > > > > > > > > > > > > > added, would > > > > > > > > > > > > > > > > you be able to > > > > > > > > > > > > > > > > run it on that > > > > > > > > > > > > > > > > system? I wasn't > > > > > > > > > > > > > > > > running into > > > > > > > > > > > > > > > > issues > > > > > > > > > > > > > > > > on the system I > > > > > > > > > > > > > > > > had with a 1.2 > > > > > > > > > > > > > > > > device, but I no > > > > > > > > > > > > > > > > longer have > > > > > > > > > > > > > > > > access > > > > > > > > > > > > > > > > to it. I'll see > > > > > > > > > > > > > > > > if I can find > > > > > > > > > > > > > > > > one in our labs > > > > > > > > > > > > > > > > and reproduce it > > > > > > > > > > > > > > > > there. > > > > > > > > > > > > > > > Yes I should be able to do that > > > > > > > > > > > > > > Any findings? > > > > > > > > > > > > > > > > > > > > > > > > > > > > /Jarkko > > > > > > > > > > > > > Okay, finally getting back > > > > > > > > > > > > > to this. Looking at the code > > > > > > > > > > > > > it isn't clear > > > > > > > > > > > > > to me > > > > > > > > > > > > > why the change is causing > > > > > > > > > > > > > this. So while I stare at > > > > > > > > > > > > > this some more > > > > > > > > > > > > > Laurent > > > > > > > > > > > > > could you reproduce it with > > > > > > > > > > > > > this patch so I can see what > > > > > > > > > > > > > the status and > > > > > > > > > > > > > access registers look like? > > > > > > > > > > > > > Does anyone else on here > > > > > > > > > > > > > happen to have a > > > > > > > > > > > > > Sinosun > > > > > > > > > > > > > tpm device? The systems I > > > > > > > > > > > > > have access to with TPM1.2 > > > > > > > > > > > > > devices don't have > > > > > > > > > > > > > this > > > > > > > > > > > > > issue. > > > > > > > > > > > > > > > > > > > > > > > > > > --8<-- > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/char/tpm/tpm_tis_core.c > > > > > > > > > > > > > b/drivers/char/tpm/tpm_tis_core.c > > > > > > > > > > > > > index fdde971bc810..7d60a7e4b50a 100644 > > > > > > > > > > > > > --- a/drivers/char/tpm/tpm_tis_core.c > > > > > > > > > > > > > +++ b/drivers/char/tpm/tpm_tis_core.c > > > > > > > > > > > > > @@ -258,6 +258,7 @@ static > > > > > > > > > > > > > int tpm_tis_send_data(struct > > > > > > > > > > > > > tpm_chip *chip, > > > > > > > > > > > > > const u8 *buf, size_t len) > > > > > > > > > > > > > int rc, status, burstcnt; > > > > > > > > > > > > > size_t count = 0; > > > > > > > > > > > > > bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; > > > > > > > > > > > > > + u8 access; > > > > > > > > > > > > > > > > > > > > > > > > > > status = tpm_tis_status(chip); > > > > > > > > > > > > > if ((status & TPM_STS_COMMAND_READY) == 0) { > > > > > > > > > > > > > @@ -292,6 +293,11 @@ static > > > > > > > > > > > > > int tpm_tis_send_data(struct > > > > > > > > > > > > > tpm_chip *chip, > > > > > > > > > > > > > const u8 *buf, size_t len) > > > > > > > > > > > > > } > > > > > > > > > > > > > status = tpm_tis_status(chip); > > > > > > > > > > > > > if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { > > > > > > > > > > > > > + rc = > > > > > > > > > > > > > tpm_tis_read8(priv, > > > > > > > > > > > > > TPM_ACCESS(priv->locality), > > > > > > > > > > > > > &access); > > > > > > > > > > > > > + if (rc < 0) > > > > > > > > > > > > > + > > > > > > > > > > > > > dev_info(&chip->dev, > > > > > > > > > > > > > "TPM_STS_DATA_EXPECT == 0: > > > > > > > > > > > > > read > > > > > > > > > > > > > failure TPM_ACCESS(%d)\n", priv->locality); > > > > > > > > > > > > > + else > > > > > > > > > > > > > + > > > > > > > > > > > > > dev_info(&chip->dev, > > > > > > > > > > > > > "TPM_STS_DATA_EXPECT == 0: > > > > > > > > > > > > > locality: %d status: %x > > > > > > > > > > > > > access: %x\n", > > > > > > > > > > > > > priv->locality, status, > > > > > > > > > > > > > access); > > > > > > > > > > > > > rc = -EIO; > > > > > > > > > > > > > goto out_err; > > > > > > > > > > > > > } > > > > > > > > > > > > > @@ -309,6 +315,11 @@ static > > > > > > > > > > > > > int tpm_tis_send_data(struct > > > > > > > > > > > > > tpm_chip *chip, > > > > > > > > > > > > > const u8 *buf, size_t len) > > > > > > > > > > > > > } > > > > > > > > > > > > > status = tpm_tis_status(chip); > > > > > > > > > > > > > if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { > > > > > > > > > > > > > + rc = > > > > > > > > > > > > > tpm_tis_read8(priv, > > > > > > > > > > > > > TPM_ACCESS(priv->locality), > > > > > > > > > > > > > &access); > > > > > > > > > > > > > + if (rc < 0) > > > > > > > > > > > > > + > > > > > > > > > > > > > dev_info(&chip->dev, > > > > > > > > > > > > > "TPM_STS_DATA_EXPECT != 0: > > > > > > > > > > > > > read > > > > > > > > > > > > > failure TPM_ACCESS(%d)\n", priv->locality); > > > > > > > > > > > > > + else > > > > > > > > > > > > > + > > > > > > > > > > > > > dev_info(&chip->dev, > > > > > > > > > > > > > "TPM_STS_DATA_EXPECT != 0: > > > > > > > > > > > > > locality: > > > > > > > > > > > > > %d status: %x access: %x\n", priv->locality, status, access); > > > > > > > > > > > > > rc = -EIO; > > > > > > > > > > > > > goto out_err; > > > > > > > > > > > > > } > > > > > > > > > > > > Please find here the dmesg output of the patched kernel > > > > > > > > > > > At least 0xff is corrupted value in > > > > > > > > > > > senseful way. CPU fills the read > > > > > > > > > > > with ones for example for unaligned > > > > > > > > > > > bus read. See table 19 in PC client > > > > > > > > > > > spec. This can happen when you do unaligned read for example. > > > > > > > > > > > > > > > > > > > > > > Maybe TPM is unreachable i.e. > > > > > > > > > > > powered off. Bit busy with stuff ATM > > > > > > > > > > > but > > > > > > > > > > > would probably make sense to compare > > > > > > > > > > > that 0x81 to table 18 in the same > > > > > > > > > > > spec. > > > > > > > > > > > > > > > > > > > > > > /Jarkko > > > > > > > > > > 0x81 is saying the access register > > > > > > > > > > status is valid, and the locality > > > > > > > > > > is not active. That first bit means A > > > > > > > > > > Dynamic OS has not been previously > > > > > > > > > > established on the platform. Normally we > > > > > > > > > > would see 0xa1, which would > > > > > > > > > > mean valid register status, and the locality is active. > > > > > > > > > I think the important thing to note here is > > > > > > > > > that STS has bits set that > > > > > > > > > should never be set. So we can conclude that TPM might be either > > > > > > > > > > > > > > > > > > 1. Powered off > > > > > > > > > 2. In some transition state? > > > > > > > > > > > > > > > > > > /Jarkko > > > > > > > > If it was powered off would we be getting a > > > > > > > > valid read from the access > > > > > > > > register? > > > > > > > I think there is no universal answer to that :-) > > > > > > > > > > > > > > Maybe adding a extra delay would be next test to make? If for random > > > > > > > reason it is in-between states... > > > > > > Any more ideas? > > > > > > > > > > > > The chip is definitely in a weird state :/ I tried > > > > > > several ways to reset the chip (windows, tpm-tools,...). > > > > > > > > > > > > I've been able to reset the chip via the bios (which now > > > > > > shows unowned) but chip is still locked apparently. > > > > > > > > > > > > But still with < 4.12 I'm able to get /some/ information > > > > > > Public EK, PCR,... out of the chip so it's not > > > > > > completely broken... > > > > > > > > > > OK correction the TPM is now unlocked (I let the computer > > > > > running for more than 24h with nothing accessing the TPM) > > > > > and with 4.9 I've been able to take the ownership again. > > > > > > > > > > Under 4.12 I still have the same errors as mentioned originally > > > > > > > > Hi Laurent, > > > > > > > > Would it be possible for you to run ftrace from boot with the > > > > following kernel parameters: > > > > > > > > ftrace=function_graph ftrace_filter=tpm* > > > > > > > > > > actually 'ftrace=function_graph > > > ftrace_filter=tpm*,*locality,wait_for_tpm_stat' would be better > > > > > > > and then send me the results of 'cat /sys/kernel/debug/tracing/trace' ? > > Here you are. > > Thank you Laurent. > > A few interesting things here: > > > # tracer: function_graph > > # > > # CPU DURATION FUNCTION CALLS > > # | | | | | | | > > 1) 4.510 us | tpm_init(); > > 1) | tpm_tis_pnp_init() { > > 1) | tpm_tis_init.part.3() { > > 1) | tpm_tis_core_init() { > > 1) | tpmm_chip_alloc() { > > 1) 3.935 us | tpm_chip_alloc(); > > 1) 4.787 us | } > > 1) 0.199 us | tpm_tcg_read_bytes(); > > 1) 0.217 us | tpm_tcg_read32(); > > 1) 0.117 us | tpm_tcg_write32(); > > 1) | tpm2_probe() { > > 1) | tpm_transmit_cmd() { > > 1) | tpm_transmit() { > > 1) | request_locality() { > > 1) | check_locality() { > > 1) 0.045 us | tpm_tcg_read_bytes(); > > 1) 1.708 us | } > > 1) 2.077 us | } > > > So it goes request locality, does check to see if the locality > is already active and it is, so doesn't go through the process > of requesting the locality. > > > > 1) 0.168 us | tpm2_prepare_space(); > > 1) | tpm_tis_send() { > > 1) | tpm_tis_send_main() { > > 1) | tpm_tis_send_data() { > > 1) 0.045 us | tpm_tcg_read_bytes(); > > 1) 0.044 us | tpm_tcg_read32(); > > 1) 1.723 us | tpm_tcg_write_bytes(); > > 1) | wait_for_tpm_stat() { > > 1) | tpm_tis_status() { > > 1) 0.042 us | tpm_tcg_read_bytes(); > > 1) 5.163 us | } > > 1) | tpm_tis_status() { > > 1) 0.167 us | tpm_tcg_read_bytes(); > > 1) 2.182 us | } > > 1) | tpm_tis_status() { > > 1) 0.194 us | tpm_tcg_read_bytes(); > > 1) 2.452 us | } > > 1) * 30406.24 us | } > > 1) 0.088 us | tpm_tcg_read_bytes(); > > 1) 0.123 us | tpm_tcg_write_bytes(); > > 1) | wait_for_tpm_stat() { > > 1) | tpm_tis_status() { > > 1) 0.084 us | tpm_tcg_read_bytes(); > > 1) 1.940 us | } > > 1) | tpm_tis_status() { > > 1) 0.170 us | tpm_tcg_read_bytes(); > > 1) 2.217 us | } > > 1) * 16000.74 us | } > > 1) 0.084 us | tpm_tcg_read_bytes(); > > 1) * 46425.66 us | } > > 1) 0.115 us | tpm_tcg_write_bytes(); > > 1) * 46426.85 us | } > > 1) * 46427.35 us | } > > 1) | tpm_tis_status() { > > 1) 1.389 us | tpm_tcg_read_bytes(); > > 1) 1.909 us | } > > 1) 0.095 us | tpm_tis_req_canceled(); > > 1) | tpm_tis_status() { > > 1) 0.187 us | tpm_tcg_read_bytes(); > > 1) 2.110 us | } > > 1) | tpm_tis_recv() { > > 1) | wait_for_tpm_stat() { > > 1) | tpm_tis_status() { > > 1) 0.082 us | tpm_tcg_read_bytes(); > > 1) 1.898 us | } > > 1) 2.425 us | } > > 1) 0.102 us | tpm_tcg_read32(); > > 1) 5.453 us | tpm_tcg_read_bytes(); > > 1) | wait_for_tpm_stat() { > > 1) | tpm_tis_status() { > > 1) 0.092 us | tpm_tcg_read_bytes(); > > 1) 1.858 us | } > > 1) 2.332 us | } > > 1) 0.077 us | tpm_tcg_read_bytes(); > > 1) 0.112 us | tpm_tcg_write_bytes(); > > 1) + 25.466 us | } > > 1) 0.152 us | tpm2_commit_space(); > > 1) | release_locality() { > > 1) 0.080 us | tpm_tcg_write_bytes(); > > 1) 0.672 us | } > > Releases the locality as it comes back out of tpm_transmit_cmd > > > 1) * 62349.91 us | } > > 1) * 62350.38 us | } > > 1) * 62350.87 us | } > > 1) 0.070 us | tpm_tcg_read32(); > > 1) 0.073 us | tpm_tcg_read_bytes(); > > 1) 0.096 us | tpm_tcg_read16(); > > 1) 0.042 us | tpm_tcg_read32(); > > 1) | tpm_chip_register() { > > 1) | tpm1_auto_startup() { > > 1) | tpm_get_timeouts() { > > 1) | tpm_get_timeouts.part.6() { > > 1) | tpm_getcap() { > > 1) | tpm_transmit_cmd() { > > 1) | tpm_transmit() { > > 1) | request_locality() { > > 1) | check_locality() { > > 1) 0.091 us | tpm_tcg_read_bytes(); > > 1) 1.680 us | } > > 1) 1.973 us | } > > Goes to request the locality again, but once again the check sees > that the locality is already active, so doesn't go through process > of requesting the locality. Very odd. > > > 1) 0.072 us | tpm2_prepare_space(); > > 1) | tpm_tis_send() { > > 1) | tpm_tis_send_main() { > > 1) | tpm_tis_send_data() { > > 1) 0.043 us | tpm_tcg_read_bytes(); > > tpm_tis_stat inlined? > > > 1) 0.071 us | tpm_tcg_write_bytes(); > > tpm_tis_ready inlined? > > > 1) | wait_for_tpm_stat() { > > 1) | tpm_tis_status() { > > 1) 0.042 us | tpm_tcg_read_bytes(); > > 1) 1.634 us | } > > 1) | tpm_tis_status() { > > 1) 0.183 us | tpm_tcg_read_bytes(); > > 1) 2.121 us | } > > 1) * 15942.66 us | } > > The wait_for_tpm_stat does its loop twice checking the status register > so at this point apparently it isn't reading 0xff. > > > 1) 0.108 us | tpm_tcg_read32(); > > This read is get_burstcount. > > > 1) 1.773 us | tpm_tcg_write_bytes(); > > 1) | wait_for_tpm_stat() { > > 1) | tpm_tis_status() { > > 1) 0.082 us | tpm_tcg_read_bytes(); > > 1) 5.011 us | } > > 1) 5.618 us | } > > 1) 0.077 us | tpm_tcg_read_bytes(); > > tpm_tis_status inlined? > > > 1) 0.090 us | tpm_tcg_write_bytes(); > > Come out of loop and write last byte > > > 1) | wait_for_tpm_stat() { > > 1) | tpm_tis_status() { > > 1) 0.080 us | tpm_tcg_read_bytes(); > > 1) 1.921 us | } > > 1) 2.376 us | } > > 1) 0.077 us | tpm_tcg_read_bytes(); > > inlined tpm_tis_status again? Here is where it sees data is still expected and errors out. > With that debugging patch at this point it was showing that the locality was not active. > Also didn't show that the tpm had been seized by another locality. > > > 1) 0.080 us | tpm_tcg_write_bytes(); > > tpm_tis_ready inlined? in out_err > > > 1) * 15970.97 us | } > > 1) * 15971.39 us | } > > 1) * 15971.81 us | } > > 1) | release_locality() { > > 1) 0.103 us | tpm_tcg_write_bytes(); > > 1) 0.535 us | } > > 1) * 16023.04 us | } > > 1) * 16023.35 us | } > > 1) * 16024.79 us | } > > 1) * 16067.18 us | } > > 1) * 16067.67 us | } > > 1) * 16068.10 us | } > > 1) * 16068.47 us | } > > 1) * 78448.69 us | } > > 1) * 78455.45 us | } > > 1) * 78456.71 us | } > > 1) 0.564 us | tpm_dev_release(); > > 0) | tpm_pcr_read() { > > 0) 0.225 us | tpm_chip_find_get(); > > 0) 0.734 us | } > > I wonder if it is possible that the release locality from the probe > isn't completing on the chip until after the request/check that > happens at the beginning of the tpm_get_timeouts. Perhaps we need > something like wait_for_tpm_stat for the access register, and > verifying that locality was released before returning out of > release_locality? > > Any thoughts? Sorry for late response. Would make sense if that is the root cause. For just testing the hypothesis (not something to be merged) adding a delay to release would probably make sense (like 200 ms delay to make sure that the TPM has done the state transition). /Jarkko ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [tpmdd-devel] tpm device not showing up in /dev anymore @ 2017-10-25 8:04 ` Laurent Bigonville 0 siblings, 0 replies; 62+ messages in thread From: Laurent Bigonville @ 2017-10-25 8:04 UTC (permalink / raw) To: Jarkko Sakkinen, Jerry Snitselaar Cc: Alexander.Steffen, tpmdd-devel, linux-integrity Le 24/10/17 a 15:51, Jarkko Sakkinen a ecrit : > On Mon, Oct 23, 2017 at 06:45:15AM -0700, Jerry Snitselaar wrote: >> On Mon Oct 23 17, Jarkko Sakkinen wrote: >>> On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote: >>>> Le 14/10/17 a 10:13, Jerry Snitselaar a ecrit : >>>>> On Wed Sep 06 17, Jarkko Sakkinen wrote: >>>>>> On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent Bigonville wrote: >>>>>>> Le 31/08/17 a 18:40, Jerry Snitselaar a ecrit : >>>>>>>> On Thu Aug 31 17, Alexander.Steffen@infineon.com wrote: >>>>>>>>>> Le 29/08/17 a 18:35, Laurent Bigonville a ecrit : >>>>>>>>>>> Le 29/08/17 a 18:00, Alexander.Steffen@infineon.com a ecrit : >>>>>>>>>>>>> An idea how to troubleshoot this? >>>>>>>>>>>> Can you run git bisect on the changes between 4.11 and >>>>>>> 4.12, so that >>>>>>>>>>>> we find the offending commit? It is probably sufficient >>>>>>> to limit the >>>>>>>>>>>> search to commits that touch something in drivers/char/tpm. >>>>>>>>>>> I'll try and keep you posted. >>>>>>>>>> OK I've been able to bisect the problem and the bad commit is: >>>>>>>>>> >>>>>>>>>> e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad commit >>>>>>>>>> commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >>>>>>>>>> Author: Jerry Snitselaar <jsnitsel@redhat.com> >>>>>>>>>> Date: Mon Mar 27 08:46:04 2017 -0700 >>>>>>>>>> >>>>>>>>>> tpm_tis: convert to using locality callbacks >>>>>>>>>> >>>>>>>>>> This patch converts tpm_tis to use of the new tpm class ops >>>>>>>>>> request_locality, and relinquish_locality. >>>>>>>>>> >>>>>>>>>> With the move to using the callbacks, release_locality is >>>>>>>>>> changed so >>>>>>>>>> that we now release the locality even if there is no >>>>>>>>>> request pending. >>>>>>>>>> >>>>>>>>>> This required some changes to the tpm_tis_core_init >>>>>>> code path to >>>>>>>>>> make sure locality is requested when needed: >>>>>>>>>> >>>>>>>>>> - tpm2_probe code path will end up calling >>>>>>>>>> request/release through >>>>>>>>>> callbacks, so request_locality prior to >>>>>>> tpm2_probe not needed. >>>>>>>>>> - probe_itpm makes calls to tpm_tis_send_data which no >>>>>>>>>> longer calls >>>>>>>>>> request_locality, so add request_locality prior to >>>>>>>>>> tpm_tis_send_data >>>>>>>>>> calls. Also drop release_locality call in middleof >>>>>>>>>> probe_itpm, and >>>>>>>>>> keep locality until release_locality called at end of >>>>>>>>>> probe_itpm. >>>>>>>>>> >>>>>>>>>> Cc: Peter Huewe <peterhuewe@gmx.de> >>>>>>>>>> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >>>>>>>>>> Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> >>>>>>>>>> Cc: Marcel Selhorst <tpmdd@selhorst.net> >>>>>>>>>> Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> >>>>>>>>>> Reviewed-by: Jarkko Sakkinen >>>>>>> <jarkko.sakkinen@linux.intel.com> >>>>>>>>>> Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >>>>>>>>>> Signed-off-by: Jarkko Sakkinen >>>>>>> <jarkko.sakkinen@linux.intel.com> >>>>>>>>>> :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >>>>>>>>>> 72f21b446e45ea1003de75902b0553deb99157fd M drivers >>>>>>>>>> >>>>>>>>> I've looked again at the code in question, but could not find >>>>>>>>> anything that is obviously wrong there. Locality is now >>>>>>>>> requested/released at slightly different points in the process than >>>>>>>>> before, but that's it. It does not seem to cause problems with the >>>>>>>>> majority of TPMs, since you are the first to report any, so >>>>>>> maybe it >>>>>>>>> is a quirk that only affects this device. >>>>>>>>> >>>>>>>>> Perhaps Jerry can help, since this is his change? >>>>>>>>> >>>>>>>>> Alexander >>>>>>>> Getting some caffeine in me, and starting to take a look. Adding >>>>>>>> Jarkko as well since this might involve the general locality changes. >>>>>>>> >>>>>>>> Laurent, if I send you a patch with some debugging code added, would >>>>>>>> you be able to run it on that system? I wasn't running into issues >>>>>>>> on the system I had with a 1.2 device, but I no longer have access >>>>>>>> to it. I'll see if I can find one in our labs and reproduce it there. >>>>>>> Yes I should be able to do that >>>>>> Any findings? >>>>>> >>>>>> /Jarkko >>>>> Okay, finally getting back to this. Looking at the code it isn't clear >>>>> to me >>>>> why the change is causing this. So while I stare at this some more >>>>> Laurent >>>>> could you reproduce it with this patch so I can see what the status and >>>>> access registers look like? Does anyone else on here happen to have a >>>>> Sinosun >>>>> tpm device? The systems I have access to with TPM1.2 devices don't have >>>>> this >>>>> issue. >>>>> >>>>> --8<-- >>>>> >>>>> diff --git a/drivers/char/tpm/tpm_tis_core.c >>>>> b/drivers/char/tpm/tpm_tis_core.c >>>>> index fdde971bc810..7d60a7e4b50a 100644 >>>>> --- a/drivers/char/tpm/tpm_tis_core.c >>>>> +++ b/drivers/char/tpm/tpm_tis_core.c >>>>> @@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >>>>> const u8 *buf, size_t len) >>>>> int rc, status, burstcnt; >>>>> size_t count = 0; >>>>> bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; >>>>> + u8 access; >>>>> >>>>> status = tpm_tis_status(chip); >>>>> if ((status & TPM_STS_COMMAND_READY) == 0) { >>>>> @@ -292,6 +293,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >>>>> const u8 *buf, size_t len) >>>>> } >>>>> status = tpm_tis_status(chip); >>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { >>>>> + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), >>>>> &access); >>>>> + if (rc < 0) >>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: read >>>>> failure TPM_ACCESS(%d)\n", priv->locality); >>>>> + else >>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: >>>>> locality: %d status: %x access: %x\n", priv->locality, status, access); >>>>> rc = -EIO; >>>>> goto out_err; >>>>> } >>>>> @@ -309,6 +315,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >>>>> const u8 *buf, size_t len) >>>>> } >>>>> status = tpm_tis_status(chip); >>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { >>>>> + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), &access); >>>>> + if (rc < 0) >>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read >>>>> failure TPM_ACCESS(%d)\n", priv->locality); >>>>> + else >>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: locality: >>>>> %d status: %x access: %x\n", priv->locality, status, access); >>>>> rc = -EIO; >>>>> goto out_err; >>>>> } >>>> Please find here the dmesg output of the patched kernel >>> At least 0xff is corrupted value in senseful way. CPU fills the read >>> with ones for example for unaligned bus read. See table 19 in PC client >>> spec. This can happen when you do unaligned read for example. >>> >>> Maybe TPM is unreachable i.e. powered off. Bit busy with stuff ATM but >>> would probably make sense to compare that 0x81 to table 18 in the same >>> spec. >>> >>> /Jarkko >> 0x81 is saying the access register status is valid, and the locality >> is not active. That first bit means A Dynamic OS has not been previously >> established on the platform. Normally we would see 0xa1, which would >> mean valid register status, and the locality is active. > I think the important thing to note here is that STS has bits set that > should never be set. So we can conclude that TPM might be either > > 1. Powered off > 2. In some transition state? MMhhhh It's actually possible that windows has blocked the chip after trying to enter automatically a wrong owner passphrase. But that doesn't explain device was showing up with previous kernel versions ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: tpm device not showing up in /dev anymore @ 2017-10-25 8:04 ` Laurent Bigonville 0 siblings, 0 replies; 62+ messages in thread From: Laurent Bigonville @ 2017-10-25 8:04 UTC (permalink / raw) To: Jarkko Sakkinen, Jerry Snitselaar Cc: linux-integrity-u79uwXL29TY76Z2rM5mHXA, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Le 24/10/17 à 15:51, Jarkko Sakkinen a écrit : > On Mon, Oct 23, 2017 at 06:45:15AM -0700, Jerry Snitselaar wrote: >> On Mon Oct 23 17, Jarkko Sakkinen wrote: >>> On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote: >>>> Le 14/10/17 à 10:13, Jerry Snitselaar a écrit : >>>>> On Wed Sep 06 17, Jarkko Sakkinen wrote: >>>>>> On Fri, Sep 01, 2017 at 02:10:18PM +0200, Laurent Bigonville wrote: >>>>>>> Le 31/08/17 à 18:40, Jerry Snitselaar a écrit : >>>>>>>> On Thu Aug 31 17, Alexander.Steffen@infineon.com wrote: >>>>>>>>>> Le 29/08/17 à 18:35, Laurent Bigonville a écrit : >>>>>>>>>>> Le 29/08/17 à 18:00, Alexander.Steffen@infineon.com a écrit : >>>>>>>>>>>>> An idea how to troubleshoot this? >>>>>>>>>>>> Can you run git bisect on the changes between 4.11 and >>>>>>> 4.12, so that >>>>>>>>>>>> we find the offending commit? It is probably sufficient >>>>>>> to limit the >>>>>>>>>>>> search to commits that touch something in drivers/char/tpm. >>>>>>>>>>> I'll try and keep you posted. >>>>>>>>>> OK I've been able to bisect the problem and the bad commit is: >>>>>>>>>> >>>>>>>>>> e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 is the first bad commit >>>>>>>>>> commit e6aef069b6e97790cb127d5eeb86ae9ff0b7b0e3 >>>>>>>>>> Author: Jerry Snitselaar <jsnitsel@redhat.com> >>>>>>>>>> Date: Mon Mar 27 08:46:04 2017 -0700 >>>>>>>>>> >>>>>>>>>> tpm_tis: convert to using locality callbacks >>>>>>>>>> >>>>>>>>>> This patch converts tpm_tis to use of the new tpm class ops >>>>>>>>>> request_locality, and relinquish_locality. >>>>>>>>>> >>>>>>>>>> With the move to using the callbacks, release_locality is >>>>>>>>>> changed so >>>>>>>>>> that we now release the locality even if there is no >>>>>>>>>> request pending. >>>>>>>>>> >>>>>>>>>> This required some changes to the tpm_tis_core_init >>>>>>> code path to >>>>>>>>>> make sure locality is requested when needed: >>>>>>>>>> >>>>>>>>>> - tpm2_probe code path will end up calling >>>>>>>>>> request/release through >>>>>>>>>> callbacks, so request_locality prior to >>>>>>> tpm2_probe not needed. >>>>>>>>>> - probe_itpm makes calls to tpm_tis_send_data which no >>>>>>>>>> longer calls >>>>>>>>>> request_locality, so add request_locality prior to >>>>>>>>>> tpm_tis_send_data >>>>>>>>>> calls. Also drop release_locality call in middleof >>>>>>>>>> probe_itpm, and >>>>>>>>>> keep locality until release_locality called at end of >>>>>>>>>> probe_itpm. >>>>>>>>>> >>>>>>>>>> Cc: Peter Huewe <peterhuewe@gmx.de> >>>>>>>>>> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >>>>>>>>>> Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> >>>>>>>>>> Cc: Marcel Selhorst <tpmdd@selhorst.net> >>>>>>>>>> Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> >>>>>>>>>> Reviewed-by: Jarkko Sakkinen >>>>>>> <jarkko.sakkinen@linux.intel.com> >>>>>>>>>> Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> >>>>>>>>>> Signed-off-by: Jarkko Sakkinen >>>>>>> <jarkko.sakkinen@linux.intel.com> >>>>>>>>>> :040000 040000 70234365da69959d47076ebb40c8d17f520c3e44 >>>>>>>>>> 72f21b446e45ea1003de75902b0553deb99157fd M drivers >>>>>>>>>> >>>>>>>>> I've looked again at the code in question, but could not find >>>>>>>>> anything that is obviously wrong there. Locality is now >>>>>>>>> requested/released at slightly different points in the process than >>>>>>>>> before, but that's it. It does not seem to cause problems with the >>>>>>>>> majority of TPMs, since you are the first to report any, so >>>>>>> maybe it >>>>>>>>> is a quirk that only affects this device. >>>>>>>>> >>>>>>>>> Perhaps Jerry can help, since this is his change? >>>>>>>>> >>>>>>>>> Alexander >>>>>>>> Getting some caffeine in me, and starting to take a look. Adding >>>>>>>> Jarkko as well since this might involve the general locality changes. >>>>>>>> >>>>>>>> Laurent, if I send you a patch with some debugging code added, would >>>>>>>> you be able to run it on that system? I wasn't running into issues >>>>>>>> on the system I had with a 1.2 device, but I no longer have access >>>>>>>> to it. I'll see if I can find one in our labs and reproduce it there. >>>>>>> Yes I should be able to do that >>>>>> Any findings? >>>>>> >>>>>> /Jarkko >>>>> Okay, finally getting back to this. Looking at the code it isn't clear >>>>> to me >>>>> why the change is causing this. So while I stare at this some more >>>>> Laurent >>>>> could you reproduce it with this patch so I can see what the status and >>>>> access registers look like? Does anyone else on here happen to have a >>>>> Sinosun >>>>> tpm device? The systems I have access to with TPM1.2 devices don't have >>>>> this >>>>> issue. >>>>> >>>>> --8<-- >>>>> >>>>> diff --git a/drivers/char/tpm/tpm_tis_core.c >>>>> b/drivers/char/tpm/tpm_tis_core.c >>>>> index fdde971bc810..7d60a7e4b50a 100644 >>>>> --- a/drivers/char/tpm/tpm_tis_core.c >>>>> +++ b/drivers/char/tpm/tpm_tis_core.c >>>>> @@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >>>>> const u8 *buf, size_t len) >>>>> int rc, status, burstcnt; >>>>> size_t count = 0; >>>>> bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND; >>>>> + u8 access; >>>>> >>>>> status = tpm_tis_status(chip); >>>>> if ((status & TPM_STS_COMMAND_READY) == 0) { >>>>> @@ -292,6 +293,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >>>>> const u8 *buf, size_t len) >>>>> } >>>>> status = tpm_tis_status(chip); >>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { >>>>> + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), >>>>> &access); >>>>> + if (rc < 0) >>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: read >>>>> failure TPM_ACCESS(%d)\n", priv->locality); >>>>> + else >>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT == 0: >>>>> locality: %d status: %x access: %x\n", priv->locality, status, access); >>>>> rc = -EIO; >>>>> goto out_err; >>>>> } >>>>> @@ -309,6 +315,11 @@ static int tpm_tis_send_data(struct tpm_chip *chip, >>>>> const u8 *buf, size_t len) >>>>> } >>>>> status = tpm_tis_status(chip); >>>>> if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) { >>>>> + rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), &access); >>>>> + if (rc < 0) >>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: read >>>>> failure TPM_ACCESS(%d)\n", priv->locality); >>>>> + else >>>>> + dev_info(&chip->dev, "TPM_STS_DATA_EXPECT != 0: locality: >>>>> %d status: %x access: %x\n", priv->locality, status, access); >>>>> rc = -EIO; >>>>> goto out_err; >>>>> } >>>> Please find here the dmesg output of the patched kernel >>> At least 0xff is corrupted value in senseful way. CPU fills the read >>> with ones for example for unaligned bus read. See table 19 in PC client >>> spec. This can happen when you do unaligned read for example. >>> >>> Maybe TPM is unreachable i.e. powered off. Bit busy with stuff ATM but >>> would probably make sense to compare that 0x81 to table 18 in the same >>> spec. >>> >>> /Jarkko >> 0x81 is saying the access register status is valid, and the locality >> is not active. That first bit means A Dynamic OS has not been previously >> established on the platform. Normally we would see 0xa1, which would >> mean valid register status, and the locality is active. > I think the important thing to note here is that STS has bits set that > should never be set. So we can conclude that TPM might be either > > 1. Powered off > 2. In some transition state? MMhhhh It's actually possible that windows has blocked the chip after trying to enter automatically a wrong owner passphrase. But that doesn't explain device was showing up with previous kernel versions ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ tpmdd-devel mailing list tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel ^ permalink raw reply [flat|nested] 62+ messages in thread
end of thread, other threads:[~2018-05-04 14:22 UTC | newest] Thread overview: 62+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-08-28 11:28 tpm device not showing up in /dev anymore Laurent Bigonville [not found] ` <f9526f55-df96-64fc-a4d6-877ce04e7156-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> 2017-08-29 16:00 ` Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w [not found] ` <dcad0104c46d4d5f88e642862bdb42c2-nFblLGNE8XKJSz+rYg/bSJowlv4uC7bZ@public.gmane.org> 2017-08-29 16:35 ` Laurent Bigonville [not found] ` <47c4300b-8701-79a6-1c58-3a5853f4c5e3-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> 2017-08-29 17:39 ` Peter Huewe 2017-08-29 18:55 ` Laurent Bigonville [not found] ` <595efb25-8d87-f39d-037f-9c9a98462339-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> 2017-08-31 12:10 ` Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w [not found] ` <857106e4bb864bb8a68b1381fffc8f50-nFblLGNE8XKJSz+rYg/bSJowlv4uC7bZ@public.gmane.org> 2017-08-31 16:40 ` Jerry Snitselaar 2017-09-01 12:10 ` Laurent Bigonville [not found] ` <0d9be244-ace0-030d-6ff9-c4e94c63b7e9-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> 2017-09-06 4:05 ` Jarkko Sakkinen 2017-10-14 8:13 ` [tpmdd-devel] " Jerry Snitselaar 2017-10-14 8:13 ` Jerry Snitselaar 2017-10-21 8:53 ` [tpmdd-devel] " Laurent Bigonville 2017-10-21 8:53 ` Laurent Bigonville 2017-10-23 13:23 ` [tpmdd-devel] " Jarkko Sakkinen 2017-10-23 13:23 ` Jarkko Sakkinen 2017-10-23 13:45 ` [tpmdd-devel] " Jerry Snitselaar 2017-10-23 13:45 ` Jerry Snitselaar 2017-10-23 13:48 ` [tpmdd-devel] " Laurent Bigonville 2017-10-23 13:48 ` Laurent Bigonville 2017-10-24 13:51 ` [tpmdd-devel] " Jarkko Sakkinen 2017-10-24 13:51 ` Jarkko Sakkinen 2017-10-24 14:57 ` [tpmdd-devel] " Jerry Snitselaar 2017-10-24 14:57 ` Jerry Snitselaar 2017-10-24 16:07 ` [tpmdd-devel] " Jarkko Sakkinen 2017-10-24 16:07 ` Jarkko Sakkinen 2017-11-09 0:04 ` [tpmdd-devel] " Laurent Bigonville 2017-11-09 0:04 ` Laurent Bigonville 2017-11-09 19:58 ` [tpmdd-devel] " Laurent Bigonville 2017-11-09 19:58 ` Laurent Bigonville 2017-11-09 23:50 ` [tpmdd-devel] " Jerry Snitselaar 2017-11-09 23:50 ` Jerry Snitselaar 2017-11-10 2:19 ` [tpmdd-devel] " Jerry Snitselaar 2017-11-10 2:19 ` Jerry Snitselaar 2017-11-10 0:28 ` [tpmdd-devel] " Jerry Snitselaar 2017-11-10 7:07 ` Jerry Snitselaar 2017-11-10 8:21 ` Laurent Bigonville 2017-11-10 20:53 ` Jerry Snitselaar 2017-11-11 15:45 ` Jason Gunthorpe 2017-11-11 19:12 ` Jerry Snitselaar 2017-11-11 19:46 ` Jason Gunthorpe 2017-11-11 20:31 ` Jerry Snitselaar 2017-11-14 0:26 ` Laurent Bigonville 2017-11-14 2:45 ` Jason Gunthorpe 2017-11-14 14:59 ` Jarkko Sakkinen 2017-11-14 15:17 ` James Bottomley 2017-11-17 13:16 ` Jarkko Sakkinen 2018-01-02 23:54 ` Laurent Bigonville 2018-01-03 0:33 ` Jerry Snitselaar 2018-01-05 19:01 ` Laurent Bigonville 2018-02-09 10:53 ` Laurent Bigonville 2018-02-14 11:44 ` Jarkko Sakkinen 2018-03-09 17:24 ` Laurent Bigonville 2018-03-15 16:24 ` Jarkko Sakkinen 2018-05-03 11:38 ` Laurent Bigonville 2018-05-03 17:43 ` Jerry Snitselaar 2018-05-04 8:20 ` Jarkko Sakkinen 2018-05-04 8:18 ` Jarkko Sakkinen 2018-05-04 14:22 ` Jerry Snitselaar 2017-11-14 14:55 ` Jarkko Sakkinen 2017-11-14 14:43 ` Jarkko Sakkinen 2017-10-25 8:04 ` Laurent Bigonville 2017-10-25 8:04 ` Laurent Bigonville
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.