diff mbox series

[v2,1/2] package/haveged: Change service file to run early

Message ID 20200609224116.13607-2-nolange79@gmail.com
State New
Headers show
Series [v2,1/2] package/haveged: Change service file to run early | expand

Commit Message

Norbert Lange June 9, 2020, 10:41 p.m. UTC
Drop default dependencies, haveged needs nothing but
local sockets and /dev/random.

The service file now mostly matches the upstream fedora file,
except alot of isolation options have been dropped.
The benefit for a completely controlled system is small,
and those option would pull in dependencies, delaying
entropy being filled up.

Signed-off-by: Norbert Lange <nolange79@gmail.com>
---
 package/haveged/haveged.service | 22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

Comments

Norbert Lange June 25, 2020, 10:39 p.m. UTC | #1
Jeremy,

Can you have a look and add your reviewed-by pls?
No drastic changes from v1, except adding a few isolation options from
the upstream fedora service file.

Am Mi., 10. Juni 2020 um 00:42 Uhr schrieb Norbert Lange <nolange79@gmail.com>:
>
> Drop default dependencies, haveged needs nothing but
> local sockets and /dev/random.
>
> The service file now mostly matches the upstream fedora file,
> except alot of isolation options have been dropped.
> The benefit for a completely controlled system is small,
> and those option would pull in dependencies, delaying
> entropy being filled up.
>
> Signed-off-by: Norbert Lange <nolange79@gmail.com>
> ---
>  package/haveged/haveged.service | 22 +++++++++++++++++-----
>  1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/package/haveged/haveged.service b/package/haveged/haveged.service
> index 91035c6711..cfdaa93a37 100644
> --- a/package/haveged/haveged.service
> +++ b/package/haveged/haveged.service
> @@ -1,10 +1,22 @@
>  [Unit]
> -Description=Entropy Harvesting Daemon
> -Documentation=man:haveged(8)
> +# inspiration from upstream init.d/service.fedora
> +Description=Entropy Daemon based on the HAVEGE algorithm
> +Documentation=man:haveged(8) http://www.issihosts.com/haveged/
> +DefaultDependencies=no
> +# This would wait for filesystems, but we only need /dev/random,
> +# which is certainly available after systemd initialised
> +# After=systemd-tmpfiles-setup-dev.service
> +Before=sysinit.target shutdown.target systemd-journald.service
>
>  [Service]
> -ExecStart=/usr/sbin/haveged -F -w 1024 -v 1
> -SuccessExitStatus=143
> +ExecStart=/usr/sbin/haveged -w 1024 -v 1 --Foreground
> +Restart=always
> +SuccessExitStatus=137 143
> +
> +# Only simple isolation methods that dont pull in dependencies
> +CapabilityBoundingSet=CAP_SYS_ADMIN
> +SecureBits=noroot-locked
> +ProtectSystem=full
>
>  [Install]
> -WantedBy=multi-user.target
> +WantedBy=sysinit.target
> --
> 2.26.2
>
Jérémy ROSEN June 29, 2020, 7:31 a.m. UTC | #2
Well
I still think you need Before=systemd-random-seed.service and I don't
understand why you are reluctant to add it.
(Honestly, I think the Before= and your work to make it an early boot
service should be upstreamed)

So, i'm a bit reluctant to give my reviewed-by. Again, it's not worse than
it was, but if you want
to make sure that all services that need randomness are correctly started
after haveged, then
you have to add that Before=

I won't block the patch going in if a BR maintainer want to commit it, but
i'd like to understand why you are reluctant
to add that

Regards
Jeremy

Le ven. 26 juin 2020 à 00:39, Norbert Lange <nolange79@gmail.com> a écrit :

> Jeremy,
>
> Can you have a look and add your reviewed-by pls?
> No drastic changes from v1, except adding a few isolation options from
> the upstream fedora service file.
>
> Am Mi., 10. Juni 2020 um 00:42 Uhr schrieb Norbert Lange <
> nolange79@gmail.com>:
> >
> > Drop default dependencies, haveged needs nothing but
> > local sockets and /dev/random.
> >
> > The service file now mostly matches the upstream fedora file,
> > except alot of isolation options have been dropped.
> > The benefit for a completely controlled system is small,
> > and those option would pull in dependencies, delaying
> > entropy being filled up.
> >
> > Signed-off-by: Norbert Lange <nolange79@gmail.com>
> > ---
> >  package/haveged/haveged.service | 22 +++++++++++++++++-----
> >  1 file changed, 17 insertions(+), 5 deletions(-)
> >
> > diff --git a/package/haveged/haveged.service
> b/package/haveged/haveged.service
> > index 91035c6711..cfdaa93a37 100644
> > --- a/package/haveged/haveged.service
> > +++ b/package/haveged/haveged.service
> > @@ -1,10 +1,22 @@
> >  [Unit]
> > -Description=Entropy Harvesting Daemon
> > -Documentation=man:haveged(8)
> > +# inspiration from upstream init.d/service.fedora
> > +Description=Entropy Daemon based on the HAVEGE algorithm
> > +Documentation=man:haveged(8) http://www.issihosts.com/haveged/
> > +DefaultDependencies=no
> > +# This would wait for filesystems, but we only need /dev/random,
> > +# which is certainly available after systemd initialised
> > +# After=systemd-tmpfiles-setup-dev.service
> > +Before=sysinit.target shutdown.target systemd-journald.service
> >
> >  [Service]
> > -ExecStart=/usr/sbin/haveged -F -w 1024 -v 1
> > -SuccessExitStatus=143
> > +ExecStart=/usr/sbin/haveged -w 1024 -v 1 --Foreground
> > +Restart=always
> > +SuccessExitStatus=137 143
> > +
> > +# Only simple isolation methods that dont pull in dependencies
> > +CapabilityBoundingSet=CAP_SYS_ADMIN
> > +SecureBits=noroot-locked
> > +ProtectSystem=full
> >
> >  [Install]
> > -WantedBy=multi-user.target
> > +WantedBy=sysinit.target
> > --
> > 2.26.2
> >
>
Norbert Lange June 29, 2020, 8:29 a.m. UTC | #3
Am Mo., 29. Juni 2020 um 09:31 Uhr schrieb Jérémy ROSEN <
jeremy.rosen@smile.fr>:

> Well
> I still think you need Before=systemd-random-seed.service and I don't
> understand why you are reluctant to add it.
> (Honestly, I think the Before= and your work to make it an early boot
> service should be upstreamed)
>
> So, i'm a bit reluctant to give my reviewed-by. Again, it's not worse than
> it was, but if you want
> to make sure that all services that need randomness are correctly started
> after haveged, then
> you have to add that Before=
>

