* Debugging errors with Dell XPS 9560 TPM @ 2020-02-02 0:19 Alex Guzman 2020-02-14 18:32 ` Alex Guzman 0 siblings, 1 reply; 9+ messages in thread From: Alex Guzman @ 2020-02-02 0:19 UTC (permalink / raw) To: linux-integrity Hey there! I reported a bug on the bug tracker a bit ago but haven't seen any movement, so I figured I'd drop in here. My XPS 9560 has been having issues with its TPM, and all commands will fail with error 1 when operating on the TPM device. I managed to bisect it back to commit 4d6ebc4c4950595414722dfadd0b361f5a05d37e (tpm: fix invalid locking in NONBLOCKING mode) though it began failing with error 14 (bad address) at that point. I reported the bug at https://bugzilla.kernel.org/show_bug.cgi?id=206275 and attached some dmesg logs from boot there. Does anyone have any suggestions for additional debugging or such to figure out what's happening here? - Alex ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Debugging errors with Dell XPS 9560 TPM 2020-02-02 0:19 Debugging errors with Dell XPS 9560 TPM Alex Guzman @ 2020-02-14 18:32 ` Alex Guzman 2020-02-14 20:29 ` James Bottomley 0 siblings, 1 reply; 9+ messages in thread From: Alex Guzman @ 2020-02-14 18:32 UTC (permalink / raw) To: linux-integrity Looks like someone had a look on the bug tracker (https://bugzilla.kernel.org/show_bug.cgi?id=206275#c6) and they figure it's definitely a regression in the kernel and should be reverted or rectified. They advised me to come ping here once more. - Alex On Sat, Feb 1, 2020 at 4:19 PM Alex Guzman <alex@guzman.io> wrote: > > Hey there! I reported a bug on the bug tracker a bit ago but haven't > seen any movement, so I figured I'd drop in here. My XPS 9560 has been > having issues with its TPM, and all commands will fail with error 1 > when operating on the TPM device. I managed to bisect it back to > commit 4d6ebc4c4950595414722dfadd0b361f5a05d37e (tpm: fix invalid > locking in NONBLOCKING mode) though it began failing with error 14 > (bad address) at that point. > > I reported the bug at > https://bugzilla.kernel.org/show_bug.cgi?id=206275 and attached some > dmesg logs from boot there. Does anyone have any suggestions for > additional debugging or such to figure out what's happening here? > > - Alex ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Debugging errors with Dell XPS 9560 TPM 2020-02-14 18:32 ` Alex Guzman @ 2020-02-14 20:29 ` James Bottomley 2020-02-14 21:02 ` Jerry Snitselaar 0 siblings, 1 reply; 9+ messages in thread From: James Bottomley @ 2020-02-14 20:29 UTC (permalink / raw) To: Alex Guzman, linux-integrity On Fri, 2020-02-14 at 10:32 -0800, Alex Guzman wrote: > Looks like someone had a look on the bug tracker > (https://bugzilla.kernel.org/show_bug.cgi?id=206275#c6) > and they figure it's definitely a regression in the kernel and should > be reverted or rectified. They advised me to come ping here once > more. Reading the bugzilla, I don't get *what* needs to be reverted. The commit 4d6ebc4c4950595414722dfadd0b361f5a05d37e isn't present in upstream, so what kernel is it present in, or what is the full commit message so we can find the upstream commit? James > - Alex > > On Sat, Feb 1, 2020 at 4:19 PM Alex Guzman <alex@guzman.io> wrote: > > > > Hey there! I reported a bug on the bug tracker a bit ago but > > haven't > > seen any movement, so I figured I'd drop in here. My XPS 9560 has > > been > > having issues with its TPM, and all commands will fail with error 1 > > when operating on the TPM device. I managed to bisect it back to > > commit 4d6ebc4c4950595414722dfadd0b361f5a05d37e (tpm: fix invalid > > locking in NONBLOCKING mode) though it began failing with error 14 > > (bad address) at that point. > > > > I reported the bug at > > https://bugzilla.kernel.org/show_bug.cgi?id=206275 and attached > > some > > dmesg logs from boot there. Does anyone have any suggestions for > > additional debugging or such to figure out what's happening here? > > > > - Alex > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Debugging errors with Dell XPS 9560 TPM 2020-02-14 20:29 ` James Bottomley @ 2020-02-14 21:02 ` Jerry Snitselaar 2020-02-14 21:04 ` James Bottomley 0 siblings, 1 reply; 9+ messages in thread From: Jerry Snitselaar @ 2020-02-14 21:02 UTC (permalink / raw) To: James Bottomley; +Cc: Alex Guzman, linux-integrity On Fri Feb 14 20, James Bottomley wrote: >On Fri, 2020-02-14 at 10:32 -0800, Alex Guzman wrote: >> Looks like someone had a look on the bug tracker >> (https://bugzilla.kernel.org/show_bug.cgi?id=206275#c6) >> and they figure it's definitely a regression in the kernel and should >> be reverted or rectified. They advised me to come ping here once >> more. > >Reading the bugzilla, I don't get *what* needs to be reverted. The >commit 4d6ebc4c4950595414722dfadd0b361f5a05d37e isn't present in >upstream, so what kernel is it present in, or what is the full commit >message so we can find the upstream commit? > >James > > >> - Alex >> >> On Sat, Feb 1, 2020 at 4:19 PM Alex Guzman <alex@guzman.io> wrote: >> > >> > Hey there! I reported a bug on the bug tracker a bit ago but >> > haven't >> > seen any movement, so I figured I'd drop in here. My XPS 9560 has >> > been >> > having issues with its TPM, and all commands will fail with error 1 >> > when operating on the TPM device. I managed to bisect it back to >> > commit 4d6ebc4c4950595414722dfadd0b361f5a05d37e (tpm: fix invalid >> > locking in NONBLOCKING mode) though it began failing with error 14 >> > (bad address) at that point. >> > >> > I reported the bug at >> > https://bugzilla.kernel.org/show_bug.cgi?id=206275 and attached >> > some >> > dmesg logs from boot there. Does anyone have any suggestions for >> > additional debugging or such to figure out what's happening here? >> > >> > - Alex >> >> > d23d12484307 | 2019-12-17 | tpm: fix invalid locking in NONBLOCKING mode (Tadeusz Struk) There is a commit that is a fix to this commit: a430e67d9a2c | 2020-01-08 | tpm: Handle negative priv->response_len in tpm_common_read() (Tadeusz Struk) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Debugging errors with Dell XPS 9560 TPM 2020-02-14 21:02 ` Jerry Snitselaar @ 2020-02-14 21:04 ` James Bottomley 2020-02-15 1:47 ` Alex Guzman 0 siblings, 1 reply; 9+ messages in thread From: James Bottomley @ 2020-02-14 21:04 UTC (permalink / raw) To: Jerry Snitselaar; +Cc: Alex Guzman, linux-integrity On Fri, 2020-02-14 at 14:02 -0700, Jerry Snitselaar wrote: > On Fri Feb 14 20, James Bottomley wrote: > > On Fri, 2020-02-14 at 10:32 -0800, Alex Guzman wrote: > > > Looks like someone had a look on the bug tracker > > > (https://bugzilla.kernel.org/show_bug.cgi?id=206275#c6) > > > and they figure it's definitely a regression in the kernel and > > > should > > > be reverted or rectified. They advised me to come ping here once > > > more. > > > > Reading the bugzilla, I don't get *what* needs to be reverted. The > > commit 4d6ebc4c4950595414722dfadd0b361f5a05d37e isn't present in > > upstream, so what kernel is it present in, or what is the full > > commit message so we can find the upstream commit? > > > > James > > > > > > > - Alex > > > > > > On Sat, Feb 1, 2020 at 4:19 PM Alex Guzman <alex@guzman.io> > > > wrote: > > > > > > > > Hey there! I reported a bug on the bug tracker a bit ago but > > > > haven't seen any movement, so I figured I'd drop in here. My > > > > XPS 9560 has been having issues with its TPM, and all commands > > > > will fail with error 1 when operating on the TPM device. I > > > > managed to bisect it back to commit > > > > 4d6ebc4c4950595414722dfadd0b361f5a05d37e (tpm: fix > > > > invalid locking in NONBLOCKING mode) though it began failing > > > > with error 14 (bad address) at that point. > > > > > > > > I reported the bug at > > > > https://bugzilla.kernel.org/show_bug.cgi?id=206275 and attached > > > > some dmesg logs from boot there. Does anyone have any > > > > suggestions for additional debugging or such to figure out > > > > what's happening here? > > > > > > > > - Alex > > > > > > > > d23d12484307 | 2019-12-17 | tpm: fix invalid locking in NONBLOCKING > mode (Tadeusz Struk) > > There is a commit that is a fix to this commit: > > a430e67d9a2c | 2020-01-08 | tpm: Handle negative priv->response_len > in tpm_common_read() (Tadeusz Struk) Yes, I suspected it might be that ... in which case upstream should have the fix, can we verify that 5.6-rc1 works just fine? James ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Debugging errors with Dell XPS 9560 TPM 2020-02-14 21:04 ` James Bottomley @ 2020-02-15 1:47 ` Alex Guzman 2020-02-18 17:52 ` Tadeusz Struk 2020-02-18 17:52 ` Tadeusz Struk 0 siblings, 2 replies; 9+ messages in thread From: Alex Guzman @ 2020-02-15 1:47 UTC (permalink / raw) To: James Bottomley, Jerry Snitselaar; +Cc: linux-integrity On Fri, 2020-02-14 at 16:04 -0500, James Bottomley wrote: > On Fri, 2020-02-14 at 14:02 -0700, Jerry Snitselaar wrote: > > On Fri Feb 14 20, James Bottomley wrote: > > > On Fri, 2020-02-14 at 10:32 -0800, Alex Guzman wrote: > > > > Looks like someone had a look on the bug tracker > > > > (https://bugzilla.kernel.org/show_bug.cgi?id=206275#c6) > > > > and they figure it's definitely a regression in the kernel and > > > > should > > > > be reverted or rectified. They advised me to come ping here > > > > once > > > > more. > > > > > > Reading the bugzilla, I don't get *what* needs to be > > > reverted. The > > > commit 4d6ebc4c4950595414722dfadd0b361f5a05d37e isn't present in > > > upstream, so what kernel is it present in, or what is the full > > > commit message so we can find the upstream commit? > > > > > > James > > > > > > > > > > - Alex > > > > > > > > On Sat, Feb 1, 2020 at 4:19 PM Alex Guzman <alex@guzman.io> > > > > wrote: > > > > > Hey there! I reported a bug on the bug tracker a bit ago but > > > > > haven't seen any movement, so I figured I'd drop in here. My > > > > > XPS 9560 has been having issues with its TPM, and all > > > > > commands > > > > > will fail with error 1 when operating on the TPM device. I > > > > > managed to bisect it back to commit > > > > > 4d6ebc4c4950595414722dfadd0b361f5a05d37e (tpm: fix > > > > > invalid locking in NONBLOCKING mode) though it began failing > > > > > with error 14 (bad address) at that point. > > > > > > > > > > I reported the bug at > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=206275 and > > > > > attached > > > > > some dmesg logs from boot there. Does anyone have any > > > > > suggestions for additional debugging or such to figure out > > > > > what's happening here? > > > > > > > > > > - Alex > > > > d23d12484307 | 2019-12-17 | tpm: fix invalid locking in NONBLOCKING > > mode (Tadeusz Struk) > > > > There is a commit that is a fix to this commit: > > > > a430e67d9a2c | 2020-01-08 | tpm: Handle negative priv->response_len > > in tpm_common_read() (Tadeusz Struk) > > Yes, I suspected it might be that ... in which case upstream should > have the fix, can we verify that 5.6-rc1 works just fine? > > James > I just tested with 5.6_rc1. The behavior is still present: ERROR:tcti:src/tss2-tcti/tcti-device.c:290:tcti_device_receive() Failed to read response from fd 3, got errno 1: Operation not permitted ERROR:esys:src/tss2- esys/api/Esys_GetCapability.c:307:Esys_GetCapability_Finish() Received a non-TPM Error ERROR:esys:src/tss2- esys/api/Esys_GetCapability.c:107:Esys_GetCapability() Esys Finish ErrorCode (0x000a000a) ERROR: Esys_GetCapability(0xA000A) - tcti:IO failure ERROR: Unable to run tpm2_getcap ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Debugging errors with Dell XPS 9560 TPM 2020-02-15 1:47 ` Alex Guzman @ 2020-02-18 17:52 ` Tadeusz Struk 2020-02-19 20:32 ` Alex Guzman 2020-02-18 17:52 ` Tadeusz Struk 1 sibling, 1 reply; 9+ messages in thread From: Tadeusz Struk @ 2020-02-18 17:52 UTC (permalink / raw) To: Alex Guzman, James Bottomley, Jerry Snitselaar; +Cc: linux-integrity On 2/14/20 5:47 PM, Alex Guzman wrote: > I just tested with 5.6_rc1. The behavior is still present: > > > ERROR:tcti:src/tss2-tcti/tcti-device.c:290:tcti_device_receive() Failed > to read response from fd 3, got errno 1: Operation not permitted > ERROR:esys:src/tss2- > esys/api/Esys_GetCapability.c:307:Esys_GetCapability_Finish() Received > a non-TPM Error > ERROR:esys:src/tss2- > esys/api/Esys_GetCapability.c:107:Esys_GetCapability() Esys Finish > ErrorCode (0x000a000a) > ERROR: Esys_GetCapability(0xA000A) - tcti:IO failure > ERROR: Unable to run tpm2_getcap I tried to reproduce this, but I couldn't. Do you know what version of TSS are you using, and what is the configuration used to build it. Could you try to rebuild it with --enable-tcti-device-async=no and try that. Thanks, -- Tadeusz ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Debugging errors with Dell XPS 9560 TPM 2020-02-18 17:52 ` Tadeusz Struk @ 2020-02-19 20:32 ` Alex Guzman 0 siblings, 0 replies; 9+ messages in thread From: Alex Guzman @ 2020-02-19 20:32 UTC (permalink / raw) To: Tadeusz Struk; +Cc: James Bottomley, Jerry Snitselaar, linux-integrity My gentoo ebuild has these config flags set: --with-crypto="$(usex gcrypt gcrypt ossl)" \ --with-udevrulesdir="$(get_udevdir)/rules.d" \ --with-udevrulesprefix=60- --disable-defaultflags \ --disable-tcti-device-async So I'm already testing with async off as far as I can tell. I just updated to the latest commits of tpm2-tss and tpm2-tools (21c6bf9e75391a7033b74c517c88e336d2da4a9d and 711250043ee075a4ebef7c8ad2a22d23e542ca00 respectively) as well as updating to 5.6_rc2. Still the same result. On Tue, Feb 18, 2020 at 12:52 PM Tadeusz Struk <tadeusz.struk@intel.com> wrote: > > On 2/14/20 5:47 PM, Alex Guzman wrote: > > I just tested with 5.6_rc1. The behavior is still present: > > > > > > ERROR:tcti:src/tss2-tcti/tcti-device.c:290:tcti_device_receive() Failed > > to read response from fd 3, got errno 1: Operation not permitted > > ERROR:esys:src/tss2- > > esys/api/Esys_GetCapability.c:307:Esys_GetCapability_Finish() Received > > a non-TPM Error > > ERROR:esys:src/tss2- > > esys/api/Esys_GetCapability.c:107:Esys_GetCapability() Esys Finish > > ErrorCode (0x000a000a) > > ERROR: Esys_GetCapability(0xA000A) - tcti:IO failure > > ERROR: Unable to run tpm2_getcap > > I tried to reproduce this, but I couldn't. Do you know what version > of TSS are you using, and what is the configuration used to build it. > Could you try to rebuild it with --enable-tcti-device-async=no > and try that. > Thanks, > -- > Tadeusz ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Debugging errors with Dell XPS 9560 TPM 2020-02-15 1:47 ` Alex Guzman 2020-02-18 17:52 ` Tadeusz Struk @ 2020-02-18 17:52 ` Tadeusz Struk 1 sibling, 0 replies; 9+ messages in thread From: Tadeusz Struk @ 2020-02-18 17:52 UTC (permalink / raw) To: Alex Guzman, James Bottomley, Jerry Snitselaar; +Cc: linux-integrity On 2/14/20 5:47 PM, Alex Guzman wrote: > I just tested with 5.6_rc1. The behavior is still present: > > > ERROR:tcti:src/tss2-tcti/tcti-device.c:290:tcti_device_receive() Failed > to read response from fd 3, got errno 1: Operation not permitted > ERROR:esys:src/tss2- > esys/api/Esys_GetCapability.c:307:Esys_GetCapability_Finish() Received > a non-TPM Error > ERROR:esys:src/tss2- > esys/api/Esys_GetCapability.c:107:Esys_GetCapability() Esys Finish > ErrorCode (0x000a000a) > ERROR: Esys_GetCapability(0xA000A) - tcti:IO failure > ERROR: Unable to run tpm2_getcap I tried to reproduce this, but I couldn't. Do you know what version of TSS are you using, and what is the configuration used to build it. Could you try to rebuild it with --enable-tcti-device-async=no and try that. Thanks, -- Tadeusz ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-02-19 20:33 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-02-02 0:19 Debugging errors with Dell XPS 9560 TPM Alex Guzman 2020-02-14 18:32 ` Alex Guzman 2020-02-14 20:29 ` James Bottomley 2020-02-14 21:02 ` Jerry Snitselaar 2020-02-14 21:04 ` James Bottomley 2020-02-15 1:47 ` Alex Guzman 2020-02-18 17:52 ` Tadeusz Struk 2020-02-19 20:32 ` Alex Guzman 2020-02-18 17:52 ` Tadeusz Struk
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).