Mandos-Client Halts at Boot for 180 Sec

[Teddy Hogeborn]

Vigneshwaran K <vigneshwaran.k at vortexindia.co.in> writes:

> > > > > > On Fri, Jun 5, 2020 at 6:27 PM Dick Middleton <dick at fouter.net>
> > > > > > wrote:
> > > > > >
> > > > > > > > We are using a mandos client to unlock the crypt disk at
> > > > > > > > boot stage in that we are facing an issue.  For this
> > > > > > > > issue we need your help for further debugging and
> > > > > > > > resolution.
> > > > > > > > *
> > > > > > > > *
> > > > > > > > *The issue is:* It halts exactly at *"Initializing
> > > > > > > > GPGME"* for 3 minutes and then continues booting.
> > > > > > > >
> > > > > > > > *PS: *If any key press action happens within the
> > > > > > > > specified time it boots immediately.
> > > > > > >
> > > > > > > Maybe this the same issue as I had with low entropy?
> > > > > > >
> > > > > > > You can get a good idea of how long the wait for entropy
> > > > > > > is by doing:
> > > > > > >
> > > > > > >  journalctl | grep crng
> > > > > > >
> > > > > > > when you'll get something like this for each boot:
> > > > > > >
> > > > > > > Feb 13 12:01:19 penguin kernel: random: get_random_u64
> > > > > > > called from __kmem_cache_create+0x3e/0x520 with
> > > > > > > crng_init=0 Feb 13 12:01:26 penguin kernel: random: crng
> > > > > > > init done
> > > > > > >
> > > > > > > Subtract the times and ...
> > > > > > >
> > > > > > > If that is the answer then there are entropy generator
> > > > > > > programs or hardware devices you can use.
> > > > > > >
> > > > > > > I hope that helps
> > >
> > > FYR, I have attached the dmesg output file here.
> >
> > I would tend to agree with Dick Middleton, I think entropy is the
> > problem, and your dmesg log seems to confirm it:
> >
> > > [    0.000000] Linux version 4.19.0-5-686-pae (
> > debian-kernel at lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-7)) #1
> > SMP Debian 4.19.37-5 (2019-06-19)
> > …
> > > [    0.101780] random: get_random_bytes called from
> > start_kernel+0x81/0x45f with crng_init=0
> > …
> > > [   41.100495] random: fast init done
> > > [  204.211426] random: crng init done
> >
> > I suggest trying with Linux 5.4 or later, which contains a change
> > which makes the kernel create its own entropy much faster.  You can
> > read more about the early boot entropy problem here:
> >
> > https://wiki.debian.org/BoottimeEntropyStarvation
> >
> > Alternatively (if Linux 5.4 is for some reason not an acceptable
> > alternative for you) there are, like Dick Middleton suggested, also
> > hardware solutions which fixes this.  One example is ChaosKey:
> >
> > https://altusmetrum.org/ChaosKey/
> >
> > This hardware is supported by Linux 4.19 and will automatically be
> > used at boot if it is plugged into any USB port.
> 
>  - Thank you for your response. We tried Haveged, RNG tools, and
> jitter entropy tools and most available entropy generator tools in
> debian.  Unfortunately nothing works out for our problem. The problem
> is still persistent.

None of those will work, since they will start too late in the boot
process.  Hardware which has direct driver support in Linux, like
ChaosKey, works since it only requires the Linux driver, not a daemon,
and the driver is available early in the boot process.

>  - We can't use hardware entropy generators due to unavailability of
> port configurations. Is there any other way to increase the entropy at
> boot time?. We are stuck in this issue for the last 12 days. Any input
> from you will help us greatly.

I believe that the only option left to you is to use Linux 5.4 or later.

> PS: If we remove execute permission for mandos-client & update
> initramfs and then boot we don't have this issue.

Of course, but then you will be forced to enter the password manually
every boot.

/Teddy Hogeborn

-- 
The Mandos Project
https://www.recompile.se/mandos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://mail.recompile.se/pipermail/mandos-dev/attachments/20200619/17c2af31/attachment.sig>