Again, this doesn't help, and might actually hurt.

-   systemd-random-seed.service could actually add better (real) entropy.
     (Upstream actually had an After systemd-random-seed.service for that
reason).
-   a before on a "persistent" service does not really block, while
accessing the kernels random source when it's not uninitialised will,
    so random consumers are already implicitly waiting for haveged - when
they need entropy and not a moment before.


> I won't block the patch going in if a BR maintainer want to commit it, but
> i'd like to understand why you are reluctant
> to add that
>

Haveged is not entropy, it's a substitute. I dont know how many times I
need to point that out.
The less dependencies, the faster the system can startup (and lesser
chances of some stoopid deadlocks).

Look at the history for service.fedora [1], which is now the blueprint for
the v2 patch,
I considered just adding a switch to install the upstream service file,
but this adds several heavy isolation options that are overkill for most
uses,
and add dependencies (upstream just removed one of these, because it
created a cycle).

[1] -
https://github.com/jirka-h/haveged/commits/master/init.d/service.fedora

Norbert


> Regards
> Jeremy
>
> Le ven. 26 juin 2020 à 00:39, Norbert Lange <nolange79@gmail.com> a
> écrit :
>
>> Jeremy,
>>
>> Can you have a look and add your reviewed-by pls?
>> No drastic changes from v1, except adding a few isolation options from
>> the upstream fedora service file.
>>
>> Am Mi., 10. Juni 2020 um 00:42 Uhr schrieb Norbert Lange <
>> nolange79@gmail.com>:
>> >
>> > Drop default dependencies, haveged needs nothing but
>> > local sockets and /dev/random.
>> >
>> > The service file now mostly matches the upstream fedora file,
>> > except alot of isolation options have been dropped.
>> > The benefit for a completely controlled system is small,
>> > and those option would pull in dependencies, delaying
>> > entropy being filled up.
>> >
>> > Signed-off-by: Norbert Lange <nolange79@gmail.com>
>> > ---
>> >  package/haveged/haveged.service | 22 +++++++++++++++++-----
>> >  1 file changed, 17 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/package/haveged/haveged.service
>> b/package/haveged/haveged.service
>> > index 91035c6711..cfdaa93a37 100644
>> > --- a/package/haveged/haveged.service
>> > +++ b/package/haveged/haveged.service
>> > @@ -1,10 +1,22 @@
>> >  [Unit]
>> > -Description=Entropy Harvesting Daemon
>> > -Documentation=man:haveged(8)
>> > +# inspiration from upstream init.d/service.fedora
>> > +Description=Entropy Daemon based on the HAVEGE algorithm
>> > +Documentation=man:haveged(8) http://www.issihosts.com/haveged/
>> > +DefaultDependencies=no
>> > +# This would wait for filesystems, but we only need /dev/random,
>> > +# which is certainly available after systemd initialised
>> > +# After=systemd-tmpfiles-setup-dev.service
>> > +Before=sysinit.target shutdown.target systemd-journald.service
>> >
>> >  [Service]
>> > -ExecStart=/usr/sbin/haveged -F -w 1024 -v 1
>> > -SuccessExitStatus=143
>> > +ExecStart=/usr/sbin/haveged -w 1024 -v 1 --Foreground
>> > +Restart=always
>> > +SuccessExitStatus=137 143
>> > +
>> > +# Only simple isolation methods that dont pull in dependencies
>> > +CapabilityBoundingSet=CAP_SYS_ADMIN
>> > +SecureBits=noroot-locked
>> > +ProtectSystem=full
>> >
>> >  [Install]
>> > -WantedBy=multi-user.target
>> > +WantedBy=sysinit.target
>> > --
>> > 2.26.2
>> >
>>
>
>
> --
> [image: SMILE]  <http://www.smile.eu/>
>
> 20 rue des Jardins
> 92600 Asnières-sur-Seine
> *Jérémy ROSEN*
> Architecte technique
>
> [image: email] jeremy.rosen@smile.fr
> [image: phone]  +33 6 88 25 87 42
> [image: url] http://www.smile.eu
>
> [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook]
> <https://www.facebook.com/smileopensource> [image: LinkedIn]
> <https://www.linkedin.com/company/smile> [image: Github]
> <https://github.com/Smile-SA>
>
> [image: Découvrez l’univers Smile, rendez-vous sur smile.eu]
> <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
>
Alexander Dahl June 29, 2020, 9:30 a.m. UTC | #4
Hei hei,

On Mon, Jun 29, 2020 at 10:29:38AM +0200, Norbert Lange wrote:
> Haveged is not entropy, it's a substitute. I dont know how many times I
> need to point that out.

As far as I understood the source for the entropy haveged collects is
random timing jitter from the CPU. Could you explain, why that is not
real entropy, although it passes the FIPS tests? Or point to an
explanation to learn from?

> The less dependencies, the faster the system can startup (and lesser
> chances of some stoopid deadlocks).

This might be true in general, but it is not necessarily on embedded
systems waiting for the kernel's crng to be initialized. If that
initialization is a requirement and the system has very few entropy
sources only (think of an embedded device with no network initialized,
no HID, no sensors, …) the boot can actually hours or days, seriously.

Greets
Alex
Norbert Lange June 29, 2020, 9:55 a.m. UTC | #5
Am Mo., 29. Juni 2020 um 11:30 Uhr schrieb Alexander Dahl <post@lespocky.de>:
>
> Hei hei,
>
> On Mon, Jun 29, 2020 at 10:29:38AM +0200, Norbert Lange wrote:
> > Haveged is not entropy, it's a substitute. I dont know how many times I
> > need to point that out.
>
> As far as I understood the source for the entropy haveged collects is
> random timing jitter from the CPU. Could you explain, why that is not
> real entropy, although it passes the FIPS tests? Or point to an
> explanation to learn from?

This is already round 2 of the argumentation, see
http://lists.busybox.net/pipermail/buildroot/2020-June/284465.html

But yes. haveged is still not tapping any entropy the kernel has not available,
it just blows up the low entropy available with a random number generator.
I am not up to speed with FIPS tests, but from a really really long way back
it wasn't a big issue to pass most tests with the Mersenne Twister and a few
bits of true entropy.

Basically it feeds PRNG back to kernel and lets it account as entropy source.

> > The less dependencies, the faster the system can startup (and lesser
> > chances of some stoopid deadlocks).
>
> This might be true in general, but it is not necessarily on embedded
> systems waiting for the kernel's crng to be initialized. If that
> initialization is a requirement and the system has very few entropy
> sources only (think of an embedded device with no network initialized,
> no HID, no sensors, …) the boot can actually hours or days, seriously.

