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@xxxxxxxxxx/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
