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: 22+ 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:42 ` James Bottomley
2024-06-17 19:56 ` Stefan Berger
2024-06-17 20:05 ` James Bottomley
2024-06-17 20:17 ` Stefan Berger
2024-06-19 22:34 ` Stefan Berger
2024-06-28 15:00 ` Linux regression tracking (Thorsten Leemhuis)
2024-07-01 15:22 ` Jarkko Sakkinen
2024-07-01 18:29 ` Stefan Berger
2024-07-01 19:01 ` Jarkko Sakkinen
2024-07-01 19:14 ` Stefan Berger [this message]
2024-07-02 23:48 ` Jarkko Sakkinen
2024-07-02 23:57 ` Jarkko Sakkinen
2024-07-03 0:34 ` Jarkko Sakkinen
2024-07-03 0:48 ` Jarkko Sakkinen
2024-07-03 1:00 ` Jarkko Sakkinen
2024-07-01 14:53 ` Jarkko Sakkinen
2024-06-28 0:54 ` Michael Ellerman
2024-06-28 16:39 ` James Bottomley
2024-06-28 17:21 ` Stefan Berger
2024-07-02 0:19 ` Michael Ellerman
2024-07-01 14:52 ` Jarkko Sakkinen
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 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).