Yes, don't need to tell me that. But the requested change would make
things worse not better
in times of startup and potentially "quality" entropy.
With systemd, a "before" means just that the process is spawned,
doesn't mean that a single bit
of random was fed back to the kernel.
-   The haveged will spawn at the same time
-   random seed will be delayed (and there might be real entropy from
a long running system now not accounted).

In short:

Want better/faster entropy, use rng-tools, or choose to "trust" the
CPU vendor if instructions are available.
Want to boot faster, substituting real entropy by blowing it up with a
PRNG, pick haveged.

A good PRNG is still not entropy.

Norbert
Jérémy ROSEN June 29, 2020, 12:03 p.m. UTC | #6
Le lun. 29 juin 2020 à 10:29, Norbert Lange <nolange79@gmail.com> a écrit :

>
>
> Am Mo., 29. Juni 2020 um 09:31 Uhr schrieb Jérémy ROSEN <
> jeremy.rosen@smile.fr>:
>
>> Well
>> I still think you need Before=systemd-random-seed.service and I don't
>> understand why you are reluctant to add it.
>> (Honestly, I think the Before= and your work to make it an early boot
>> service should be upstreamed)
>>
>> So, i'm a bit reluctant to give my reviewed-by. Again, it's not worse
>> than it was, but if you want
>> to make sure that all services that need randomness are correctly started
>> after haveged, then
>> you have to add that Before=
>>
>
> Again, this doesn't help, and might actually hurt.
>
> -   systemd-random-seed.service could actually add better (real) entropy.
>      (Upstream actually had an After systemd-random-seed.service for that
> reason).
> -   a before on a "persistent" service does not really block, while
> accessing the kernels random source when it's not uninitialised will,
>     so random consumers are already implicitly waiting for haveged - when
> they need entropy and not a moment before.
>
>
I'm not sure what you mean by "persistent" in that context.
I also think there is a confusion on what Before= does....
Before=systemd-random-seed.service means that systemd-random-seed will be
spawned after haveged is READY (in
the Type= sense of READY)

unfortunately, it seems haveged does not synchronize with systemd at all
and indeed, in the case of haveged,
Before= will only sync the point where systemd spawns the coresponding
processes.

I am not very convinced on what you said about another source being
"better". Either you are OK with the value
proposition of haveged and you count it as good entropy or you are not and
you don't use haveged at all...

now... my main point is that services that need good entopy will
synchronize after systemd-random-seed.service.
This is documented by systemd and means that the processes will only be
spawned after the RNG is ready and
will not wait for entropy at all. That's the whole point of syncing after
systemd-random-seed.

So i understand your point about the implicit sync point added by the
kernel's "RGN is ready" bit, but I still think
that adding my sync point is "the way it's meant to be"

Anyway, at this point I think we should just agree to disagree and it's not
that relevant.
I still don't consider that the proper approch, but I still don't think
this should block that patch. Everything else is fine by me.


> I won't block the patch going in if a BR maintainer want to commit it, but
>> i'd like to understand why you are reluctant
>> to add that
>>
>
> Haveged is not entropy, it's a substitute. I dont know how many times I
> need to point that out.
> The less dependencies, the faster the system can startup (and lesser
> chances of some stoopid deadlocks).
>
> Look at the history for service.fedora [1], which is now the blueprint for
> the v2 patch,
> I considered just adding a switch to install the upstream service file,
> but this adds several heavy isolation options that are overkill for most
> uses,
> and add dependencies (upstream just removed one of these, because it
> created a cycle).
>
> [1] -
> https://github.com/jirka-h/haveged/commits/master/init.d/service.fedora
>
> Norbert
>
>
>> Regards
>> Jeremy
>>
>> Le ven. 26 juin 2020 à 00:39, Norbert Lange <nolange79@gmail.com> a
>> écrit :
>>
>>> Jeremy,
>>>
>>> Can you have a look and add your reviewed-by pls?
>>> No drastic changes from v1, except adding a few isolation options from
>>> the upstream fedora service file.
>>>
>>> Am Mi., 10. Juni 2020 um 00:42 Uhr schrieb Norbert Lange <
>>> nolange79@gmail.com>:
>>> >
>>> > Drop default dependencies, haveged needs nothing but
>>> > local sockets and /dev/random.
>>> >
>>> > The service file now mostly matches the upstream fedora file,
>>> > except alot of isolation options have been dropped.
>>> > The benefit for a completely controlled system is small,
>>> > and those option would pull in dependencies, delaying
>>> > entropy being filled up.
>>> >
>>> > Signed-off-by: Norbert Lange <nolange79@gmail.com>
>>> > ---
>>> >  package/haveged/haveged.service | 22 +++++++++++++++++-----
>>> >  1 file changed, 17 insertions(+), 5 deletions(-)
>>> >
>>> > diff --git a/package/haveged/haveged.service
>>> b/package/haveged/haveged.service
>>> > index 91035c6711..cfdaa93a37 100644
>>> > --- a/package/haveged/haveged.service
>>> > +++ b/package/haveged/haveged.service
>>> > @@ -1,10 +1,22 @@
>>> >  [Unit]
>>> > -Description=Entropy Harvesting Daemon
>>> > -Documentation=man:haveged(8)
>>> > +# inspiration from upstream init.d/service.fedora
>>> > +Description=Entropy Daemon based on the HAVEGE algorithm
>>> > +Documentation=man:haveged(8) http://www.issihosts.com/haveged/
>>> > +DefaultDependencies=no
>>> > +# This would wait for filesystems, but we only need /dev/random,
>>> > +# which is certainly available after systemd initialised
>>> > +# After=systemd-tmpfiles-setup-dev.service
>>> > +Before=sysinit.target shutdown.target systemd-journald.service
>>> >
>>> >  [Service]
>>> > -ExecStart=/usr/sbin/haveged -F -w 1024 -v 1
>>> > -SuccessExitStatus=143
>>> > +ExecStart=/usr/sbin/haveged -w 1024 -v 1 --Foreground
>>> > +Restart=always
>>> > +SuccessExitStatus=137 143
>>> > +
>>> > +# Only simple isolation methods that dont pull in dependencies
>>> > +CapabilityBoundingSet=CAP_SYS_ADMIN
>>> > +SecureBits=noroot-locked
>>> > +ProtectSystem=full
>>> >
>>> >  [Install]
>>> > -WantedBy=multi-user.target
>>> > +WantedBy=sysinit.target
>>> > --
>>> > 2.26.2
>>> >
>>>
>>
>>
>> --
>> [image: SMILE]  <http://www.smile.eu/>
>>
>> 20 rue des Jardins
>> 92600 Asnières-sur-Seine
>> *Jérémy ROSEN*
>> Architecte technique
>>
>> [image: email] jeremy.rosen@smile.fr
>> [image: phone]  +33 6 88 25 87 42
>> [image: url] http://www.smile.eu
>>
>> [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook]
>> <https://www.facebook.com/smileopensource> [image: LinkedIn]
>> <https://www.linkedin.com/company/smile> [image: Github]
>> <https://github.com/Smile-SA>
>>
>> [image: Découvrez l’univers Smile, rendez-vous sur smile.eu]
>> <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
>>
>
Alexander Dahl June 29, 2020, 12:41 p.m. UTC | #7
Hello Norbert,

