[PATCH] rng: tpm_rng: start TPM before reading random numbers

[Ilias Apalodimas]

On Wed, 10 Jun 2026 at 18:03, Begari, Padmarao <Padmarao.Begari at amd.com> wrote:
>
> AMD General
>
> Hi Ilias,
>
> > From: Ilias Apalodimas <ilias.apalodimas at linaro.org>
> > Sent: Tuesday, June 9, 2026 4:06 PM
> > To: Begari, Padmarao <Padmarao.Begari at amd.com>
> > Cc: u-boot at lists.denx.de; Simek, Michal <michal.simek at amd.com>; git (AMD-
> > Xilinx) <git at amd.com>; Sughosh Ganu <sughosh.ganu at arm.com>; Heinrich
> > Schuchardt <xypron.glpk at gmx.de>; Tom Rini <trini at konsulko.com>
> > Subject: Re: [PATCH] rng: tpm_rng: start TPM before reading random numbers
> >
> > Hi Padmarao
> >
> >
> > On Tue, 9 Jun 2026 at 13:10, Padmarao Begari <padmarao.begari at amd.com>
> > wrote:
> > >
> > > The tpm-rng driver calls tpm_get_random() without first ensuring the
> > > TPM device is opened and started. When systemd-boot or fdt_fixup_kaslr
> > > triggers an RNG read early in boot, the TPM2 device hasn't been
> > > initialized yet, causing the command to fail:
> >
> > Is systemd_boot called via EFI? If so the TPM should be up already.
>
> You're right, The EFI TCG2 protocol does start the TPM, but only when tcg2_platform_get_tpm2() returns a probed TPM2 device. That function iterates with for_each_tpm_device(), and the uclass iterator silently skips any device whose probe fails, returning -ENODEV. So, a failed probe means EFI never starts the TPM.

But if the TPM fails to start from there, why would it succeed when
called from a different subsystem?

>
> The failure (tpm-rng tpm-rng: dm_rng_read failed: -1) does not come from systemd-boot, it comes from U-Boot's own fdt_kaslrseed() call, which runs during bootefi/bootmgr setup before control is handed to the EFI app.
>
> > About fdt_fixup_kaslr(), why do you need this? We specifically clear the kaslr-seed
> > when booting via EFI and EFI_RNG is installed, since the kernel ignores it.
>
> Agree, referencing fdt_fixup_kaslr() in the commit message is a mistake,  I'll correct the commit message.

It's not only the commit message. I think initializing the TPM in
_read callback is the wrong place to fix it.  We need a probe callback
that will initialize the device, if we use it for it's RNG, even if we
have to initialize the entire TPM
(+ CC Simon)

Thanks
/Ilias

>
> Regards
> Padmarao
>
> >
> > Thanks
> > /Ilias
> > >
> > >   tpm-rng tpm-rng: dm_rng_read failed: -1
> > >
> > > Fix this by calling tpm_auto_start() on the parent TPM device before
> > > tpm_get_random(). This ensures the TPM is initialized before use.
> > >
> > > Fixes: e67ffb5aa5ab ("tpm: rng: Add driver model interface for TPM RNG
> > > device")
> > > Signed-off-by: Padmarao Begari <padmarao.begari at amd.com>
> > > ---
> > >  drivers/rng/tpm_rng.c | 10 +++++++++-
> > >  1 file changed, 9 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/rng/tpm_rng.c b/drivers/rng/tpm_rng.c index
> > > 1a5e9e2e4b4..374e0ac1ff8 100644
> > > --- a/drivers/rng/tpm_rng.c
> > > +++ b/drivers/rng/tpm_rng.c
> > > @@ -4,12 +4,20 @@
> > >   */
> > >
> > >  #include <dm.h>
> > > +#include <log.h>
> > >  #include <rng.h>
> > >  #include <tpm_api.h>
> > >
> > >  static int rng_tpm_random_read(struct udevice *dev, void *data,
> > > size_t count)  {
> > > -       return tpm_get_random(dev_get_parent(dev), data, count);
> > > +       struct udevice *tpm_dev = dev_get_parent(dev);
> > > +       u32 rc;
> > > +
> > > +       rc = tpm_auto_start(tpm_dev);
> > > +       if (rc)
> > > +               return log_msg_ret("start", -EIO);
> > > +
> > > +       return tpm_get_random(tpm_dev, data, count);
> > >  }
> > >
> > >  static const struct dm_rng_ops tpm_rng_ops = {
> > > --
> > > 2.34.1
> > >