random number generator missing after upgrade

[Björn Persson]

Hello, I upgraded from Debian 11 to Debian 12, and my random number
generator disappeared.

When I boot vmlinuz-5.10.0-23-amd64, there are two hardware random
number generators available:

# cat /sys/class/misc/hw_random/rng_available
ccp-1-rng tpm-rng-0

ccp-1-rng is nonfunctional because AMD's "Cryptographic Coprocessor" is
too secretive to work with Coreboot, so I've been using tpm-rng-0.

When I boot vmlinuz-6.1.0-11-amd64, there is no tpm-rng-0. Only the
nonfunctional ccp-1-rng is available:

# cat /sys/class/misc/hw_random/rng_available
ccp-1-rng

The hardware is an APU2 from PC Engines with this TPM board:
https://www.pcengines.ch/tpm1a.htm
The actual TPM seems to be SLB 9665TT2.0 from Infineon, (although the
writing on the actual chip differs from Infineon's rendering):
https://www.infineon.com/cms/en/product/security-smart-card-solutions/optiga-embedded-security-solutions/optiga-tpm/slb-9665tt2.0/

The TPM seems to still exist as /dev/tpm0, but its random number
generator is somehow unavailable.

Rebooting to Linux 5.10 makes tpm-rng-0 reappear and provide seemingly
random numbers like it always did. That rules out a hardware problem.
It's some difference between the two kernels, but so far I haven't found
anything obvious in the Linux source code.

Is there anything that can be done, or is support for this random number
generator just gone from Linux 6.1?

Björn Persson

[Jeffrey Walton]

Maybe related to https://www.phoronix.com/news/Linux-Disables-RNG-AMD-fTPMs

Jeff

[Björn Persson]

Jeffrey Walton wrote:
> Maybe related to https://www.phoronix.com/news/Linux-Disables-RNG-AMD-fTPMs

Not likely. That article is about a firmware TPM that comes with newer
Ryzen processors. Older Ryzens supposedly don't have it. The processor
in my APU2 is a GX-412TC, not a Ryzen at all, and my TPM is a discrete
chip from Infineon. The change in question is supposed to disable the
random number generator only if the TPM lists AMD as its manufacturer.

Björn Persson

[Anders Andersson]

I agree that the patch looks ok, but I remember being hit by a kernel
change that inadvertently changed the behavior on other systems too
(ECC RAM background scrubbing), but nobody really noticed because it
was not in much use.

I suspect that the case of having an external TPM on an AMD system is
such an unusual case, and I couldn't trace exactly where that patch
checked the AMD string, so perhaps it's picking up the AMD string
earlier on, and decides to disable all TPM on the AMD system. At least
the timing of the problem and the patch is suspicious.

[Björn Persson]

I see the 6.1 branch contains the first attempt at working around the
stutter problem, which disables randomness only from certain known
broken firmware versions:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/char/tpm/tpm-chip.c?h=linux-6.1.y#n510

It's supposed to log a warning when it takes effect:
"AMD fTPM version 0x%llx causes system stutter; hwrng disabled\n"
That message does not appear in my logs.

The new workaround, which disables randomness from all AMD firmware TPUs
and doesn't log, can be in effect only if it has been backported to
Debian's kernel very recently. That does not seem to be the case, if
this is the right way to look for backports:
https://salsa.debian.org/kernel-team/linux/-/commits/bookworm/

I'll check what the manufacturer number is on my system, if I can
figure out how to get at it.

Björn Persson