On Mon, Jun 29, 2020 at 11:55:26AM +0200, Norbert Lange wrote:
> Am Mo., 29. Juni 2020 um 11:30 Uhr schrieb Alexander Dahl <post@lespocky.de>:
> > On Mon, Jun 29, 2020 at 10:29:38AM +0200, Norbert Lange wrote:
> > > Haveged is not entropy, it's a substitute. I dont know how many times I
> > > need to point that out.
> >
> > As far as I understood the source for the entropy haveged collects is
> > random timing jitter from the CPU. Could you explain, why that is not
> > real entropy, although it passes the FIPS tests? Or point to an
> > explanation to learn from?
> 
> This is already round 2 of the argumentation, see
> http://lists.busybox.net/pipermail/buildroot/2020-June/284465.html
> 
> But yes. haveged is still not tapping any entropy the kernel has not available,
> it just blows up the low entropy available with a random number generator.

So, I read http://www.issihosts.com/haveged/history.html (again) and
as far as I understand it is a not a pseudo random number generator.
According to its own documentation
https://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html#toc-Subsection-1.1
it is a random generator based on CPU timing jitter, measured by high
precision timers.  That randomness is fed to the kernel pools the same
way one would fed randomness from a true hwrng.  Right?

> I am not up to speed with FIPS tests, but from a really really long way back
> it wasn't a big issue to pass most tests with the Mersenne Twister and a few
> bits of true entropy.
> 
> Basically it feeds PRNG back to kernel and lets it account as entropy source.

I could not find any backup for that claim.  If I understood
correctly, haveged does not read from the kernel PRNG.

> In short:
> 
> Want better/faster entropy, use rng-tools, or choose to "trust" the
> CPU vendor if instructions are available.

rng-tools is useless without a hwrng or jitterentropy-rngd, which does
the same thing as haveged.  So for a system without a hwrng, how
should that recommendation help an user?

> A good PRNG is still not entropy.

I think we can agree on that one.

Greets
Alex
Norbert Lange June 29, 2020, 3:08 p.m. UTC | #8
Am Mo., 29. Juni 2020 um 14:04 Uhr schrieb Jérémy ROSEN <
jeremy.rosen@smile.fr>:

>
>
> Le lun. 29 juin 2020 à 10:29, Norbert Lange <nolange79@gmail.com> a
> écrit :
>
>>
>>
>> Am Mo., 29. Juni 2020 um 09:31 Uhr schrieb Jérémy ROSEN <
>> jeremy.rosen@smile.fr>:
>>
>>> Well
>>> I still think you need Before=systemd-random-seed.service and I don't
>>> understand why you are reluctant to add it.
>>> (Honestly, I think the Before= and your work to make it an early boot
>>> service should be upstreamed)
>>>
>>> So, i'm a bit reluctant to give my reviewed-by. Again, it's not worse
>>> than it was, but if you want
>>> to make sure that all services that need randomness are correctly
>>> started after haveged, then
>>> you have to add that Before=
>>>
>>
>> Again, this doesn't help, and might actually hurt.
>>
>> -   systemd-random-seed.service could actually add better (real) entropy.
>>      (Upstream actually had an After systemd-random-seed.service for that
>> reason).
>> -   a before on a "persistent" service does not really block, while
>> accessing the kernels random source when it's not uninitialised will,
>>     so random consumers are already implicitly waiting for haveged - when
>> they need entropy and not a moment before.
>>
>>
> I'm not sure what you mean by "persistent" in that context.
> I also think there is a confusion on what Before= does....
> Before=systemd-random-seed.service means that systemd-random-seed will be
> spawned after haveged is READY (in
> the Type= sense of READY)
>
> unfortunately, it seems haveged does not synchronize with systemd at all
> and indeed, in the case of haveged,
> Before= will only sync the point where systemd spawns the coresponding
> processes.
>

So you agree it's pointless?
It does not make haveged start faster, it will delay systemd-random-seed a
ridiculous small amount.

I am not very convinced on what you said about another source being
> "better". Either you are OK with the value
> proposition of haveged and you count it as good entropy or you are not and
> you don't use haveged at all...
>

I don't use haveged as good source for entropy, I use it because otherwise
the system won't boot for ages.
You don't even have a measure on how much entropy the jitter adds.


> now... my main point is that services that need good entopy will
> synchronize after systemd-random-seed.service.
> This is documented by systemd and means that the processes will only be
> spawned after the RNG is ready and
> will not wait for entropy at all. That's the whole point of syncing after
> systemd-random-seed.
>

Yes, and none of this is affected by adding a Before dependency.


> So i understand your point about the implicit sync point added by the
> kernel's "RGN is ready" bit, but I still think
> that adding my sync point is "the way it's meant to be"
>

Some concrete example of where this "actually" helps would be needed, let
alone an explanation why upstream, debian and
AFAIR fedora had haveged ordered *after* systemd-random-seed (likely before
they figured out this could deadlock with the
seed being on an network drive).

So it:
-   Wont help
-   the sync point is already systemd-random-seed
-   arguably if you are paranoid about secure random numbers you will
disable haveged in favor of true entropy,
    then can consider blocking on systemd-random-seed.

Norbert

Anyway, at this point I think we should just agree to disagree and it's not
> that relevant.
> I still don't consider that the proper approch, but I still don't think
> this should block that patch. Everything else is fine by me.
>

