From: Stefan Berger <stefanb@linux.ibm.com>
To: Jarkko Sakkinen <jarkko.sakkinen@iki.fi>,
Jarkko Sakkinen <jarkko@kernel.org>,
Linux regressions mailing list <regressions@lists.linux.dev>
Cc: naveen.n.rao@linux.ibm.com, linux-kernel@vger.kernel.org,
linux-integrity@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] tpm: ibmvtpm: Call tpm2_sessions_init() to initialize session support
Date: Mon, 1 Jul 2024 15:14:43 -0400 [thread overview]
Message-ID: <e7db74a0-cd5c-4394-b87e-c31ea0861ea1@linux.ibm.com> (raw)
In-Reply-To: <D2EFNJTR80JS.1RW91OVY1UH1N@iki.fi>
On 7/1/24 15:01, Jarkko Sakkinen wrote:
> On Mon Jul 1, 2024 at 6:29 PM UTC, Stefan Berger wrote:
>>
>>
>> On 7/1/24 11:22, Jarkko Sakkinen wrote:
>>> On Fri, 2024-06-28 at 17:00 +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
>>>> [CCing the regression list]
>>>>
>>>> On 20.06.24 00:34, Stefan Berger wrote:
>>>>> Jarkko,
>>>>> are you ok with this patch?
>>>>
>>>> Hmmm, hope I did not miss anythng, but looks like nothing happened for
>>>> about 10 days here. Hence:
>>>>
>>>> Jarkko, looks like some feedback from your side really would help to
>>>> find a path to get this regression resolved before 6.10 is released.
>>>>
>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>>>
>>> Sorry for latency, and except a bit more slow phase also during
>>> July because I'm most of this month on Holiday, except taking care
>>> 6.11 release.
>>>
>>> This really is a bug in the HMAC code not in the IBM driver as
>>> it should not break because of a new feature, i.e. this is only
>>> correct conclusions, give the "no regressions" rule.
>>>
>>> Since HMAC is by default only for x86_64 and it does not break
>>> defconfig's, we should take time and fix the actual issue.
>>
>> It was enabled it on my ppc64 system after a git pull -- at least I did
>> not enable it explicitly. Besides that others can enable it on any arch
>> unless you now change the 'default x86_64' to a 'depends x86_64' iiuc
>> otherwise the usage of a Fixes: , as I used in my patch, would be justified.
>>
>> config TCG_TPM2_HMAC
>> bool "Use HMAC and encrypted transactions on the TPM bus"
>> default X86_64
>> select CRYPTO_ECDH
>> select CRYPTO_LIB_AESCFB
>> select CRYPTO_LIB_SHA256
>>
>> https://elixir.bootlin.com/linux/v6.10-rc6/source/drivers/char/tpm/Kconfig
>
> Yep, it is still a bug, and unmodified IBM vtpm driver must be expected
> to work. I was merely saying that there is some window to fix it properly
> instead of duct tape since it is not yet widely enable feature.
>
> I was shocked to see that the implementation has absolutely no checks
> whether chip->auth was allocated. I mean anything that would cause
> tpm2_sessions_init() not called could trigger null dereference.
>
> So can you test this and see how your test hardware behaves:
I just tested it and it does NOT resolve the issue on my ppc64 machine.
I see this here:
[ 1.549798] tpm_ibmvtpm 5000: CRQ initialized
[ 1.549871] tpm_ibmvtpm 5000: CRQ initialization completed
[ 2.569446] tpm2_start_auth_session: encryption is not active
[ 2.570544] tpm tpm0: A TPM error (154) occurred attempting get random
....
[ 330.188826] tpm tpm0: A TPM error (149) occurred attempting extend a
PCR value
[ 330.189438] ima: Error Communicating to TPM chip, result: 149
[ 330.195007] tpm tpm0: A TPM error (149) occurred attempting extend a
PCR value
[ 330.195550] ima: Error Communicating to TPM chip, result: 149
[ 330.197246] tpm tpm0: A TPM error (149) occurred attempting extend a
PCR value
[ 330.197727] ima: Error Communicating to TPM chip, result: 149
[ 330.199378] tpm tpm0: A TPM error (149) occurred attempting extend a
PCR value
[ 330.199962] ima: Error Communicating to TPM chip, result: 149
[ 330.201452] tpm tpm0: A TPM error (149) occurred attempting extend a
PCR value
[ 330.201917] ima: Error Communicating to TPM chip, result: 149
My 4-liner patch, applied on top of it, does resolve the issue:
[ 1.462079] tpm_ibmvtpm 5000: CRQ initialized
[ 1.462125] tpm_ibmvtpm 5000: CRQ initialization completed
[ 2.496024] xhci_hcd 0000:00:02.0: xHCI Host Controller
[ 2.496183] xhci_hcd 0000:00:02.0: new USB bus registered, assigned
bus number 1
Applying it is probably the better path forward than restricting HMAC to
x86_64 now and enabling it on a per-architecture basis afterwards ...
Stefan
>
> https://lore.kernel.org/linux-integrity/20240701170735.109583-1-jarkko@kernel.org/T/#u
>
> I'll modify it accrodingly if problems persist. Please put your feedback
> over there. I cannot anything but compile test so it could be that
> I've ignored something.
>
> BR, Jarkko
WARNING: multiple messages have this Message-ID (diff)
From: Stefan Berger <stefanb@linux.ibm.com>
To: Jarkko Sakkinen <jarkko.sakkinen@iki.fi>,
Jarkko Sakkinen <jarkko@kernel.org>,
Linux regressions mailing list <regressions@lists.linux.dev>
Cc: naveen.n.rao@linux.ibm.com, linux-integrity@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] tpm: ibmvtpm: Call tpm2_sessions_init() to initialize session support
Date: Mon, 1 Jul 2024 15:14:43 -0400 [thread overview]
Message-ID: <e7db74a0-cd5c-4394-b87e-c31ea0861ea1@linux.ibm.com> (raw)
In-Reply-To: <D2EFNJTR80JS.1RW91OVY1UH1N@iki.fi>
On 7/1/24 15:01, Jarkko Sakkinen wrote:
> On Mon Jul 1, 2024 at 6:29 PM UTC, Stefan Berger wrote:
>>
>>
>> On 7/1/24 11:22, Jarkko Sakkinen wrote:
>>> On Fri, 2024-06-28 at 17:00 +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
>>>> [CCing the regression list]
>>>>
>>>> On 20.06.24 00:34, Stefan Berger wrote:
>>>>> Jarkko,
>>>>> are you ok with this patch?
>>>>
>>>> Hmmm, hope I did not miss anythng, but looks like nothing happened for
>>>> about 10 days here. Hence:
>>>>
>>>> Jarkko, looks like some feedback from your side really would help to
>>>> find a path to get this regression resolved before 6.10 is released.
>>>>
>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>>>
>>> Sorry for latency, and except a bit more slow phase also during
>>> July because I'm most of this month on Holiday, except taking care
>>> 6.11 release.
>>>
>>> This really is a bug in the HMAC code not in the IBM driver as
>>> it should not break because of a new feature, i.e. this is only
>>> correct conclusions, give the "no regressions" rule.
>>>
>>> Since HMAC is by default only for x86_64 and it does not break
>>> defconfig's, we should take time and fix the actual issue.
>>
>> It was enabled it on my ppc64 system after a git pull -- at least I did
>> not enable it explicitly. Besides that others can enable it on any arch
>> unless you now change the 'default x86_64' to a 'depends x86_64' iiuc
>> otherwise the usage of a Fixes: , as I used in my patch, would be justified.
>>
>> config TCG_TPM2_HMAC
>> bool "Use HMAC and encrypted transactions on the TPM bus"
>> default X86_64
>> select CRYPTO_ECDH
>> select CRYPTO_LIB_AESCFB
>> select CRYPTO_LIB_SHA256
>>
>> https://elixir.bootlin.com/linux/v6.10-rc6/source/drivers/char/tpm/Kconfig
>
> Yep, it is still a bug, and unmodified IBM vtpm driver must be expected
> to work. I was merely saying that there is some window to fix it properly
> instead of duct tape since it is not yet widely enable feature.
>
> I was shocked to see that the implementation has absolutely no checks
> whether chip->auth was allocated. I mean anything that would cause
> tpm2_sessions_init() not called could trigger null dereference.
>
> So can you test this and see how your test hardware behaves:
I just tested it and it does NOT resolve the issue on my ppc64 machine.
I see this here:
[ 1.549798] tpm_ibmvtpm 5000: CRQ initialized
[ 1.549871] tpm_ibmvtpm 5000: CRQ initialization completed
[ 2.569446] tpm2_start_auth_session: encryption is not active
[ 2.570544] tpm tpm0: A TPM error (154) occurred attempting get random
....
[ 330.188826] tpm tpm0: A TPM error (149) occurred attempting extend a
PCR value
[ 330.189438] ima: Error Communicating to TPM chip, result: 149
[ 330.195007] tpm tpm0: A TPM error (149) occurred attempting extend a
PCR value
[ 330.195550] ima: Error Communicating to TPM chip, result: 149
[ 330.197246] tpm tpm0: A TPM error (149) occurred attempting extend a
PCR value
[ 330.197727] ima: Error Communicating to TPM chip, result: 149
[ 330.199378] tpm tpm0: A TPM error (149) occurred attempting extend a
PCR value
[ 330.199962] ima: Error Communicating to TPM chip, result: 149
[ 330.201452] tpm tpm0: A TPM error (149) occurred attempting extend a
PCR value
[ 330.201917] ima: Error Communicating to TPM chip, result: 149
My 4-liner patch, applied on top of it, does resolve the issue:
[ 1.462079] tpm_ibmvtpm 5000: CRQ initialized
[ 1.462125] tpm_ibmvtpm 5000: CRQ initialization completed
[ 2.496024] xhci_hcd 0000:00:02.0: xHCI Host Controller
[ 2.496183] xhci_hcd 0000:00:02.0: new USB bus registered, assigned
bus number 1
Applying it is probably the better path forward than restricting HMAC to
x86_64 now and enabling it on a per-architecture basis afterwards ...
Stefan
>
> https://lore.kernel.org/linux-integrity/20240701170735.109583-1-jarkko@kernel.org/T/#u
>
> I'll modify it accrodingly if problems persist. Please put your feedback
> over there. I cannot anything but compile test so it could be that
> I've ignored something.
>
> BR, Jarkko
next prev parent reply other threads:[~2024-07-01 19:15 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-17 19:34 [PATCH] tpm: ibmvtpm: Call tpm2_sessions_init() to initialize session support Stefan Berger
2024-06-17 19:34 ` Stefan Berger
2024-06-17 19:42 ` James Bottomley
2024-06-17 19:42 ` James Bottomley
2024-06-17 19:56 ` Stefan Berger
2024-06-17 19:56 ` Stefan Berger
2024-06-17 20:05 ` James Bottomley
2024-06-17 20:05 ` James Bottomley
2024-06-17 20:17 ` Stefan Berger
2024-06-17 20:17 ` Stefan Berger
2024-06-19 22:34 ` Stefan Berger
2024-06-19 22:34 ` Stefan Berger
2024-06-28 15:00 ` Linux regression tracking (Thorsten Leemhuis)
2024-06-28 15:00 ` Linux regression tracking (Thorsten Leemhuis)
2024-07-01 15:22 ` Jarkko Sakkinen
2024-07-01 15:22 ` Jarkko Sakkinen
2024-07-01 18:29 ` Stefan Berger
2024-07-01 18:29 ` Stefan Berger
2024-07-01 19:01 ` Jarkko Sakkinen
2024-07-01 19:01 ` Jarkko Sakkinen
2024-07-01 19:14 ` Stefan Berger [this message]
2024-07-01 19:14 ` Stefan Berger
2024-07-02 23:48 ` Jarkko Sakkinen
2024-07-02 23:48 ` Jarkko Sakkinen
2024-07-02 23:57 ` Jarkko Sakkinen
2024-07-02 23:57 ` Jarkko Sakkinen
2024-07-03 0:34 ` Jarkko Sakkinen
2024-07-03 0:34 ` Jarkko Sakkinen
2024-07-03 0:48 ` Jarkko Sakkinen
2024-07-03 0:48 ` Jarkko Sakkinen
2024-07-03 1:00 ` Jarkko Sakkinen
2024-07-03 1:00 ` Jarkko Sakkinen
2024-07-01 14:53 ` Jarkko Sakkinen
2024-07-01 14:53 ` Jarkko Sakkinen
2024-06-28 0:54 ` Michael Ellerman
2024-06-28 0:54 ` Michael Ellerman
2024-06-28 16:39 ` James Bottomley
2024-06-28 16:39 ` James Bottomley
2024-06-28 17:21 ` Stefan Berger
2024-06-28 17:21 ` Stefan Berger
2024-07-02 0:19 ` Michael Ellerman
2024-07-02 0:19 ` Michael Ellerman
2024-07-01 14:52 ` Jarkko Sakkinen
2024-07-01 14:52 ` Jarkko Sakkinen
-- strict thread matches above, loose matches on Subject: below --
2024-08-29 13:47 Qianqiang Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e7db74a0-cd5c-4394-b87e-c31ea0861ea1@linux.ibm.com \
--to=stefanb@linux.ibm.com \
--cc=jarkko.sakkinen@iki.fi \
--cc=jarkko@kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=naveen.n.rao@linux.ibm.com \
--cc=regressions@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.