| Message ID | 20200609224116.13607-2-nolange79@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [v2,1/2] package/haveged: Change service file to run early | expand |
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 >
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 > > >
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> >
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
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
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> >> >
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
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> >
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
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
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)
> > > > > > > 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
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
On Wed, 10 Jun 2020 00:41:15 +0200 Norbert Lange <nolange79@gmail.com> wrote: > 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(-) The consensus on this patch was not huge, but after reading the comments from the different parties, it seems like the opposition was not very strong. So I applied this patch to master. Thanks! Thomas
Fine by me... Jérémy Le dim. 13 sept. 2020 à 15:27, Thomas Petazzoni < thomas.petazzoni@bootlin.com> a écrit : > On Wed, 10 Jun 2020 00:41:15 +0200 > Norbert Lange <nolange79@gmail.com> wrote: > > > 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(-) > > The consensus on this patch was not huge, but after reading the > comments from the different parties, it seems like the opposition was > not very strong. So I applied this patch to master. Thanks! > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com >
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
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(-)