>
>> I won't block the patch going in if a BR maintainer want to commit it,
>>> but i'd like to understand why you are reluctant
>>> to add that
>>>
>>
>> Haveged is not entropy, it's a substitute. I dont know how many times I
>> need to point that out.
>> The less dependencies, the faster the system can startup (and lesser
>> chances of some stoopid deadlocks).
>>
>> Look at the history for service.fedora [1], which is now the blueprint
>> for the v2 patch,
>> I considered just adding a switch to install the upstream service file,
>> but this adds several heavy isolation options that are overkill for most
>> uses,
>> and add dependencies (upstream just removed one of these, because it
>> created a cycle).
>>
>> [1] -
>> https://github.com/jirka-h/haveged/commits/master/init.d/service.fedora
>>
>> Norbert
>>
>>
>>> Regards
>>> Jeremy
>>>
>>> Le ven. 26 juin 2020 à 00:39, Norbert Lange <nolange79@gmail.com> a
>>> écrit :
>>>
>>>> Jeremy,
>>>>
>>>> Can you have a look and add your reviewed-by pls?
>>>> No drastic changes from v1, except adding a few isolation options from
>>>> the upstream fedora service file.
>>>>
>>>> Am Mi., 10. Juni 2020 um 00:42 Uhr schrieb Norbert Lange <
>>>> nolange79@gmail.com>:
>>>> >
>>>> > Drop default dependencies, haveged needs nothing but
>>>> > local sockets and /dev/random.
>>>> >
>>>> > The service file now mostly matches the upstream fedora file,
>>>> > except alot of isolation options have been dropped.
>>>> > The benefit for a completely controlled system is small,
>>>> > and those option would pull in dependencies, delaying
>>>> > entropy being filled up.
>>>> >
>>>> > Signed-off-by: Norbert Lange <nolange79@gmail.com>
>>>> > ---
>>>> >  package/haveged/haveged.service | 22 +++++++++++++++++-----
>>>> >  1 file changed, 17 insertions(+), 5 deletions(-)
>>>> >
>>>> > diff --git a/package/haveged/haveged.service
>>>> b/package/haveged/haveged.service
>>>> > index 91035c6711..cfdaa93a37 100644
>>>> > --- a/package/haveged/haveged.service
>>>> > +++ b/package/haveged/haveged.service
>>>> > @@ -1,10 +1,22 @@
>>>> >  [Unit]
>>>> > -Description=Entropy Harvesting Daemon
>>>> > -Documentation=man:haveged(8)
>>>> > +# inspiration from upstream init.d/service.fedora
>>>> > +Description=Entropy Daemon based on the HAVEGE algorithm
>>>> > +Documentation=man:haveged(8) http://www.issihosts.com/haveged/
>>>> > +DefaultDependencies=no
>>>> > +# This would wait for filesystems, but we only need /dev/random,
>>>> > +# which is certainly available after systemd initialised
>>>> > +# After=systemd-tmpfiles-setup-dev.service
>>>> > +Before=sysinit.target shutdown.target systemd-journald.service
>>>> >
>>>> >  [Service]
>>>> > -ExecStart=/usr/sbin/haveged -F -w 1024 -v 1
>>>> > -SuccessExitStatus=143
>>>> > +ExecStart=/usr/sbin/haveged -w 1024 -v 1 --Foreground
>>>> > +Restart=always
>>>> > +SuccessExitStatus=137 143
>>>> > +
>>>> > +# Only simple isolation methods that dont pull in dependencies
>>>> > +CapabilityBoundingSet=CAP_SYS_ADMIN
>>>> > +SecureBits=noroot-locked
>>>> > +ProtectSystem=full
>>>> >
>>>> >  [Install]
>>>> > -WantedBy=multi-user.target
>>>> > +WantedBy=sysinit.target
>>>> > --
>>>> > 2.26.2
>>>> >
>>>>
>>>
>>>
>>> --
>>> [image: SMILE]  <http://www.smile.eu/>
>>>
>>> 20 rue des Jardins
>>> 92600 Asnières-sur-Seine
>>> *Jérémy ROSEN*
>>> Architecte technique
>>>
>>> [image: email] jeremy.rosen@smile.fr
>>> [image: phone]  +33 6 88 25 87 42
>>> [image: url] http://www.smile.eu
>>>
>>> [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook]
>>> <https://www.facebook.com/smileopensource> [image: LinkedIn]
>>> <https://www.linkedin.com/company/smile> [image: Github]
>>> <https://github.com/Smile-SA>
>>>
>>> [image: Découvrez l’univers Smile, rendez-vous sur smile.eu]
>>> <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
>>>
>>
>
> --
> [image: SMILE]  <http://www.smile.eu/>
>
> 20 rue des Jardins
> 92600 Asnières-sur-Seine
> *Jérémy ROSEN*
> Architecte technique
>
> [image: email] jeremy.rosen@smile.fr
> [image: phone]  +33 6 88 25 87 42
> [image: url] http://www.smile.eu
>
> [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook]
> <https://www.facebook.com/smileopensource> [image: LinkedIn]
> <https://www.linkedin.com/company/smile> [image: Github]
> <https://github.com/Smile-SA>
>
> [image: Découvrez l’univers Smile, rendez-vous sur smile.eu]
> <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
>
Norbert Lange June 29, 2020, 3:17 p.m. UTC | #9
Am Mo., 29. Juni 2020 um 14:41 Uhr schrieb Alexander Dahl <post@lespocky.de>:
>
> Hello Norbert,
>
> On Mon, Jun 29, 2020 at 11:55:26AM +0200, Norbert Lange wrote:
> > Am Mo., 29. Juni 2020 um 11:30 Uhr schrieb Alexander Dahl <post@lespocky.de>:
> > > On Mon, Jun 29, 2020 at 10:29:38AM +0200, Norbert Lange wrote:
> > > > Haveged is not entropy, it's a substitute. I dont know how many times I
> > > > need to point that out.
> > >
> > > As far as I understood the source for the entropy haveged collects is
> > > random timing jitter from the CPU. Could you explain, why that is not
> > > real entropy, although it passes the FIPS tests? Or point to an
> > > explanation to learn from?
> >
> > This is already round 2 of the argumentation, see
> > http://lists.busybox.net/pipermail/buildroot/2020-June/284465.html
> >
> > But yes. haveged is still not tapping any entropy the kernel has not available,
> > it just blows up the low entropy available with a random number generator.
>
> So, I read http://www.issihosts.com/haveged/history.html (again) and
> as far as I understand it is a not a pseudo random number generator.
> According to its own documentation
> https://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html#toc-Subsection-1.1
> it is a random generator based on CPU timing jitter, measured by high
> precision timers.  That randomness is fed to the kernel pools the same
> way one would fed randomness from a true hwrng.  Right?

random generator *based* on CPU timing jitter, just like you typically
seed a PRNG
system time.
Its not just entropy, you dont have any measure on how much entropy
you get from jitter,
especially on embedded systems or VMs where you would haveged in the
first place.

