[Swan-dev] lost art: using TPM for entropy

Andrew Cagney andrew.cagney at gmail.com
Fri Jul 20 19:20:04 UTC 2018


The place I normally notice a lack of entropy is at the start while
the keys are being created.  So during a test run would be new issue.

Have a look in the debug.log for an unresolved test.  Since it
contains all the boot messages you might be able to spot a pattern for
what is taking so long.


On Fri, 20 Jul 2018 at 11:36, D. Hugh Redelmeier <hugh at mimosa.com> wrote:
> I used to use an old machine for testing.  After a long hiatus, I'm
> trying again, with a fresh install of everything
> The processor is an Intel i5-2400 "Sandy Bridge".  This processor does not
> have the RDRAND feature.  You can test your own processor:
>         grep rdrand /proc/cpuinfo
> To get more entropy without RDRAND, I used to use the TPM feature of
> the computer.  I wrote it up here:
> <https://libreswan.org/wiki/Entropy_matters#using_TPM_entropy_on_Fedora_23>
> This does not work on Fedora 28.  The most obvious thing is that there
> no longer is a tpm-rng module in the kernel:
> Jul 19 22:39:14 localhost.localdomain systemd-modules-load[490]: Failed to find module 'tpm-rng'
> Consequently rngd fails.
> Jul 19 22:39:15 localhost.localdomain rngd[686]: Failed to init entropy source 1: TPM RNG Device
> Jul 19 22:39:15 localhost.localdomain rngd[686]: Failed to init entropy source 2: Intel RDRAND Instruction RNG
> Jul 19 22:39:15 localhost.localdomain rngd[686]: Enabling JITTER rng support
> I think that JITTER is a new user-space entropy gleaner.  I imagine
> that TPM RNG would still be beneficial.
> Does anyone know what the new way of using the TPM RNG?  Is there any
> documentation of this?  random(4) and random(7) don't help.
> This is intriguing but not actually helpful:
>         <https://lkml.org/lkml/2018/6/8/72>
> It suggests that the tpm driver does have a function "tpm_add_hwrng"
> but doesn't say how it might get invoked.
> Somewhere in here might be something useful:
>         [build at redbird libreswan]$ find /sys -name 'tpm*'
>         /sys/kernel/security/tpm0
>         find: ‘/sys/kernel/debug’: Permission denied
>         /sys/class/tpmrm
>         /sys/class/tpm
>         /sys/class/tpm/tpm0
>         /sys/devices/pnp0/00:04/tpm
>         /sys/devices/pnp0/00:04/tpm/tpm0
>         find: ‘/sys/fs/pstore’: Permission denied
>         find: ‘/sys/fs/bpf’: Permission denied
>         /sys/bus/platform/drivers/tpm_tis
>         /sys/bus/pnp/drivers/tpm_tis
>         /sys/bus/acpi/drivers/tpm_crb
>         /sys/module/tpm_tis
>         /sys/module/tpm_crb
>         /sys/module/tpm_tis_core
>         /sys/module/tpm
> Reading this code, I would have expected a tpm-rngd-%d
> <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/char/tpm/tpm-chip.c#n378>
> ================
> It is possible that the TPM is being used automatically.  But I have
> suspiciously many tests coming out "unresolved".  And the whole test
> run seems to be taking a long time.  For example, right now 399 of 746
> tests have been run and 231 are unresolved.
> My other test machine (with RDRAND hardware) gets more unresolved
> results than Andrew expects.  Sometimes 20 at the end of a whole run.
> I thought that the problem might be that it uses a hard disk.  So I
> put an SSD in the Sandy Bridge machine but unresolved gets a lot
> worse.
> ================
> I have not set
>         /etc/modules-load.d/virtio.conf
> as specified by
>         <https://libreswan.org/wiki/Test_Suite#ensure_that_the_host_has_enough_entropy>
> There's too little explanation for me to trust it.
> Perhaps that is my problem._______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev

More information about the Swan-dev mailing list