>
> > I am not up to speed with FIPS tests, but from a really really long way back
> > it wasn't a big issue to pass most tests with the Mersenne Twister and a few
> > bits of true entropy.
> >
> > Basically it feeds PRNG back to kernel and lets it account as entropy source.
>
> I could not find any backup for that claim.  If I understood
> correctly, haveged does not read from the kernel PRNG.

The kernel has an entropy pool, it taps alot sources (inkl jitter, see
https://lwn.net/Articles/642166/).
what haveged does is overaccounting the very little true entropy it
fetches (by using a PRNG on top AFAIU).

>
> > In short:
> >
> > Want better/faster entropy, use rng-tools, or choose to "trust" the
> > CPU vendor if instructions are available.
>
> rng-tools is useless without a hwrng or jitterentropy-rngd, which does
> the same thing as haveged.  So for a system without a hwrng, how
> should that recommendation help an user?

Maybe you should understand that not everyone needs that kinda level
of entropy.
If you are that concerned, use a TPM Module + rng-tools.
haveged's primary concern is to speed up boot, *not* improve the random numbers,
it does not tap entropy that the kernel is not using already.

>
> > A good PRNG is still not entropy.
>
> I think we can agree on that one.
>
> Greets
> Alex

Norbert
Alexander Dahl June 29, 2020, 9:37 p.m. UTC | #10
Hello Norbert,

On Mon, Jun 29, 2020 at 05:17:16PM +0200, Norbert Lange wrote:
> Am Mo., 29. Juni 2020 um 14:41 Uhr schrieb Alexander Dahl <post@lespocky.de>:
> > On Mon, Jun 29, 2020 at 11:55:26AM +0200, Norbert Lange wrote:
> > > Am Mo., 29. Juni 2020 um 11:30 Uhr schrieb Alexander Dahl <post@lespocky.de>:
> > > > On Mon, Jun 29, 2020 at 10:29:38AM +0200, Norbert Lange wrote:
> > > > > Haveged is not entropy, it's a substitute. I dont know how many times I
> > > > > need to point that out.
> > > >
> > > > As far as I understood the source for the entropy haveged collects is
> > > > random timing jitter from the CPU. Could you explain, why that is not
> > > > real entropy, although it passes the FIPS tests? Or point to an
> > > > explanation to learn from?
> > >
> > > This is already round 2 of the argumentation, see
> > > http://lists.busybox.net/pipermail/buildroot/2020-June/284465.html
> > >
> > > But yes. haveged is still not tapping any entropy the kernel has not available,
> > > it just blows up the low entropy available with a random number generator.
> >
> > So, I read http://www.issihosts.com/haveged/history.html (again) and
> > as far as I understand it is a not a pseudo random number generator.
> > According to its own documentation
> > https://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html#toc-Subsection-1.1
> > it is a random generator based on CPU timing jitter, measured by high
> > precision timers.  That randomness is fed to the kernel pools the same
> > way one would fed randomness from a true hwrng.  Right?
> 
> random generator *based* on CPU timing jitter, just like you typically
> seed a PRNG
> system time.

I just took some time and read the havege source.  It's not just
seeding with one timestamp or something, the jitter is the noise
source, and new jitter data is gathered by doing calculations, and
measuring timings (and doing some calculations on top) on each read to
the havege rng.

> Its not just entropy, you dont have any measure on how much entropy
> you get from jitter,
> especially on embedded systems or VMs where you would haveged in the
> first place.

I'm no expert on RNG, not at all.  But how is an embedded system or a
virtual machine CPU different from other systems here, if the noise
source is the CPU itself only?

> > > I am not up to speed with FIPS tests, but from a really really long way back
> > > it wasn't a big issue to pass most tests with the Mersenne Twister and a few
> > > bits of true entropy.
> > >
> > > Basically it feeds PRNG back to kernel and lets it account as entropy source.
> >
> > I could not find any backup for that claim.  If I understood
> > correctly, haveged does not read from the kernel PRNG.
> 
> The kernel has an entropy pool, it taps alot sources (inkl jitter, see
> https://lwn.net/Articles/642166/).

Yes, but according to Stephan Müller, the author of the
jitterentropy-rng, the kernel uses the CPU timing jitter internally
only in the crypto subsystem, that's not fed to the pool /dev/random
uses [1].  There's a patch series for a redesigned random number
subsystem by him, which would make that possible, but that never got
merged. 

> what haveged does is overaccounting the very little true entropy it
> fetches (by using a PRNG on top AFAIU).

That may be, I did not read and understood the haveged source good
enough to prove or disprove that.

> > > In short:
> > >
> > > Want better/faster entropy, use rng-tools, or choose to "trust" the
> > > CPU vendor if instructions are available.
> >
> > rng-tools is useless without a hwrng or jitterentropy-rngd, which does
> > the same thing as haveged.  So for a system without a hwrng, how
> > should that recommendation help an user?
> 
> Maybe you should understand that not everyone needs that kinda level
> of entropy.
> If you are that concerned, use a TPM Module + rng-tools.
> haveged's primary concern is to speed up boot, *not* improve the random numbers,
> it does not tap entropy that the kernel is not using already.

I think this is wrong.  According to [1] the kernel does not feed CPU
timing jitter based entropy to the entropy pool for the rng available
to userspace, which haveged does.

Greets
Alex

[1] https://lore.kernel.org/linux-crypto/6708214.Ppv1U3N1OP@tauon.chronox.de/T/#t
Norbert Lange June 30, 2020, 7:46 a.m. UTC | #11
Am Mo., 29. Juni 2020 um 23:38 Uhr schrieb Alexander Dahl <post@lespocky.de>:
>
> Hello Norbert,
>
> On Mon, Jun 29, 2020 at 05:17:16PM +0200, Norbert Lange wrote:
> > Am Mo., 29. Juni 2020 um 14:41 Uhr schrieb Alexander Dahl <post@lespocky.de>:
> > > On Mon, Jun 29, 2020 at 11:55:26AM +0200, Norbert Lange wrote:
> > > > Am Mo., 29. Juni 2020 um 11:30 Uhr schrieb Alexander Dahl <post@lespocky.de>:
> > > > > On Mon, Jun 29, 2020 at 10:29:38AM +0200, Norbert Lange wrote:
> > > > > > Haveged is not entropy, it's a substitute. I dont know how many times I
> > > > > > need to point that out.
> > > > >
> > > > > As far as I understood the source for the entropy haveged collects is
> > > > > random timing jitter from the CPU. Could you explain, why that is not
> > > > > real entropy, although it passes the FIPS tests? Or point to an
> > > > > explanation to learn from?
> > > >
> > > > This is already round 2 of the argumentation, see
> > > > http://lists.busybox.net/pipermail/buildroot/2020-June/284465.html
> > > >
> > > > But yes. haveged is still not tapping any entropy the kernel has not available,
> > > > it just blows up the low entropy available with a random number generator.
> > >
> > > So, I read http://www.issihosts.com/haveged/history.html (again) and
> > > as far as I understand it is a not a pseudo random number generator.
> > > According to its own documentation
> > > https://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html#toc-Subsection-1.1
> > > it is a random generator based on CPU timing jitter, measured by high
> > > precision timers.  That randomness is fed to the kernel pools the same
> > > way one would fed randomness from a true hwrng.  Right?
> >
> > random generator *based* on CPU timing jitter, just like you typically
> > seed a PRNG
> > system time.
>
> I just took some time and read the havege source.  It's not just
> seeding with one timestamp or something, the jitter is the noise
> source, and new jitter data is gathered by doing calculations, and
> measuring timings (and doing some calculations on top) on each read to
> the havege rng.

Point is its not entropy but a PRNG with (re)seeds, the only qualification
seems to be that it passes tests. To quote a kernel dev [1]:
"One of Peter's colleagues replaced the random input source employed
by HAVEGE with a constant stream of ones. All of the same tests
passed."

Means the PRNG is enough to pass the tests. There is no good argument that
the entropy it gathers is of good quality.

> > Its not just entropy, you dont have any measure on how much entropy
> > you get from jitter,
> > especially on embedded systems or VMs where you would haveged in the
> > first place.
>
> I'm no expert on RNG, not at all.  But how is an embedded system or a
> virtual machine CPU different from other systems here, if the noise
> source is the CPU itself only?

haveged depends on jitters in the kernel scheduler and cache/pipeline
characteristics.
Those aren't the source of noise (entropy in this context), those are
consequences of other noises
(skew between multiple clock sources, IRG/device/filesystem/net timings).
On isolated systems you have less of that noise (and on embedded
simpler, more predictable CPUs aswell).

The CPU is fully deterministic without those outside influences, even
if no one is practically able to do so.
(You might have heard of all the spectre issues where some smart
people figured some details out anyway).

>
> > > > I am not up to speed with FIPS tests, but from a really really long way back
> > > > it wasn't a big issue to pass most tests with the Mersenne Twister and a few
> > > > bits of true entropy.
> > > >
> > > > Basically it feeds PRNG back to kernel and lets it account as entropy source.
> > >
> > > I could not find any backup for that claim.  If I understood
> > > correctly, haveged does not read from the kernel PRNG.
> >
> > The kernel has an entropy pool, it taps alot sources (inkl jitter, see
> > https://lwn.net/Articles/642166/).
>
> Yes, but according to Stephan Müller, the author of the
> jitterentropy-rng, the kernel uses the CPU timing jitter internally
> only in the crypto subsystem, that's not fed to the pool /dev/random
> uses [1].  There's a patch series for a redesigned random number
> subsystem by him, which would make that possible, but that never got
> merged.

Maybe because no one trusts self-generated jitter as source for
entropy for a reason (as a RNG its another matter)?
You need entropy from outside the CPU (not counting embedded entropy
hardware/instructions)
 everything else can be assumed a deterministic feedback loop.

> > what haveged does is overaccounting the very little true entropy it
> > fetches (by using a PRNG on top AFAIU).
>
> That may be, I did not read and understood the haveged source good
> enough to prove or disprove that.

See quote above, even if the entropy is removed, it will feed the
kernel just PRNG noise,
and there is no guarantee whatsoever that the "jitter" is not the same
for each reboot.

> > > > In short:
> > > >
> > > > Want better/faster entropy, use rng-tools, or choose to "trust" the
> > > > CPU vendor if instructions are available.
> > >
> > > rng-tools is useless without a hwrng or jitterentropy-rngd, which does
> > > the same thing as haveged.  So for a system without a hwrng, how
> > > should that recommendation help an user?
> >
> > Maybe you should understand that not everyone needs that kinda level
> > of entropy.
> > If you are that concerned, use a TPM Module + rng-tools.
> > haveged's primary concern is to speed up boot, *not* improve the random numbers,
> > it does not tap entropy that the kernel is not using already.
>
> I think this is wrong.  According to [1] the kernel does not feed CPU
> timing jitter based entropy to the entropy pool for the rng available
> to userspace, which haveged does.

Jitter noise would be easily available in kernel, but thats difficult to account
(how much is from outside sources, how much is deterministic).
You should feed the kernel good entropy, the kernel runs a PRNG over it,
if you feed the kernel stuff from a PRNG with no reasonable argumentation
that this is raw entropy the accounting will be off.

Dont get me wrong, it's fine for most usecases, but haveged does reduce
the quality of the entropy, and never should be your first option.

See the LWN article below [1], or Arch's page [2] on it.

Norbert

[1] - https://lwn.net/Articles/525459/
[2] - https://wiki.archlinux.org/index.php/Haveged

>
> Greets
> Alex
>
> [1] https://lore.kernel.org/linux-crypto/6708214.Ppv1U3N1OP@tauon.chronox.de/T/#t
>
> --
> /"\ ASCII RIBBON | »With the first link, the chain is forged. The first
> \ / CAMPAIGN     | speech censured, the first thought forbidden, the
>  X  AGAINST      | first freedom denied, chains us all irrevocably.«
> / \ HTML MAIL    | (Jean-Luc Picard, quoting Judge Aaron Satie)
Norbert Lange June 30, 2020, 7:54 a.m. UTC | #12
> >
> > > > > I am not up to speed with FIPS tests, but from a really really long way back
> > > > > it wasn't a big issue to pass most tests with the Mersenne Twister and a few
> > > > > bits of true entropy.
> > > > >
> > > > > Basically it feeds PRNG back to kernel and lets it account as entropy source.
> > > >
> > > > I could not find any backup for that claim.  If I understood
> > > > correctly, haveged does not read from the kernel PRNG.
> > >
> > > The kernel has an entropy pool, it taps alot sources (inkl jitter, see
> > > https://lwn.net/Articles/642166/).
> >
> > Yes, but according to Stephan Müller, the author of the
> > jitterentropy-rng, the kernel uses the CPU timing jitter internally
> > only in the crypto subsystem, that's not fed to the pool /dev/random
> > uses [1].  There's a patch series for a redesigned random number
> > subsystem by him, which would make that possible, but that never got
> > merged.

Forgot adding the kernel uses "timings of events such as hardware
interrupts as inputs",
that's basically the same entropy source that causes your "jitters".
"CPU effects" like cache evictions, pipeline flushes are just an
effect of that and could
be deterministically recreated if the IRQs happen in the same fashion again.

Norbert
Alexander Dahl June 30, 2020, 8:14 a.m. UTC | #13
Hei hei,

On Tue, Jun 30, 2020 at 09:46:12AM +0200, Norbert Lange wrote:
> Am Mo., 29. Juni 2020 um 23:38 Uhr schrieb Alexander Dahl <post@lespocky.de>:
> > I just took some time and read the havege source.  It's not just
> > seeding with one timestamp or something, the jitter is the noise
> > source, and new jitter data is gathered by doing calculations, and
> > measuring timings (and doing some calculations on top) on each read to
> > the havege rng.
> 
> Point is its not entropy but a PRNG with (re)seeds, the only qualification
> seems to be that it passes tests. To quote a kernel dev [1]:
> "One of Peter's colleagues replaced the random input source employed
> by HAVEGE with a constant stream of ones. All of the same tests
> passed."
> 
> Means the PRNG is enough to pass the tests. There is no good argument that
> the entropy it gathers is of good quality.
> 
> > > Its not just entropy, you dont have any measure on how much entropy
> > > you get from jitter,
> > > especially on embedded systems or VMs where you would haveged in the
> > > first place.
> >
> > I'm no expert on RNG, not at all.  But how is an embedded system or a
> > virtual machine CPU different from other systems here, if the noise
> > source is the CPU itself only?
> 
> haveged depends on jitters in the kernel scheduler and cache/pipeline
> characteristics.
> Those aren't the source of noise (entropy in this context), those are
> consequences of other noises
> (skew between multiple clock sources, IRG/device/filesystem/net timings).
> On isolated systems you have less of that noise (and on embedded
> simpler, more predictable CPUs aswell).
> 
> The CPU is fully deterministic without those outside influences, even
> if no one is practically able to do so.
> (You might have heard of all the spectre issues where some smart
> people figured some details out anyway).
> 
> >
> > > > > I am not up to speed with FIPS tests, but from a really really long way back
> > > > > it wasn't a big issue to pass most tests with the Mersenne Twister and a few
> > > > > bits of true entropy.
> > > > >
> > > > > Basically it feeds PRNG back to kernel and lets it account as entropy source.
> > > >
> > > > I could not find any backup for that claim.  If I understood
> > > > correctly, haveged does not read from the kernel PRNG.
> > >
> > > The kernel has an entropy pool, it taps alot sources (inkl jitter, see
> > > https://lwn.net/Articles/642166/).
> >
> > Yes, but according to Stephan Müller, the author of the
> > jitterentropy-rng, the kernel uses the CPU timing jitter internally
> > only in the crypto subsystem, that's not fed to the pool /dev/random
> > uses [1].  There's a patch series for a redesigned random number
> > subsystem by him, which would make that possible, but that never got
> > merged.
> 
> Maybe because no one trusts self-generated jitter as source for
> entropy for a reason (as a RNG its another matter)?
> You need entropy from outside the CPU (not counting embedded entropy
> hardware/instructions)
>  everything else can be assumed a deterministic feedback loop.
> 
> > > what haveged does is overaccounting the very little true entropy it
> > > fetches (by using a PRNG on top AFAIU).
> >
> > That may be, I did not read and understood the haveged source good
> > enough to prove or disprove that.
> 
> See quote above, even if the entropy is removed, it will feed the
> kernel just PRNG noise,
> and there is no guarantee whatsoever that the "jitter" is not the same
> for each reboot.
> 
> > > > > In short:
> > > > >
> > > > > Want better/faster entropy, use rng-tools, or choose to "trust" the
> > > > > CPU vendor if instructions are available.
> > > >
> > > > rng-tools is useless without a hwrng or jitterentropy-rngd, which does
> > > > the same thing as haveged.  So for a system without a hwrng, how
> > > > should that recommendation help an user?
> > >
> > > Maybe you should understand that not everyone needs that kinda level
> > > of entropy.
> > > If you are that concerned, use a TPM Module + rng-tools.
> > > haveged's primary concern is to speed up boot, *not* improve the random numbers,
> > > it does not tap entropy that the kernel is not using already.
> >
> > I think this is wrong.  According to [1] the kernel does not feed CPU
> > timing jitter based entropy to the entropy pool for the rng available
> > to userspace, which haveged does.
> 
> Jitter noise would be easily available in kernel, but thats difficult to account
> (how much is from outside sources, how much is deterministic).
> You should feed the kernel good entropy, the kernel runs a PRNG over it,
> if you feed the kernel stuff from a PRNG with no reasonable argumentation
> that this is raw entropy the accounting will be off.
> 
> Dont get me wrong, it's fine for most usecases, but haveged does reduce
> the quality of the entropy, and never should be your first option.
> 
> See the LWN article below [1], or Arch's page [2] on it.
> 
> Norbert
> 
> [1] - https://lwn.net/Articles/525459/
> [2] - https://wiki.archlinux.org/index.php/Haveged

Thanks for your explanations.  Especially the last lwn article puts
some more light on the whole topic.

Greets
Alex
diff mbox series

Patch

diff --git a/package/haveged/haveged.service b/package/haveged/haveged.service
index 91035c6711..cfdaa93a37 100644
--- a/package/haveged/haveged.service
+++ b/package/haveged/haveged.service
@@ -1,10 +1,22 @@ 
 [Unit]
-Description=Entropy Harvesting Daemon
-Documentation=man:haveged(8)
+# inspiration from upstream init.d/service.fedora
+Description=Entropy Daemon based on the HAVEGE algorithm
+Documentation=man:haveged(8) http://www.issihosts.com/haveged/
+DefaultDependencies=no
+# This would wait for filesystems, but we only need /dev/random,
+# which is certainly available after systemd initialised
+# After=systemd-tmpfiles-setup-dev.service
+Before=sysinit.target shutdown.target systemd-journald.service
 
 [Service]
-ExecStart=/usr/sbin/haveged -F -w 1024 -v 1
-SuccessExitStatus=143
+ExecStart=/usr/sbin/haveged -w 1024 -v 1 --Foreground
+Restart=always
+SuccessExitStatus=137 143
+
+# Only simple isolation methods that dont pull in dependencies
+CapabilityBoundingSet=CAP_SYS_ADMIN
+SecureBits=noroot-locked
+ProtectSystem=full
 
 [Install]
-WantedBy=multi-user.target
+WantedBy=sysinit.target