| Message ID | 20200605225421.13494-1-nolange79@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | package/haveged: Allow service to run early | expand |
Hello, On Sat, 6 Jun 2020 00:54:21 +0200 Norbert Lange <nolange79@gmail.com> wrote: > Drop default dependencies, haveged needs nothing but > local sockets and /dev/random. > This allows the entropy to be available earlier. > > Signed-off-by: Norbert Lange <nolange79@gmail.com> Thanks Norbert. I will need the review of those systemd person on this patch. Jérémy ? Matt ? > package/haveged/haveged.service | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/package/haveged/haveged.service b/package/haveged/haveged.service > index 91035c6711..ed9f043a91 100644 > --- a/package/haveged/haveged.service > +++ b/package/haveged/haveged.service > @@ -1,10 +1,13 @@ > [Unit] > Description=Entropy Harvesting Daemon > Documentation=man:haveged(8) > +DefaultDependencies=no > +Conflicts=shutdown.target > +Before=sysinit.target shutdown.target systemd-update-done.service > > [Service] > ExecStart=/usr/sbin/haveged -F -w 1024 -v 1 > SuccessExitStatus=143 > > [Install] > -WantedBy=multi-user.target > +WantedBy=sysinit.target
Le sam. 6 juin 2020 à 00:55, Norbert Lange <nolange79@gmail.com> a écrit : > Drop default dependencies, haveged needs nothing but > local sockets and /dev/random. > This allows the entropy to be available earlier. > > Signed-off-by: Norbert Lange <nolange79@gmail.com> > --- > package/haveged/haveged.service | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/package/haveged/haveged.service > b/package/haveged/haveged.service > index 91035c6711..ed9f043a91 100644 > --- a/package/haveged/haveged.service > +++ b/package/haveged/haveged.service > @@ -1,10 +1,13 @@ > [Unit] > Description=Entropy Harvesting Daemon > Documentation=man:haveged(8) > +DefaultDependencies=no > +Conflicts=shutdown.target > +Before=sysinit.target shutdown.target systemd-update-done.service > > Since v243 (quoting systemd's NEWS file) : * systemd-random-seed.service is now a synchronization point for full initialization of the kernel's entropy pool. Services that require /dev/urandom to be correctly initialized should be ordered after this service. so... in that case it might make sense to add Before=systemd-random-seed.service (assuming that works. This a very early point, so it needs some testing) [Service] > ExecStart=/usr/sbin/haveged -F -w 1024 -v 1 > SuccessExitStatus=143 > > I could not find any documentation on haveged return codes, so i'll trust you on that one > [Install] > -WantedBy=multi-user.target > +WantedBy=sysinit.target > -- > 2.26.2 > > Apart from my earlier remark, you can add my ReviewedBy > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot >
Am So., 7. Juni 2020 um 12:35 Uhr schrieb Jérémy ROSEN <jeremy.rosen@smile.fr>: > > > > Le sam. 6 juin 2020 à 00:55, Norbert Lange <nolange79@gmail.com> a écrit : >> >> Drop default dependencies, haveged needs nothing but >> local sockets and /dev/random. >> This allows the entropy to be available earlier. >> >> Signed-off-by: Norbert Lange <nolange79@gmail.com> >> --- >> package/haveged/haveged.service | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/package/haveged/haveged.service b/package/haveged/haveged.service >> index 91035c6711..ed9f043a91 100644 >> --- a/package/haveged/haveged.service >> +++ b/package/haveged/haveged.service >> @@ -1,10 +1,13 @@ >> [Unit] >> Description=Entropy Harvesting Daemon >> Documentation=man:haveged(8) >> +DefaultDependencies=no >> +Conflicts=shutdown.target >> +Before=sysinit.target shutdown.target systemd-update-done.service >> > Since v243 (quoting systemd's NEWS file) : > > * systemd-random-seed.service is now a synchronization point for full > initialization of the kernel's entropy pool. Services that require > /dev/urandom to be correctly initialized should be ordered after this > service. > > so... in that case it might make sense to add Before=systemd-random-seed.service > (assuming that works. This a very early point, so it needs some testing) No, doesnt make sense, a "before" only means the service is *started before*, not the process did do anything worthwile. (That's the reason for my openssh patch BTW) systemd-random-seed.service is a one-shot, so a "before" *that* service means the dependants wait till it is finished. > >> [Service] >> ExecStart=/usr/sbin/haveged -F -w 1024 -v 1 >> SuccessExitStatus=143 >> > I could not find any documentation on haveged return codes, so i'll trust you on that one Don't trust me, I did not touch the values (but I can attest they work). >> [Install] >> -WantedBy=multi-user.target >> +WantedBy=sysinit.target >> -- >> 2.26.2 >> > Apart from my earlier remark, you can add my ReviewedBy Thx. Norbert
Le dim. 7 juin 2020 à 20:35, Norbert Lange <nolange79@gmail.com> a écrit : > Am So., 7. Juni 2020 um 12:35 Uhr schrieb Jérémy ROSEN < > jeremy.rosen@smile.fr>: > > > > > > > > Le sam. 6 juin 2020 à 00:55, Norbert Lange <nolange79@gmail.com> a > écrit : > >> > >> Drop default dependencies, haveged needs nothing but > >> local sockets and /dev/random. > >> This allows the entropy to be available earlier. > >> > >> Signed-off-by: Norbert Lange <nolange79@gmail.com> > >> --- > >> package/haveged/haveged.service | 5 ++++- > >> 1 file changed, 4 insertions(+), 1 deletion(-) > >> > >> diff --git a/package/haveged/haveged.service > b/package/haveged/haveged.service > >> index 91035c6711..ed9f043a91 100644 > >> --- a/package/haveged/haveged.service > >> +++ b/package/haveged/haveged.service > >> @@ -1,10 +1,13 @@ > >> [Unit] > >> Description=Entropy Harvesting Daemon > >> Documentation=man:haveged(8) > >> +DefaultDependencies=no > >> +Conflicts=shutdown.target > >> +Before=sysinit.target shutdown.target systemd-update-done.service > >> > > Since v243 (quoting systemd's NEWS file) : > > > > * systemd-random-seed.service is now a synchronization point for full > > initialization of the kernel's entropy pool. Services that > require > > /dev/urandom to be correctly initialized should be ordered > after this > > service. > > > > so... in that case it might make sense to add > Before=systemd-random-seed.service > > (assuming that works. This a very early point, so it needs some testing) > > > No, doesnt make sense, a "before" only means the service is *started > before*, > not the process did do anything worthwile. (That's the reason for my > openssh patch BTW) > systemd-random-seed.service is a one-shot, so a "before" *that* > service means the dependants wait till it is finished. > > (note that I don't really understand what haveged does, so I might be completely wrong in my understanding) systemd-random-seed is the sync point, that means that any service that needs random numbers should be ordered after random-seed. So, to me, it makes sense that we want to have haveged started before that point. Thus having haveged ordered before random-seed. and I don't really understand your sentence above... if you add Before=systemd-random-seed, it's systemd-random-seed that will wait for haveged to be started, not the other way round. (which seems to be what you say ??) now... if haveged needs some time to "do something usefull" then it means that haveged is badly synchronised on startup. The Ready signal in systemd is defined as "the point at which the service is able to render the service expected for it' > > > >> [Service] > >> ExecStart=/usr/sbin/haveged -F -w 1024 -v 1 > >> SuccessExitStatus=143 > >> > > I could not find any documentation on haveged return codes, so i'll > trust you on that one > > > Don't trust me, I did not touch the values (but I can attest they work). > > >> [Install] > >> -WantedBy=multi-user.target > >> +WantedBy=sysinit.target > >> -- > >> 2.26.2 > >> > > Apart from my earlier remark, you can add my ReviewedBy > > > Thx. > Norbert >
Am So., 7. Juni 2020 um 21:05 Uhr schrieb Jérémy ROSEN <jeremy.rosen@smile.fr>: > > > > Le dim. 7 juin 2020 à 20:35, Norbert Lange <nolange79@gmail.com> a écrit : >> >> Am So., 7. Juni 2020 um 12:35 Uhr schrieb Jérémy ROSEN <jeremy.rosen@smile.fr>: >> > >> > >> > >> > Le sam. 6 juin 2020 à 00:55, Norbert Lange <nolange79@gmail.com> a écrit : >> >> >> >> Drop default dependencies, haveged needs nothing but >> >> local sockets and /dev/random. >> >> This allows the entropy to be available earlier. >> >> >> >> Signed-off-by: Norbert Lange <nolange79@gmail.com> >> >> --- >> >> package/haveged/haveged.service | 5 ++++- >> >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> >> >> diff --git a/package/haveged/haveged.service b/package/haveged/haveged.service >> >> index 91035c6711..ed9f043a91 100644 >> >> --- a/package/haveged/haveged.service >> >> +++ b/package/haveged/haveged.service >> >> @@ -1,10 +1,13 @@ >> >> [Unit] >> >> Description=Entropy Harvesting Daemon >> >> Documentation=man:haveged(8) >> >> +DefaultDependencies=no >> >> +Conflicts=shutdown.target >> >> +Before=sysinit.target shutdown.target systemd-update-done.service >> >> >> > Since v243 (quoting systemd's NEWS file) : >> > >> > * systemd-random-seed.service is now a synchronization point for full >> > initialization of the kernel's entropy pool. Services that require >> > /dev/urandom to be correctly initialized should be ordered after this >> > service. >> > >> > so... in that case it might make sense to add Before=systemd-random-seed.service >> > (assuming that works. This a very early point, so it needs some testing) >> >> >> No, doesnt make sense, a "before" only means the service is *started before*, >> not the process did do anything worthwile. (That's the reason for my >> openssh patch BTW) >> systemd-random-seed.service is a one-shot, so a "before" *that* >> service means the dependants wait till it is finished. >> > (note that I don't really understand what haveged does, so I might be completely wrong in my > understanding) > > systemd-random-seed is the sync point, that means that any service that needs > random numbers should be ordered after random-seed. > > So, to me, it makes sense that we want to have haveged started before that point. Thus > having haveged ordered before random-seed. > > and I don't really understand your sentence above... > if you add Before=systemd-random-seed, it's systemd-random-seed that will wait for > haveged to be started, not the other way round. (which seems to be what you say ??) Yes, systemd-random-seed will wait for haveged to be *startet* (and maybe its immediatly preempted), but it takes several seconds after that till /dev/urandom is "ready" (what that means changed in the last few years multiple times) > > now... if haveged needs some time to "do something usefull" then it means that haveged > is badly synchronised on startup. The Ready signal in systemd is defined as "the point > at which the service is able to render the service expected for it' Yes, but haveged does not send such a signal (and systemd only wait for that if the Type=notify). Further the service only feeds data to the kernel, and the only valid meaning of /dev/urandom is "ready" comes from the kernel. The point of waiting for "systemd-random-seed" is a substitute if you are in a really tough spot, and independent of what haveged does. > > > > >> >> > >> >> [Service] >> >> ExecStart=/usr/sbin/haveged -F -w 1024 -v 1 >> >> SuccessExitStatus=143 >> >> >> > I could not find any documentation on haveged return codes, so i'll trust you on that one >> >> >> Don't trust me, I did not touch the values (but I can attest they work). >> >> >> [Install] >> >> -WantedBy=multi-user.target >> >> +WantedBy=sysinit.target >> >> -- >> >> 2.26.2 >> >> >> > Apart from my earlier remark, you can add my ReviewedBy >> >> >> Thx. >> Norbert > > > > -- > > > 20 rue des Jardins > 92600 Asnières-sur-Seine > > Jérémy ROSEN > Architecte technique > > jeremy.rosen@smile.fr > +33 6 88 25 87 42 > http://www.smile.eu Norbert
Le dim. 7 juin 2020 à 21:18, Norbert Lange <nolange79@gmail.com> a écrit : > Am So., 7. Juni 2020 um 21:05 Uhr schrieb Jérémy ROSEN < > jeremy.rosen@smile.fr>: > > > > > > > > Le dim. 7 juin 2020 à 20:35, Norbert Lange <nolange79@gmail.com> a > écrit : > >> > >> Am So., 7. Juni 2020 um 12:35 Uhr schrieb Jérémy ROSEN < > jeremy.rosen@smile.fr>: > >> > > >> > > >> > > >> > Le sam. 6 juin 2020 à 00:55, Norbert Lange <nolange79@gmail.com> a > écrit : > >> >> > >> >> Drop default dependencies, haveged needs nothing but > >> >> local sockets and /dev/random. > >> >> This allows the entropy to be available earlier. > >> >> > >> >> Signed-off-by: Norbert Lange <nolange79@gmail.com> > >> >> --- > >> >> package/haveged/haveged.service | 5 ++++- > >> >> 1 file changed, 4 insertions(+), 1 deletion(-) > >> >> > >> >> diff --git a/package/haveged/haveged.service > b/package/haveged/haveged.service > >> >> index 91035c6711..ed9f043a91 100644 > >> >> --- a/package/haveged/haveged.service > >> >> +++ b/package/haveged/haveged.service > >> >> @@ -1,10 +1,13 @@ > >> >> [Unit] > >> >> Description=Entropy Harvesting Daemon > >> >> Documentation=man:haveged(8) > >> >> +DefaultDependencies=no > >> >> +Conflicts=shutdown.target > >> >> +Before=sysinit.target shutdown.target systemd-update-done.service > >> >> > >> > Since v243 (quoting systemd's NEWS file) : > >> > > >> > * systemd-random-seed.service is now a synchronization point for full > >> > initialization of the kernel's entropy pool. Services that > require > >> > /dev/urandom to be correctly initialized should be ordered > after this > >> > service. > >> > > >> > so... in that case it might make sense to add > Before=systemd-random-seed.service > >> > (assuming that works. This a very early point, so it needs some > testing) > >> > >> > >> No, doesnt make sense, a "before" only means the service is *started > before*, > >> not the process did do anything worthwile. (That's the reason for my > >> openssh patch BTW) > >> systemd-random-seed.service is a one-shot, so a "before" *that* > >> service means the dependants wait till it is finished. > >> > > (note that I don't really understand what haveged does, so I might be > completely wrong in my > > understanding) > > > > systemd-random-seed is the sync point, that means that any service that > needs > > random numbers should be ordered after random-seed. > > > > So, to me, it makes sense that we want to have haveged started before > that point. Thus > > having haveged ordered before random-seed. > > > > and I don't really understand your sentence above... > > if you add Before=systemd-random-seed, it's systemd-random-seed that > will wait for > > haveged to be started, not the other way round. (which seems to be what > you say ??) > > > Yes, systemd-random-seed will wait for haveged to be *startet* (and > maybe its immediatly preempted), > but it takes several seconds after that till /dev/urandom is "ready" > (what that means changed in the last few years multiple times) > > ... yeah ... > > > > now... if haveged needs some time to "do something usefull" then it > means that haveged > > is badly synchronised on startup. The Ready signal in systemd is defined > as "the point > > at which the service is able to render the service expected for it' > > > Yes, but haveged does not send such a signal (and systemd only wait > for that if the Type=notify). > There is a workaround for that. Add an ExecStartPost that detects readiness. (mentionning that for completeness sake, not sure if it's worth doing here.) > Further the service only feeds data to the kernel, and the only valid > meaning of /dev/urandom is "ready" > comes from the kernel. > > and random-seed will wait for that, so syncronisation will work correctly > The point of waiting for "systemd-random-seed" is a substitute if you > are in a really tough spot, > and independent of what haveged does. > > No, it's more than a substitute. it's a sync point. It doesn't just load entropy into the kernel, it also blocks until the kernel reports that /dev/urandom is ready IOW the only way to make sure that haveged is started "at the right point" in a generic way is to add that Before= That would allow any service that needs reliable randomness to be correctly synced with haveged, even if they are not aware that haveged is here... > > > > > > > > > >> > >> > > >> >> [Service] > >> >> ExecStart=/usr/sbin/haveged -F -w 1024 -v 1 > >> >> SuccessExitStatus=143 > >> >> > >> > I could not find any documentation on haveged return codes, so i'll > trust you on that one > >> > >> > >> Don't trust me, I did not touch the values (but I can attest they > work). > >> > >> >> [Install] > >> >> -WantedBy=multi-user.target > >> >> +WantedBy=sysinit.target > >> >> -- > >> >> 2.26.2 > >> >> > >> > Apart from my earlier remark, you can add my ReviewedBy > >> > >> > >> Thx. > >> Norbert > > > > > > > > -- > > > > > > 20 rue des Jardins > > 92600 Asnières-sur-Seine > > > > Jérémy ROSEN > > Architecte technique > > > > jeremy.rosen@smile.fr > > +33 6 88 25 87 42 > > http://www.smile.eu > > Norbert >
Am So., 7. Juni 2020 um 21:27 Uhr schrieb Jérémy ROSEN <jeremy.rosen@smile.fr>: > > > > Le dim. 7 juin 2020 à 21:18, Norbert Lange <nolange79@gmail.com> a écrit : >> >> Am So., 7. Juni 2020 um 21:05 Uhr schrieb Jérémy ROSEN <jeremy.rosen@smile.fr>: >> > >> > >> > >> > Le dim. 7 juin 2020 à 20:35, Norbert Lange <nolange79@gmail.com> a écrit : >> >> >> >> Am So., 7. Juni 2020 um 12:35 Uhr schrieb Jérémy ROSEN <jeremy.rosen@smile.fr>: >> >> > >> >> > >> >> > >> >> > Le sam. 6 juin 2020 à 00:55, Norbert Lange <nolange79@gmail.com> a écrit : >> >> >> >> >> >> Drop default dependencies, haveged needs nothing but >> >> >> local sockets and /dev/random. >> >> >> This allows the entropy to be available earlier. >> >> >> >> >> >> Signed-off-by: Norbert Lange <nolange79@gmail.com> >> >> >> --- >> >> >> package/haveged/haveged.service | 5 ++++- >> >> >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> >> >> >> >> diff --git a/package/haveged/haveged.service b/package/haveged/haveged.service >> >> >> index 91035c6711..ed9f043a91 100644 >> >> >> --- a/package/haveged/haveged.service >> >> >> +++ b/package/haveged/haveged.service >> >> >> @@ -1,10 +1,13 @@ >> >> >> [Unit] >> >> >> Description=Entropy Harvesting Daemon >> >> >> Documentation=man:haveged(8) >> >> >> +DefaultDependencies=no >> >> >> +Conflicts=shutdown.target >> >> >> +Before=sysinit.target shutdown.target systemd-update-done.service >> >> >> >> >> > Since v243 (quoting systemd's NEWS file) : >> >> > >> >> > * systemd-random-seed.service is now a synchronization point for full >> >> > initialization of the kernel's entropy pool. Services that require >> >> > /dev/urandom to be correctly initialized should be ordered after this >> >> > service. >> >> > >> >> > so... in that case it might make sense to add Before=systemd-random-seed.service >> >> > (assuming that works. This a very early point, so it needs some testing) >> >> >> >> >> >> No, doesnt make sense, a "before" only means the service is *started before*, >> >> not the process did do anything worthwile. (That's the reason for my >> >> openssh patch BTW) >> >> systemd-random-seed.service is a one-shot, so a "before" *that* >> >> service means the dependants wait till it is finished. >> >> >> > (note that I don't really understand what haveged does, so I might be completely wrong in my >> > understanding) >> > >> > systemd-random-seed is the sync point, that means that any service that needs >> > random numbers should be ordered after random-seed. >> > >> > So, to me, it makes sense that we want to have haveged started before that point. Thus >> > having haveged ordered before random-seed. >> > >> > and I don't really understand your sentence above... >> > if you add Before=systemd-random-seed, it's systemd-random-seed that will wait for >> > haveged to be started, not the other way round. (which seems to be what you say ??) >> >> >> Yes, systemd-random-seed will wait for haveged to be *startet* (and >> maybe its immediatly preempted), >> but it takes several seconds after that till /dev/urandom is "ready" >> (what that means changed in the last few years multiple times) >> > ... yeah ... >> >> > >> > now... if haveged needs some time to "do something usefull" then it means that haveged >> > is badly synchronised on startup. The Ready signal in systemd is defined as "the point >> > at which the service is able to render the service expected for it' >> >> >> Yes, but haveged does not send such a signal (and systemd only wait >> for that if the Type=notify). > > > There is a workaround for that. Add an ExecStartPost that detects readiness. > (mentionning that for completeness sake, not sure if it's worth doing here.) > >> >> Further the service only feeds data to the kernel, and the only valid >> meaning of /dev/urandom is "ready" >> comes from the kernel. >> > and random-seed will wait for that, so syncronisation will work correctly Nope, it does not. It's a (poor) substitute to wait after some entropy was fed to the kernel. > >> >> The point of waiting for "systemd-random-seed" is a substitute if you >> are in a really tough spot, >> and independent of what haveged does. >> > No, it's more than a substitute. it's a sync point. > It doesn't just load entropy into the kernel, it also blocks until the kernel reports > that /dev/urandom is ready Show me where? > > IOW the only way to make sure that haveged is started "at the right point" in a generic > way is to add that Before= > > That would allow any service that needs reliable randomness to be correctly synced > with haveged, even if they are not aware that haveged is here... Well, consider that systemd-random-seed would block for that (which it does not), then it does not matter *when* haveged is started, only that it is not blocked (and it is not). In other words, it would make no difference. Norbert.
Le dim. 7 juin 2020 à 21:42, Norbert Lange <nolange79@gmail.com> a écrit : > Am So., 7. Juni 2020 um 21:27 Uhr schrieb Jérémy ROSEN < > jeremy.rosen@smile.fr>: > > > > > > > > Le dim. 7 juin 2020 à 21:18, Norbert Lange <nolange79@gmail.com> a > écrit : > >> > >> Am So., 7. Juni 2020 um 21:05 Uhr schrieb Jérémy ROSEN < > jeremy.rosen@smile.fr>: > >> > > >> > > >> > > >> > Le dim. 7 juin 2020 à 20:35, Norbert Lange <nolange79@gmail.com> a > écrit : > >> >> > >> >> Am So., 7. Juni 2020 um 12:35 Uhr schrieb Jérémy ROSEN < > jeremy.rosen@smile.fr>: > >> >> > > >> >> > > >> >> > > >> >> > Le sam. 6 juin 2020 à 00:55, Norbert Lange <nolange79@gmail.com> > a écrit : > >> >> >> > >> >> >> Drop default dependencies, haveged needs nothing but > >> >> >> local sockets and /dev/random. > >> >> >> This allows the entropy to be available earlier. > >> >> >> > >> >> >> Signed-off-by: Norbert Lange <nolange79@gmail.com> > >> >> >> --- > >> >> >> package/haveged/haveged.service | 5 ++++- > >> >> >> 1 file changed, 4 insertions(+), 1 deletion(-) > >> >> >> > >> >> >> diff --git a/package/haveged/haveged.service > b/package/haveged/haveged.service > >> >> >> index 91035c6711..ed9f043a91 100644 > >> >> >> --- a/package/haveged/haveged.service > >> >> >> +++ b/package/haveged/haveged.service > >> >> >> @@ -1,10 +1,13 @@ > >> >> >> [Unit] > >> >> >> Description=Entropy Harvesting Daemon > >> >> >> Documentation=man:haveged(8) > >> >> >> +DefaultDependencies=no > >> >> >> +Conflicts=shutdown.target > >> >> >> +Before=sysinit.target shutdown.target systemd-update-done.service > >> >> >> > >> >> > Since v243 (quoting systemd's NEWS file) : > >> >> > > >> >> > * systemd-random-seed.service is now a synchronization point for > full > >> >> > initialization of the kernel's entropy pool. Services > that require > >> >> > /dev/urandom to be correctly initialized should be > ordered after this > >> >> > service. > >> >> > > >> >> > so... in that case it might make sense to add > Before=systemd-random-seed.service > >> >> > (assuming that works. This a very early point, so it needs some > testing) > >> >> > >> >> > >> >> No, doesnt make sense, a "before" only means the service is > *started before*, > >> >> not the process did do anything worthwile. (That's the reason for my > >> >> openssh patch BTW) > >> >> systemd-random-seed.service is a one-shot, so a "before" *that* > >> >> service means the dependants wait till it is finished. > >> >> > >> > (note that I don't really understand what haveged does, so I might be > completely wrong in my > >> > understanding) > >> > > >> > systemd-random-seed is the sync point, that means that any service > that needs > >> > random numbers should be ordered after random-seed. > >> > > >> > So, to me, it makes sense that we want to have haveged started before > that point. Thus > >> > having haveged ordered before random-seed. > >> > > >> > and I don't really understand your sentence above... > >> > if you add Before=systemd-random-seed, it's systemd-random-seed that > will wait for > >> > haveged to be started, not the other way round. (which seems to be > what you say ??) > >> > >> > >> Yes, systemd-random-seed will wait for haveged to be *startet* (and > >> maybe its immediatly preempted), > >> but it takes several seconds after that till /dev/urandom is "ready" > >> (what that means changed in the last few years multiple times) > >> > > ... yeah ... > >> > >> > > >> > now... if haveged needs some time to "do something usefull" then it > means that haveged > >> > is badly synchronised on startup. The Ready signal in systemd is > defined as "the point > >> > at which the service is able to render the service expected for it' > >> > >> > >> Yes, but haveged does not send such a signal (and systemd only wait > >> for that if the Type=notify). > > > > > > There is a workaround for that. Add an ExecStartPost that detects > readiness. > > (mentionning that for completeness sake, not sure if it's worth doing > here.) > > > >> > >> Further the service only feeds data to the kernel, and the only valid > >> meaning of /dev/urandom is "ready" > >> comes from the kernel. > >> > > and random-seed will wait for that, so syncronisation will work correctly > > Nope, it does not. It's a (poor) substitute to wait after some entropy > was fed to the kernel. > > comment at the bottom of random-seed.service: # This service waits until the kernel's entropy pool is initialized, and may be # used as ordering barrier for service that require an initialized entropy # pool. Since initialization can take a while on entropy-starved systems, let's # increase the time-out substantially here. and from the man page This new seed is retrieved synchronously from the kernel, which means the service will not complete start-up until the random pool is fully initialized. I might misread stuff, as you stated randomness handing in linux is complicated but I really think that the initial idea behind that service was synchronisation... > > >> > >> The point of waiting for "systemd-random-seed" is a substitute if you > >> are in a really tough spot, > >> and independent of what haveged does. > >> > > No, it's more than a substitute. it's a sync point. > > It doesn't just load entropy into the kernel, it also blocks until the > kernel reports > > that /dev/urandom is ready > > Show me where? > > > > > IOW the only way to make sure that haveged is started "at the right > point" in a generic > > way is to add that Before= > > > > That would allow any service that needs reliable randomness to be > correctly synced > > with haveged, even if they are not aware that haveged is here... > > Well, consider that systemd-random-seed would block for that (which it > does not), > then it does not matter *when* haveged is started, only that it is not > blocked (and it is not). > In other words, it would make no difference. > > Norbert. >
Am So., 7. Juni 2020 um 21:47 Uhr schrieb Jérémy ROSEN <jeremy.rosen@smile.fr>: > > > > Le dim. 7 juin 2020 à 21:42, Norbert Lange <nolange79@gmail.com> a écrit : >> >> Am So., 7. Juni 2020 um 21:27 Uhr schrieb Jérémy ROSEN <jeremy.rosen@smile.fr>: >> > >> > >> > >> > Le dim. 7 juin 2020 à 21:18, Norbert Lange <nolange79@gmail.com> a écrit : >> >> >> >> Am So., 7. Juni 2020 um 21:05 Uhr schrieb Jérémy ROSEN <jeremy.rosen@smile.fr>: >> >> > >> >> > >> >> > >> >> > Le dim. 7 juin 2020 à 20:35, Norbert Lange <nolange79@gmail.com> a écrit : >> >> >> >> >> >> Am So., 7. Juni 2020 um 12:35 Uhr schrieb Jérémy ROSEN <jeremy.rosen@smile.fr>: >> >> >> > >> >> >> > >> >> >> > >> >> >> > Le sam. 6 juin 2020 à 00:55, Norbert Lange <nolange79@gmail.com> a écrit : >> >> >> >> >> >> >> >> Drop default dependencies, haveged needs nothing but >> >> >> >> local sockets and /dev/random. >> >> >> >> This allows the entropy to be available earlier. >> >> >> >> >> >> >> >> Signed-off-by: Norbert Lange <nolange79@gmail.com> >> >> >> >> --- >> >> >> >> package/haveged/haveged.service | 5 ++++- >> >> >> >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> >> >> >> >> >> >> diff --git a/package/haveged/haveged.service b/package/haveged/haveged.service >> >> >> >> index 91035c6711..ed9f043a91 100644 >> >> >> >> --- a/package/haveged/haveged.service >> >> >> >> +++ b/package/haveged/haveged.service >> >> >> >> @@ -1,10 +1,13 @@ >> >> >> >> [Unit] >> >> >> >> Description=Entropy Harvesting Daemon >> >> >> >> Documentation=man:haveged(8) >> >> >> >> +DefaultDependencies=no >> >> >> >> +Conflicts=shutdown.target >> >> >> >> +Before=sysinit.target shutdown.target systemd-update-done.service >> >> >> >> >> >> >> > Since v243 (quoting systemd's NEWS file) : >> >> >> > >> >> >> > * systemd-random-seed.service is now a synchronization point for full >> >> >> > initialization of the kernel's entropy pool. Services that require >> >> >> > /dev/urandom to be correctly initialized should be ordered after this >> >> >> > service. >> >> >> > >> >> >> > so... in that case it might make sense to add Before=systemd-random-seed.service >> >> >> > (assuming that works. This a very early point, so it needs some testing) >> >> >> >> >> >> >> >> >> No, doesnt make sense, a "before" only means the service is *started before*, >> >> >> not the process did do anything worthwile. (That's the reason for my >> >> >> openssh patch BTW) >> >> >> systemd-random-seed.service is a one-shot, so a "before" *that* >> >> >> service means the dependants wait till it is finished. >> >> >> >> >> > (note that I don't really understand what haveged does, so I might be completely wrong in my >> >> > understanding) >> >> > >> >> > systemd-random-seed is the sync point, that means that any service that needs >> >> > random numbers should be ordered after random-seed. >> >> > >> >> > So, to me, it makes sense that we want to have haveged started before that point. Thus >> >> > having haveged ordered before random-seed. >> >> > >> >> > and I don't really understand your sentence above... >> >> > if you add Before=systemd-random-seed, it's systemd-random-seed that will wait for >> >> > haveged to be started, not the other way round. (which seems to be what you say ??) >> >> >> >> >> >> Yes, systemd-random-seed will wait for haveged to be *startet* (and >> >> maybe its immediatly preempted), >> >> but it takes several seconds after that till /dev/urandom is "ready" >> >> (what that means changed in the last few years multiple times) >> >> >> > ... yeah ... >> >> >> >> > >> >> > now... if haveged needs some time to "do something usefull" then it means that haveged >> >> > is badly synchronised on startup. The Ready signal in systemd is defined as "the point >> >> > at which the service is able to render the service expected for it' >> >> >> >> >> >> Yes, but haveged does not send such a signal (and systemd only wait >> >> for that if the Type=notify). >> > >> > >> > There is a workaround for that. Add an ExecStartPost that detects readiness. >> > (mentionning that for completeness sake, not sure if it's worth doing here.) >> > >> >> >> >> Further the service only feeds data to the kernel, and the only valid >> >> meaning of /dev/urandom is "ready" >> >> comes from the kernel. >> >> >> > and random-seed will wait for that, so syncronisation will work correctly >> >> Nope, it does not. It's a (poor) substitute to wait after some entropy >> was fed to the kernel. >> > comment at the bottom of random-seed.service: > > # This service waits until the kernel's entropy pool is initialized, and may be > # used as ordering barrier for service that require an initialized entropy > # pool. Since initialization can take a while on entropy-starved systems, let's > # increase the time-out substantially here. > > and from the man page > > This new seed is retrieved synchronously from the kernel, which means the > service will not complete start-up until the random pool is fully initialized. > > I might misread stuff, as you stated randomness handing in linux is complicated > but I really think that the initial idea behind that service was synchronisation... No you are correct, Ive been proven wrong. Did not know reading the seed would sync to the entropy pool being ready. > > >> > >> >> >> >> The point of waiting for "systemd-random-seed" is a substitute if you >> >> are in a really tough spot, >> >> and independent of what haveged does. >> >> >> > No, it's more than a substitute. it's a sync point. >> > It doesn't just load entropy into the kernel, it also blocks until the kernel reports >> > that /dev/urandom is ready >> >> Show me where? >> >> > >> > IOW the only way to make sure that haveged is started "at the right point" in a generic >> > way is to add that Before= >> > >> > That would allow any service that needs reliable randomness to be correctly synced >> > with haveged, even if they are not aware that haveged is here... >> >> Well, consider that systemd-random-seed would block for that (which it >> does not), >> then it does not matter *when* haveged is started, only that it is not >> blocked (and it is not). >> In other words, it would make no difference. That point still stands though. - haveged will be "startable" as early as systemd-random-seed, potentially before (does not need a filesystem). - even if it is started later, systemd-random-seed will block until haveged was running long enough to feed entropy to the kernel Norbert
Le dim. 7 juin 2020 à 21:59, Norbert Lange <nolange79@gmail.com> a écrit : > Am So., 7. Juni 2020 um 21:47 Uhr schrieb Jérémy ROSEN < > jeremy.rosen@smile.fr>: > > > > > > > > Le dim. 7 juin 2020 à 21:42, Norbert Lange <nolange79@gmail.com> a > écrit : > >> > >> Am So., 7. Juni 2020 um 21:27 Uhr schrieb Jérémy ROSEN < > jeremy.rosen@smile.fr>: > >> > > >> > > >> > > >> > Le dim. 7 juin 2020 à 21:18, Norbert Lange <nolange79@gmail.com> a > écrit : > >> >> > >> >> Am So., 7. Juni 2020 um 21:05 Uhr schrieb Jérémy ROSEN < > jeremy.rosen@smile.fr>: > >> >> > > >> >> > > >> >> > > >> >> > Le dim. 7 juin 2020 à 20:35, Norbert Lange <nolange79@gmail.com> > a écrit : > >> >> >> > >> >> >> Am So., 7. Juni 2020 um 12:35 Uhr schrieb Jérémy ROSEN < > jeremy.rosen@smile.fr>: > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > Le sam. 6 juin 2020 à 00:55, Norbert Lange <nolange79@gmail.com> > a écrit : > >> >> >> >> > >> >> >> >> Drop default dependencies, haveged needs nothing but > >> >> >> >> local sockets and /dev/random. > >> >> >> >> This allows the entropy to be available earlier. > >> >> >> >> > >> >> >> >> Signed-off-by: Norbert Lange <nolange79@gmail.com> > >> >> >> >> --- > >> >> >> >> package/haveged/haveged.service | 5 ++++- > >> >> >> >> 1 file changed, 4 insertions(+), 1 deletion(-) > >> >> >> >> > >> >> >> >> diff --git a/package/haveged/haveged.service > b/package/haveged/haveged.service > >> >> >> >> index 91035c6711..ed9f043a91 100644 > >> >> >> >> --- a/package/haveged/haveged.service > >> >> >> >> +++ b/package/haveged/haveged.service > >> >> >> >> @@ -1,10 +1,13 @@ > >> >> >> >> [Unit] > >> >> >> >> Description=Entropy Harvesting Daemon > >> >> >> >> Documentation=man:haveged(8) > >> >> >> >> +DefaultDependencies=no > >> >> >> >> +Conflicts=shutdown.target > >> >> >> >> +Before=sysinit.target shutdown.target > systemd-update-done.service > >> >> >> >> > >> >> >> > Since v243 (quoting systemd's NEWS file) : > >> >> >> > > >> >> >> > * systemd-random-seed.service is now a synchronization point > for full > >> >> >> > initialization of the kernel's entropy pool. Services > that require > >> >> >> > /dev/urandom to be correctly initialized should be > ordered after this > >> >> >> > service. > >> >> >> > > >> >> >> > so... in that case it might make sense to add > Before=systemd-random-seed.service > >> >> >> > (assuming that works. This a very early point, so it needs some > testing) > >> >> >> > >> >> >> > >> >> >> No, doesnt make sense, a "before" only means the service is > *started before*, > >> >> >> not the process did do anything worthwile. (That's the reason for > my > >> >> >> openssh patch BTW) > >> >> >> systemd-random-seed.service is a one-shot, so a "before" *that* > >> >> >> service means the dependants wait till it is finished. > >> >> >> > >> >> > (note that I don't really understand what haveged does, so I might > be completely wrong in my > >> >> > understanding) > >> >> > > >> >> > systemd-random-seed is the sync point, that means that any service > that needs > >> >> > random numbers should be ordered after random-seed. > >> >> > > >> >> > So, to me, it makes sense that we want to have haveged started > before that point. Thus > >> >> > having haveged ordered before random-seed. > >> >> > > >> >> > and I don't really understand your sentence above... > >> >> > if you add Before=systemd-random-seed, it's systemd-random-seed > that will wait for > >> >> > haveged to be started, not the other way round. (which seems to be > what you say ??) > >> >> > >> >> > >> >> Yes, systemd-random-seed will wait for haveged to be *startet* (and > >> >> maybe its immediatly preempted), > >> >> but it takes several seconds after that till /dev/urandom is "ready" > >> >> (what that means changed in the last few years multiple times) > >> >> > >> > ... yeah ... > >> >> > >> >> > > >> >> > now... if haveged needs some time to "do something usefull" then > it means that haveged > >> >> > is badly synchronised on startup. The Ready signal in systemd is > defined as "the point > >> >> > at which the service is able to render the service expected for it' > >> >> > >> >> > >> >> Yes, but haveged does not send such a signal (and systemd only wait > >> >> for that if the Type=notify). > >> > > >> > > >> > There is a workaround for that. Add an ExecStartPost that detects > readiness. > >> > (mentionning that for completeness sake, not sure if it's worth doing > here.) > >> > > >> >> > >> >> Further the service only feeds data to the kernel, and the only valid > >> >> meaning of /dev/urandom is "ready" > >> >> comes from the kernel. > >> >> > >> > and random-seed will wait for that, so syncronisation will work > correctly > >> > >> Nope, it does not. It's a (poor) substitute to wait after some entropy > >> was fed to the kernel. > >> > > comment at the bottom of random-seed.service: > > > > # This service waits until the kernel's entropy pool is initialized, and > may be > > # used as ordering barrier for service that require an initialized > entropy > > # pool. Since initialization can take a while on entropy-starved > systems, let's > > # increase the time-out substantially here. > > > > and from the man page > > > > This new seed is retrieved synchronously from the kernel, which means > the > > service will not complete start-up until the random pool is fully > initialized. > > > > I might misread stuff, as you stated randomness handing in linux is > complicated > > but I really think that the initial idea behind that service was > synchronisation... > > > No you are correct, Ive been proven wrong. Did not know reading the > seed would sync to the entropy pool being ready. > > > > > > >> > > >> >> > >> >> The point of waiting for "systemd-random-seed" is a substitute if > you > >> >> are in a really tough spot, > >> >> and independent of what haveged does. > >> >> > >> > No, it's more than a substitute. it's a sync point. > >> > It doesn't just load entropy into the kernel, it also blocks until > the kernel reports > >> > that /dev/urandom is ready > >> > >> Show me where? > >> > >> > > >> > IOW the only way to make sure that haveged is started "at the right > point" in a generic > >> > way is to add that Before= > >> > > >> > That would allow any service that needs reliable randomness to be > correctly synced > >> > with haveged, even if they are not aware that haveged is here... > >> > >> Well, consider that systemd-random-seed would block for that (which it > >> does not), > >> then it does not matter *when* haveged is started, only that it is not > >> blocked (and it is not). > >> In other words, it would make no difference. > > > That point still stands though. > - haveged will be "startable" as early as systemd-random-seed, > potentially before (does not need a filesystem). > - even if it is started later, systemd-random-seed will block until > haveged was running long enough to feed entropy to the kernel > not if there are other sources of entropy available and the kernel marks urandom as ready before haveged is started more importantly, I am worried about "the promise". A user installing haveged will want to rely on it to provide improved randomness. by not syncing correctly, we are missing on that promise. Overall, I think it's good practice. Haveged should be aware of systemd-random-seed and should be started before systemd-random-seed. Having it explicitely before is more readable, safer, and doesn't rely on a kernel sync that is hard to understand. The more I think about it, the more I think you should add that... It's just a line in a config file and it might really improve clarity, avoid potential bugs and better guarantee that services needing high quality randomness will have it properly. > Norbert >
Am So., 7. Juni 2020 um 22:07 Uhr schrieb Jérémy ROSEN <jeremy.rosen@smile.fr>: > > > > Le dim. 7 juin 2020 à 21:59, Norbert Lange <nolange79@gmail.com> a écrit : >> >> Am So., 7. Juni 2020 um 21:47 Uhr schrieb Jérémy ROSEN <jeremy.rosen@smile.fr>: >> > >> > >> > >> > Le dim. 7 juin 2020 à 21:42, Norbert Lange <nolange79@gmail.com> a écrit : >> >> >> >> Am So., 7. Juni 2020 um 21:27 Uhr schrieb Jérémy ROSEN <jeremy.rosen@smile.fr>: >> >> > >> >> > >> >> > >> >> > Le dim. 7 juin 2020 à 21:18, Norbert Lange <nolange79@gmail.com> a écrit : >> >> >> >> >> >> Am So., 7. Juni 2020 um 21:05 Uhr schrieb Jérémy ROSEN <jeremy.rosen@smile.fr>: >> >> >> > >> >> >> > >> >> >> > >> >> >> > Le dim. 7 juin 2020 à 20:35, Norbert Lange <nolange79@gmail.com> a écrit : >> >> >> >> >> >> >> >> Am So., 7. Juni 2020 um 12:35 Uhr schrieb Jérémy ROSEN <jeremy.rosen@smile.fr>: >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > Le sam. 6 juin 2020 à 00:55, Norbert Lange <nolange79@gmail.com> a écrit : >> >> >> >> >> >> >> >> >> >> Drop default dependencies, haveged needs nothing but >> >> >> >> >> local sockets and /dev/random. >> >> >> >> >> This allows the entropy to be available earlier. >> >> >> >> >> >> >> >> >> >> Signed-off-by: Norbert Lange <nolange79@gmail.com> >> >> >> >> >> --- >> >> >> >> >> package/haveged/haveged.service | 5 ++++- >> >> >> >> >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> >> >> >> >> >> >> >> >> diff --git a/package/haveged/haveged.service b/package/haveged/haveged.service >> >> >> >> >> index 91035c6711..ed9f043a91 100644 >> >> >> >> >> --- a/package/haveged/haveged.service >> >> >> >> >> +++ b/package/haveged/haveged.service >> >> >> >> >> @@ -1,10 +1,13 @@ >> >> >> >> >> [Unit] >> >> >> >> >> Description=Entropy Harvesting Daemon >> >> >> >> >> Documentation=man:haveged(8) >> >> >> >> >> +DefaultDependencies=no >> >> >> >> >> +Conflicts=shutdown.target >> >> >> >> >> +Before=sysinit.target shutdown.target systemd-update-done.service >> >> >> >> >> >> >> >> >> > Since v243 (quoting systemd's NEWS file) : >> >> >> >> > >> >> >> >> > * systemd-random-seed.service is now a synchronization point for full >> >> >> >> > initialization of the kernel's entropy pool. Services that require >> >> >> >> > /dev/urandom to be correctly initialized should be ordered after this >> >> >> >> > service. >> >> >> >> > >> >> >> >> > so... in that case it might make sense to add Before=systemd-random-seed.service >> >> >> >> > (assuming that works. This a very early point, so it needs some testing) >> >> >> >> >> >> >> >> >> >> >> >> No, doesnt make sense, a "before" only means the service is *started before*, >> >> >> >> not the process did do anything worthwile. (That's the reason for my >> >> >> >> openssh patch BTW) >> >> >> >> systemd-random-seed.service is a one-shot, so a "before" *that* >> >> >> >> service means the dependants wait till it is finished. >> >> >> >> >> >> >> > (note that I don't really understand what haveged does, so I might be completely wrong in my >> >> >> > understanding) >> >> >> > >> >> >> > systemd-random-seed is the sync point, that means that any service that needs >> >> >> > random numbers should be ordered after random-seed. >> >> >> > >> >> >> > So, to me, it makes sense that we want to have haveged started before that point. Thus >> >> >> > having haveged ordered before random-seed. >> >> >> > >> >> >> > and I don't really understand your sentence above... >> >> >> > if you add Before=systemd-random-seed, it's systemd-random-seed that will wait for >> >> >> > haveged to be started, not the other way round. (which seems to be what you say ??) >> >> >> >> >> >> >> >> >> Yes, systemd-random-seed will wait for haveged to be *startet* (and >> >> >> maybe its immediatly preempted), >> >> >> but it takes several seconds after that till /dev/urandom is "ready" >> >> >> (what that means changed in the last few years multiple times) >> >> >> >> >> > ... yeah ... >> >> >> >> >> >> > >> >> >> > now... if haveged needs some time to "do something usefull" then it means that haveged >> >> >> > is badly synchronised on startup. The Ready signal in systemd is defined as "the point >> >> >> > at which the service is able to render the service expected for it' >> >> >> >> >> >> >> >> >> Yes, but haveged does not send such a signal (and systemd only wait >> >> >> for that if the Type=notify). >> >> > >> >> > >> >> > There is a workaround for that. Add an ExecStartPost that detects readiness. >> >> > (mentionning that for completeness sake, not sure if it's worth doing here.) >> >> > >> >> >> >> >> >> Further the service only feeds data to the kernel, and the only valid >> >> >> meaning of /dev/urandom is "ready" >> >> >> comes from the kernel. >> >> >> >> >> > and random-seed will wait for that, so syncronisation will work correctly >> >> >> >> Nope, it does not. It's a (poor) substitute to wait after some entropy >> >> was fed to the kernel. >> >> >> > comment at the bottom of random-seed.service: >> > >> > # This service waits until the kernel's entropy pool is initialized, and may be >> > # used as ordering barrier for service that require an initialized entropy >> > # pool. Since initialization can take a while on entropy-starved systems, let's >> > # increase the time-out substantially here. >> > >> > and from the man page >> > >> > This new seed is retrieved synchronously from the kernel, which means the >> > service will not complete start-up until the random pool is fully initialized. >> > >> > I might misread stuff, as you stated randomness handing in linux is complicated >> > but I really think that the initial idea behind that service was synchronisation... >> >> >> No you are correct, Ive been proven wrong. Did not know reading the >> seed would sync to the entropy pool being ready. >> >> > >> > >> >> > >> >> >> >> >> >> The point of waiting for "systemd-random-seed" is a substitute if you >> >> >> are in a really tough spot, >> >> >> and independent of what haveged does. >> >> >> >> >> > No, it's more than a substitute. it's a sync point. >> >> > It doesn't just load entropy into the kernel, it also blocks until the kernel reports >> >> > that /dev/urandom is ready >> >> >> >> Show me where? >> >> >> >> > >> >> > IOW the only way to make sure that haveged is started "at the right point" in a generic >> >> > way is to add that Before= >> >> > >> >> > That would allow any service that needs reliable randomness to be correctly synced >> >> > with haveged, even if they are not aware that haveged is here... >> >> >> >> Well, consider that systemd-random-seed would block for that (which it >> >> does not), >> >> then it does not matter *when* haveged is started, only that it is not >> >> blocked (and it is not). >> >> In other words, it would make no difference. >> >> >> That point still stands though. >> - haveged will be "startable" as early as systemd-random-seed, >> potentially before (does not need a filesystem). >> - even if it is started later, systemd-random-seed will block until >> haveged was running long enough to feed entropy to the kernel > > > not if there are other sources of entropy available and the kernel marks > urandom as ready before haveged is started > > more importantly, I am worried about "the promise". > A user installing haveged will want to rely on it to provide improved > randomness. by not syncing correctly, we are missing on that promise. > > Overall, I think it's good practice. Haveged should be aware of > systemd-random-seed and should be started before systemd-random-seed. > > Having it explicitely before is more readable, safer, and doesn't rely on a > kernel sync that is hard to understand. > > The more I think about it, the more I think you should add that... > It's just a line in a config file and it might really improve clarity, avoid > potential bugs and better guarantee that services needing high > quality randomness will have it properly. haveged is *not* a prefered source of entropy, it's there that VMs and embedded systems don't stall for minutes at bootup (I use that with a ConditionVirtualization to test my rootfs under qemu) So I'd prefer any other sources to feed the kernel, this is the software fallback.
Le dim. 7 juin 2020 à 22:14, Norbert Lange <nolange79@gmail.com> a écrit : > Am So., 7. Juni 2020 um 22:07 Uhr schrieb Jérémy ROSEN < > jeremy.rosen@smile.fr>: > > > > > > > > Le dim. 7 juin 2020 à 21:59, Norbert Lange <nolange79@gmail.com> a > écrit : > >> > >> Am So., 7. Juni 2020 um 21:47 Uhr schrieb Jérémy ROSEN < > jeremy.rosen@smile.fr>: > >> > > >> > > >> > > >> > Le dim. 7 juin 2020 à 21:42, Norbert Lange <nolange79@gmail.com> a > écrit : > >> >> > >> >> Am So., 7. Juni 2020 um 21:27 Uhr schrieb Jérémy ROSEN < > jeremy.rosen@smile.fr>: > >> >> > > >> >> > > >> >> > > >> >> > Le dim. 7 juin 2020 à 21:18, Norbert Lange <nolange79@gmail.com> > a écrit : > >> >> >> > >> >> >> Am So., 7. Juni 2020 um 21:05 Uhr schrieb Jérémy ROSEN < > jeremy.rosen@smile.fr>: > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > Le dim. 7 juin 2020 à 20:35, Norbert Lange <nolange79@gmail.com> > a écrit : > >> >> >> >> > >> >> >> >> Am So., 7. Juni 2020 um 12:35 Uhr schrieb Jérémy ROSEN < > jeremy.rosen@smile.fr>: > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > Le sam. 6 juin 2020 à 00:55, Norbert Lange < > nolange79@gmail.com> a écrit : > >> >> >> >> >> > >> >> >> >> >> Drop default dependencies, haveged needs nothing but > >> >> >> >> >> local sockets and /dev/random. > >> >> >> >> >> This allows the entropy to be available earlier. > >> >> >> >> >> > >> >> >> >> >> Signed-off-by: Norbert Lange <nolange79@gmail.com> > >> >> >> >> >> --- > >> >> >> >> >> package/haveged/haveged.service | 5 ++++- > >> >> >> >> >> 1 file changed, 4 insertions(+), 1 deletion(-) > >> >> >> >> >> > >> >> >> >> >> diff --git a/package/haveged/haveged.service > b/package/haveged/haveged.service > >> >> >> >> >> index 91035c6711..ed9f043a91 100644 > >> >> >> >> >> --- a/package/haveged/haveged.service > >> >> >> >> >> +++ b/package/haveged/haveged.service > >> >> >> >> >> @@ -1,10 +1,13 @@ > >> >> >> >> >> [Unit] > >> >> >> >> >> Description=Entropy Harvesting Daemon > >> >> >> >> >> Documentation=man:haveged(8) > >> >> >> >> >> +DefaultDependencies=no > >> >> >> >> >> +Conflicts=shutdown.target > >> >> >> >> >> +Before=sysinit.target shutdown.target > systemd-update-done.service > >> >> >> >> >> > >> >> >> >> > Since v243 (quoting systemd's NEWS file) : > >> >> >> >> > > >> >> >> >> > * systemd-random-seed.service is now a synchronization point > for full > >> >> >> >> > initialization of the kernel's entropy pool. > Services that require > >> >> >> >> > /dev/urandom to be correctly initialized should be > ordered after this > >> >> >> >> > service. > >> >> >> >> > > >> >> >> >> > so... in that case it might make sense to add > Before=systemd-random-seed.service > >> >> >> >> > (assuming that works. This a very early point, so it needs > some testing) > >> >> >> >> > >> >> >> >> > >> >> >> >> No, doesnt make sense, a "before" only means the service is > *started before*, > >> >> >> >> not the process did do anything worthwile. (That's the reason > for my > >> >> >> >> openssh patch BTW) > >> >> >> >> systemd-random-seed.service is a one-shot, so a "before" *that* > >> >> >> >> service means the dependants wait till it is finished. > >> >> >> >> > >> >> >> > (note that I don't really understand what haveged does, so I > might be completely wrong in my > >> >> >> > understanding) > >> >> >> > > >> >> >> > systemd-random-seed is the sync point, that means that any > service that needs > >> >> >> > random numbers should be ordered after random-seed. > >> >> >> > > >> >> >> > So, to me, it makes sense that we want to have haveged started > before that point. Thus > >> >> >> > having haveged ordered before random-seed. > >> >> >> > > >> >> >> > and I don't really understand your sentence above... > >> >> >> > if you add Before=systemd-random-seed, it's systemd-random-seed > that will wait for > >> >> >> > haveged to be started, not the other way round. (which seems to > be what you say ??) > >> >> >> > >> >> >> > >> >> >> Yes, systemd-random-seed will wait for haveged to be *startet* > (and > >> >> >> maybe its immediatly preempted), > >> >> >> but it takes several seconds after that till /dev/urandom is > "ready" > >> >> >> (what that means changed in the last few years multiple times) > >> >> >> > >> >> > ... yeah ... > >> >> >> > >> >> >> > > >> >> >> > now... if haveged needs some time to "do something usefull" > then it means that haveged > >> >> >> > is badly synchronised on startup. The Ready signal in systemd > is defined as "the point > >> >> >> > at which the service is able to render the service expected for > it' > >> >> >> > >> >> >> > >> >> >> Yes, but haveged does not send such a signal (and systemd only > wait > >> >> >> for that if the Type=notify). > >> >> > > >> >> > > >> >> > There is a workaround for that. Add an ExecStartPost that detects > readiness. > >> >> > (mentionning that for completeness sake, not sure if it's worth > doing here.) > >> >> > > >> >> >> > >> >> >> Further the service only feeds data to the kernel, and the only > valid > >> >> >> meaning of /dev/urandom is "ready" > >> >> >> comes from the kernel. > >> >> >> > >> >> > and random-seed will wait for that, so syncronisation will work > correctly > >> >> > >> >> Nope, it does not. It's a (poor) substitute to wait after some > entropy > >> >> was fed to the kernel. > >> >> > >> > comment at the bottom of random-seed.service: > >> > > >> > # This service waits until the kernel's entropy pool is initialized, > and may be > >> > # used as ordering barrier for service that require an initialized > entropy > >> > # pool. Since initialization can take a while on entropy-starved > systems, let's > >> > # increase the time-out substantially here. > >> > > >> > and from the man page > >> > > >> > This new seed is retrieved synchronously from the kernel, which > means the > >> > service will not complete start-up until the random pool is fully > initialized. > >> > > >> > I might misread stuff, as you stated randomness handing in linux is > complicated > >> > but I really think that the initial idea behind that service was > synchronisation... > >> > >> > >> No you are correct, Ive been proven wrong. Did not know reading the > >> seed would sync to the entropy pool being ready. > >> > >> > > >> > > >> >> > > >> >> >> > >> >> >> The point of waiting for "systemd-random-seed" is a substitute > if you > >> >> >> are in a really tough spot, > >> >> >> and independent of what haveged does. > >> >> >> > >> >> > No, it's more than a substitute. it's a sync point. > >> >> > It doesn't just load entropy into the kernel, it also blocks until > the kernel reports > >> >> > that /dev/urandom is ready > >> >> > >> >> Show me where? > >> >> > >> >> > > >> >> > IOW the only way to make sure that haveged is started "at the > right point" in a generic > >> >> > way is to add that Before= > >> >> > > >> >> > That would allow any service that needs reliable randomness to be > correctly synced > >> >> > with haveged, even if they are not aware that haveged is here... > >> >> > >> >> Well, consider that systemd-random-seed would block for that (which > it > >> >> does not), > >> >> then it does not matter *when* haveged is started, only that it is > not > >> >> blocked (and it is not). > >> >> In other words, it would make no difference. > >> > >> > >> That point still stands though. > >> - haveged will be "startable" as early as systemd-random-seed, > >> potentially before (does not need a filesystem). > >> - even if it is started later, systemd-random-seed will block until > >> haveged was running long enough to feed entropy to the kernel > > > > > > not if there are other sources of entropy available and the kernel marks > > urandom as ready before haveged is started > > > > more importantly, I am worried about "the promise". > > A user installing haveged will want to rely on it to provide improved > > randomness. by not syncing correctly, we are missing on that promise. > > > > Overall, I think it's good practice. Haveged should be aware of > > systemd-random-seed and should be started before systemd-random-seed. > > > > Having it explicitely before is more readable, safer, and doesn't rely > on a > > kernel sync that is hard to understand. > > > > The more I think about it, the more I think you should add that... > > It's just a line in a config file and it might really improve clarity, > avoid > > potential bugs and better guarantee that services needing high > > quality randomness will have it properly. > > haveged is *not* a prefered source of entropy, > it's there that VMs and embedded systems don't stall for minutes at bootup > (I use that with a ConditionVirtualization to test my rootfs under qemu) > > So I'd prefer any other sources to feed the kernel, this is the > software fallback. > Ok, but with that i'm not sure what the proper configurtion for buildroot in general should be... I mean... if it's not high grade entropy, it shouldn't credit the kernel entropy pool,and if the user is ok with unreliable entropy, systemd-random-seed is probably a faster way to get some. I'm a bit confused at this point. I'm not sure what the correct default should be.
Am So., 7. Juni 2020 um 22:19 Uhr schrieb Jérémy ROSEN <jeremy.rosen@smile.fr>: > > > > Le dim. 7 juin 2020 à 22:14, Norbert Lange <nolange79@gmail.com> a écrit : >> >> Am So., 7. Juni 2020 um 22:07 Uhr schrieb Jérémy ROSEN <jeremy.rosen@smile.fr>: >> > >> > >> > >> > Le dim. 7 juin 2020 à 21:59, Norbert Lange <nolange79@gmail.com> a écrit : >> >> >> >> Am So., 7. Juni 2020 um 21:47 Uhr schrieb Jérémy ROSEN <jeremy.rosen@smile.fr>: >> >> > >> >> > >> >> > >> >> > Le dim. 7 juin 2020 à 21:42, Norbert Lange <nolange79@gmail.com> a écrit : >> >> >> >> >> >> Am So., 7. Juni 2020 um 21:27 Uhr schrieb Jérémy ROSEN <jeremy.rosen@smile.fr>: >> >> >> > >> >> >> > >> >> >> > >> >> >> > Le dim. 7 juin 2020 à 21:18, Norbert Lange <nolange79@gmail.com> a écrit : >> >> >> >> >> >> >> >> Am So., 7. Juni 2020 um 21:05 Uhr schrieb Jérémy ROSEN <jeremy.rosen@smile.fr>: >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > Le dim. 7 juin 2020 à 20:35, Norbert Lange <nolange79@gmail.com> a écrit : >> >> >> >> >> >> >> >> >> >> Am So., 7. Juni 2020 um 12:35 Uhr schrieb Jérémy ROSEN <jeremy.rosen@smile.fr>: >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > Le sam. 6 juin 2020 à 00:55, Norbert Lange <nolange79@gmail.com> a écrit : >> >> >> >> >> >> >> >> >> >> >> >> Drop default dependencies, haveged needs nothing but >> >> >> >> >> >> local sockets and /dev/random. >> >> >> >> >> >> This allows the entropy to be available earlier. >> >> >> >> >> >> >> >> >> >> >> >> Signed-off-by: Norbert Lange <nolange79@gmail.com> >> >> >> >> >> >> --- >> >> >> >> >> >> package/haveged/haveged.service | 5 ++++- >> >> >> >> >> >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> >> >> >> >> >> >> >> >> >> >> diff --git a/package/haveged/haveged.service b/package/haveged/haveged.service >> >> >> >> >> >> index 91035c6711..ed9f043a91 100644 >> >> >> >> >> >> --- a/package/haveged/haveged.service >> >> >> >> >> >> +++ b/package/haveged/haveged.service >> >> >> >> >> >> @@ -1,10 +1,13 @@ >> >> >> >> >> >> [Unit] >> >> >> >> >> >> Description=Entropy Harvesting Daemon >> >> >> >> >> >> Documentation=man:haveged(8) >> >> >> >> >> >> +DefaultDependencies=no >> >> >> >> >> >> +Conflicts=shutdown.target >> >> >> >> >> >> +Before=sysinit.target shutdown.target systemd-update-done.service >> >> >> >> >> >> >> >> >> >> >> > Since v243 (quoting systemd's NEWS file) : >> >> >> >> >> > >> >> >> >> >> > * systemd-random-seed.service is now a synchronization point for full >> >> >> >> >> > initialization of the kernel's entropy pool. Services that require >> >> >> >> >> > /dev/urandom to be correctly initialized should be ordered after this >> >> >> >> >> > service. >> >> >> >> >> > >> >> >> >> >> > so... in that case it might make sense to add Before=systemd-random-seed.service >> >> >> >> >> > (assuming that works. This a very early point, so it needs some testing) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> No, doesnt make sense, a "before" only means the service is *started before*, >> >> >> >> >> not the process did do anything worthwile. (That's the reason for my >> >> >> >> >> openssh patch BTW) >> >> >> >> >> systemd-random-seed.service is a one-shot, so a "before" *that* >> >> >> >> >> service means the dependants wait till it is finished. >> >> >> >> >> >> >> >> >> > (note that I don't really understand what haveged does, so I might be completely wrong in my >> >> >> >> > understanding) >> >> >> >> > >> >> >> >> > systemd-random-seed is the sync point, that means that any service that needs >> >> >> >> > random numbers should be ordered after random-seed. >> >> >> >> > >> >> >> >> > So, to me, it makes sense that we want to have haveged started before that point. Thus >> >> >> >> > having haveged ordered before random-seed. >> >> >> >> > >> >> >> >> > and I don't really understand your sentence above... >> >> >> >> > if you add Before=systemd-random-seed, it's systemd-random-seed that will wait for >> >> >> >> > haveged to be started, not the other way round. (which seems to be what you say ??) >> >> >> >> >> >> >> >> >> >> >> >> Yes, systemd-random-seed will wait for haveged to be *startet* (and >> >> >> >> maybe its immediatly preempted), >> >> >> >> but it takes several seconds after that till /dev/urandom is "ready" >> >> >> >> (what that means changed in the last few years multiple times) >> >> >> >> >> >> >> > ... yeah ... >> >> >> >> >> >> >> >> > >> >> >> >> > now... if haveged needs some time to "do something usefull" then it means that haveged >> >> >> >> > is badly synchronised on startup. The Ready signal in systemd is defined as "the point >> >> >> >> > at which the service is able to render the service expected for it' >> >> >> >> >> >> >> >> >> >> >> >> Yes, but haveged does not send such a signal (and systemd only wait >> >> >> >> for that if the Type=notify). >> >> >> > >> >> >> > >> >> >> > There is a workaround for that. Add an ExecStartPost that detects readiness. >> >> >> > (mentionning that for completeness sake, not sure if it's worth doing here.) >> >> >> > >> >> >> >> >> >> >> >> Further the service only feeds data to the kernel, and the only valid >> >> >> >> meaning of /dev/urandom is "ready" >> >> >> >> comes from the kernel. >> >> >> >> >> >> >> > and random-seed will wait for that, so syncronisation will work correctly >> >> >> >> >> >> Nope, it does not. It's a (poor) substitute to wait after some entropy >> >> >> was fed to the kernel. >> >> >> >> >> > comment at the bottom of random-seed.service: >> >> > >> >> > # This service waits until the kernel's entropy pool is initialized, and may be >> >> > # used as ordering barrier for service that require an initialized entropy >> >> > # pool. Since initialization can take a while on entropy-starved systems, let's >> >> > # increase the time-out substantially here. >> >> > >> >> > and from the man page >> >> > >> >> > This new seed is retrieved synchronously from the kernel, which means the >> >> > service will not complete start-up until the random pool is fully initialized. >> >> > >> >> > I might misread stuff, as you stated randomness handing in linux is complicated >> >> > but I really think that the initial idea behind that service was synchronisation... >> >> >> >> >> >> No you are correct, Ive been proven wrong. Did not know reading the >> >> seed would sync to the entropy pool being ready. >> >> >> >> > >> >> > >> >> >> > >> >> >> >> >> >> >> >> The point of waiting for "systemd-random-seed" is a substitute if you >> >> >> >> are in a really tough spot, >> >> >> >> and independent of what haveged does. >> >> >> >> >> >> >> > No, it's more than a substitute. it's a sync point. >> >> >> > It doesn't just load entropy into the kernel, it also blocks until the kernel reports >> >> >> > that /dev/urandom is ready >> >> >> >> >> >> Show me where? >> >> >> >> >> >> > >> >> >> > IOW the only way to make sure that haveged is started "at the right point" in a generic >> >> >> > way is to add that Before= >> >> >> > >> >> >> > That would allow any service that needs reliable randomness to be correctly synced >> >> >> > with haveged, even if they are not aware that haveged is here... >> >> >> >> >> >> Well, consider that systemd-random-seed would block for that (which it >> >> >> does not), >> >> >> then it does not matter *when* haveged is started, only that it is not >> >> >> blocked (and it is not). >> >> >> In other words, it would make no difference. >> >> >> >> >> >> That point still stands though. >> >> - haveged will be "startable" as early as systemd-random-seed, >> >> potentially before (does not need a filesystem). >> >> - even if it is started later, systemd-random-seed will block until >> >> haveged was running long enough to feed entropy to the kernel >> > >> > >> > not if there are other sources of entropy available and the kernel marks >> > urandom as ready before haveged is started >> > >> > more importantly, I am worried about "the promise". >> > A user installing haveged will want to rely on it to provide improved >> > randomness. by not syncing correctly, we are missing on that promise. >> > >> > Overall, I think it's good practice. Haveged should be aware of >> > systemd-random-seed and should be started before systemd-random-seed. >> > >> > Having it explicitely before is more readable, safer, and doesn't rely on a >> > kernel sync that is hard to understand. >> > >> > The more I think about it, the more I think you should add that... >> > It's just a line in a config file and it might really improve clarity, avoid >> > potential bugs and better guarantee that services needing high >> > quality randomness will have it properly. >> >> haveged is *not* a prefered source of entropy, >> it's there that VMs and embedded systems don't stall for minutes at bootup >> (I use that with a ConditionVirtualization to test my rootfs under qemu) >> >> So I'd prefer any other sources to feed the kernel, this is the >> software fallback. > > > Ok, but with that i'm not sure what the proper configurtion for > buildroot in general should be... > > I mean... if it's not high grade entropy, it shouldn't credit the kernel entropy > pool,and if the user is ok with unreliable entropy, systemd-random-seed is > probably a faster way to get some. haveged is barely entropy, certainly not more than the kernel provides, it is a means to fake entropy. Gets you to boot faster. systemd-random-seed needs a filesystem to store stuff, does not credit the entropy pool (by default).. and won't help at all when booting the first time. I think what you have in mind is more like rng-tools, which feed real, quality entropy to the kernel. The user should pick what he needs, haveged will never give you better entropy over the kernel or real HW sources, systemd-random-seed will not let you boot faster (by default). Norbert
Hei hei, I'd like to hook in, because I had that topic on my desk lately (although not with buildroot). On Sun, Jun 07, 2020 at 10:36:18PM +0200, Norbert Lange wrote: > > I mean... if it's not high grade entropy, it shouldn't credit the kernel entropy > > pool,and if the user is ok with unreliable entropy, systemd-random-seed is > > probably a faster way to get some. > > > haveged is barely entropy, certainly not more than the kernel > provides, it is a means to fake entropy. Gets you to boot faster. Well, the system can boot faster, because haveged provides entropy from unpredictable internal CPU states. It's not just another PRNG. > systemd-random-seed needs a filesystem to store stuff, does not credit > the entropy pool (by default).. and won't help at all when booting the > first time. > > I think what you have in mind is more like rng-tools, which feed real, > quality entropy to the kernel. rng-tools can not do that by itself, but needs a real HWRNG or something like jitterentropy-rng (which gets its entropy from CPU execution timing jitter). So rng-tools alone doesn't help you, especially if your hardware has no hwrng. > The user should pick what he needs, haveged will never give you better > entropy over the kernel or real HW sources, systemd-random-seed will > not let you boot faster (by default). I'm curious, where do you think the kernel gets entropy from? ;-) What you all might find interesting: newer OpenSSL versions, I think from some 1.1.1 bugfix release onwards block until the kernel has initialized its crng. The upcoming (not yet released) dropbear will do that, too. Both don't rely on /dev/urandom for that but on the getrandom(2) syscall IIRC. Without having looked in systemd source, I would guess they do something similar? So, it's complicated … ;-) Greets Alex
Le lun. 8 juin 2020 à 10:38, Alexander Dahl <post@lespocky.de> a écrit : > Hei hei, > > I'd like to hook in, because I had that topic on my desk lately > (although not with buildroot). > > On Sun, Jun 07, 2020 at 10:36:18PM +0200, Norbert Lange wrote: > > > I mean... if it's not high grade entropy, it shouldn't credit the > kernel entropy > > > pool,and if the user is ok with unreliable entropy, > systemd-random-seed is > > > probably a faster way to get some. > > > > > > haveged is barely entropy, certainly not more than the kernel > > provides, it is a means to fake entropy. Gets you to boot faster. > > Well, the system can boot faster, because haveged provides entropy > from unpredictable internal CPU states. It's not just another PRNG. > > Oh. I didn't know that... interesting So. haveged provides high quality entropy to the kernel. That entropy is probably credited (unlike systemd-random-seed) So it is even more important that it is ordered before systemd-random-seed. > systemd-random-seed needs a filesystem to store stuff, does not credit > > the entropy pool (by default).. and won't help at all when booting the > > first time. > > > > I think what you have in mind is more like rng-tools, which feed real, > > quality entropy to the kernel. > > rng-tools can not do that by itself, but needs a real HWRNG or > something like jitterentropy-rng (which gets its entropy from CPU > execution timing jitter). So rng-tools alone doesn't help you, > especially if your hardware has no hwrng. > > > The user should pick what he needs, haveged will never give you better > > entropy over the kernel or real HW sources, systemd-random-seed will > > not let you boot faster (by default). > > I'm curious, where do you think the kernel gets entropy from? ;-) > > What you all might find interesting: newer OpenSSL versions, I think > from some 1.1.1 bugfix release onwards block until the kernel has > initialized its crng. The upcoming (not yet released) dropbear will > do that, too. Both don't rely on /dev/urandom for that but on the > getrandom(2) syscall IIRC. Without having looked in systemd source, I > would guess they do something similar? > > Yes it's exactly that. systemd-random-seed will block until urng is ready so other services don't have to do that themselves (it makes sense for dropbear/openssl to do that themselves anyway, for the non-systemd case, but in a systemd-based distro, they won't wait because systemd-random-seed will already have done the waiting) So at this point, I am more and more convinced that haveged must be ordered before systemd-random-seed. Not doing so is incorrect. At best it will work by luck and at worst the entropy provided by haveged will arrive too late. On a read-only filesystem, systemd-random-seed will not read the file and feed entropy (which is not credited anyway) but it will still block the boot and thus ensure that any "normal" (post sysinit) daemon will have proper urng. Please add the Before= it has no ill effect AFAICT and not doing so might prevent faster boots in the very cases where you try to avoid it. Regards. Jeremy > So, it's complicated … ;-) > > Greets > Alex > > -- > /"\ 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) > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot >
Hello Jérémy, Norbert, Alexander, On Mon, 8 Jun 2020 16:14:00 +0200, Jérémy ROSEN <jeremy.rosen@smile.fr> wrote: > Le lun. 8 juin 2020 à 10:38, Alexander Dahl <post@lespocky.de> a écrit : > > > Hei hei, > > > > I'd like to hook in, because I had that topic on my desk lately > > (although not with buildroot). > > > > On Sun, Jun 07, 2020 at 10:36:18PM +0200, Norbert Lange wrote: > > > > I mean... if it's not high grade entropy, it shouldn't credit the > > kernel entropy > > > > pool,and if the user is ok with unreliable entropy, > > systemd-random-seed is > > > > probably a faster way to get some. > > > > > > > > > haveged is barely entropy, certainly not more than the kernel > > > provides, it is a means to fake entropy. Gets you to boot faster. > > > > Well, the system can boot faster, because haveged provides entropy > > from unpredictable internal CPU states. It's not just another PRNG. > > > > Oh. I didn't know that... interesting > > So. haveged provides high quality entropy to the kernel. > That entropy is probably credited (unlike systemd-random-seed) > So it is even more important that it is ordered before systemd-random-seed. > > > systemd-random-seed needs a filesystem to store stuff, does not credit > > > the entropy pool (by default).. and won't help at all when booting the > > > first time. > > > > > > > > I think what you have in mind is more like rng-tools, which feed real, > > > quality entropy to the kernel. > > > > rng-tools can not do that by itself, but needs a real HWRNG or > > something like jitterentropy-rng (which gets its entropy from CPU > > execution timing jitter). So rng-tools alone doesn't help you, > > especially if your hardware has no hwrng. > > > > > The user should pick what he needs, haveged will never give you better > > > entropy over the kernel or real HW sources, systemd-random-seed will > > > not let you boot faster (by default). > > > > I'm curious, where do you think the kernel gets entropy from? ;-) > > > > What you all might find interesting: newer OpenSSL versions, I think > > from some 1.1.1 bugfix release onwards block until the kernel has > > initialized its crng. The upcoming (not yet released) dropbear will > > do that, too. Both don't rely on /dev/urandom for that but on the > > getrandom(2) syscall IIRC. Without having looked in systemd source, I > > would guess they do something similar? > > > > Yes it's exactly that. systemd-random-seed will block until urng is ready > so > other services don't have to do that themselves (it makes sense for > dropbear/openssl to do that themselves anyway, for the non-systemd case, > but in a systemd-based distro, they won't wait because systemd-random-seed > will already have done the waiting) > > So at this point, I am more and more convinced that haveged must be > ordered before systemd-random-seed. Not doing so is incorrect. At best > it will work by luck and at worst the entropy provided by haveged will > arrive > too late. > > On a read-only filesystem, systemd-random-seed will not read the file and > feed > entropy (which is not credited anyway) but it will still block the boot and > thus > ensure that any "normal" (post sysinit) daemon will have proper urng. > > Please add the Before= it has no ill effect AFAICT and not doing so might > prevent faster boots in the very cases where you try to avoid it. Did not follow the thread in detail, but did a quick search for haveged and systemd, found two relevant hits [1], [2], debian (and other) had 'After=systemd-random-seed.service' but dropped it leaving only: After=apparmor.service systemd-tmpfiles-setup.service Before=sysinit.target shutdown.target Regards, Peter [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938939 [2] https://salsa.debian.org/debian/haveged/-/merge_requests/1?commit_id=f92a246e53de88a346a2fb6dc770a624f0660bef > > Regards. > Jeremy > > > > > So, it's complicated … ;-) > > > > Greets > > Alex > > > > -- > > /"\ 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) > > _______________________________________________ > > buildroot mailing list > > buildroot@busybox.net > > http://lists.busybox.net/mailman/listinfo/buildroot > > > >
Thx. an After= would indeed be completely wrong (and it did cause a multi minute boot-delay and was removed. Unfortunately, apart from that there is no real rational about why this After= was added in the first place and it is not related to our discussion (we want to add a Before=) Thx for the search, though... Le lun. 8 juin 2020 à 23:34, Peter Seiderer <ps.report@gmx.net> a écrit : > Hello Jérémy, Norbert, Alexander, > > On Mon, 8 Jun 2020 16:14:00 +0200, Jérémy ROSEN <jeremy.rosen@smile.fr> > wrote: > > > Le lun. 8 juin 2020 à 10:38, Alexander Dahl <post@lespocky.de> a écrit : > > > > > Hei hei, > > > > > > I'd like to hook in, because I had that topic on my desk lately > > > (although not with buildroot). > > > > > > On Sun, Jun 07, 2020 at 10:36:18PM +0200, Norbert Lange wrote: > > > > > I mean... if it's not high grade entropy, it shouldn't credit the > > > kernel entropy > > > > > pool,and if the user is ok with unreliable entropy, > > > systemd-random-seed is > > > > > probably a faster way to get some. > > > > > > > > > > > > haveged is barely entropy, certainly not more than the kernel > > > > provides, it is a means to fake entropy. Gets you to boot faster. > > > > > > Well, the system can boot faster, because haveged provides entropy > > > from unpredictable internal CPU states. It's not just another PRNG. > > > > > > Oh. I didn't know that... interesting > > > > So. haveged provides high quality entropy to the kernel. > > That entropy is probably credited (unlike systemd-random-seed) > > So it is even more important that it is ordered before > systemd-random-seed. > > > > > systemd-random-seed needs a filesystem to store stuff, does not > credit > > > > the entropy pool (by default).. and won't help at all when booting > the > > > > first time. > > > > > > > > > > > > I think what you have in mind is more like rng-tools, which feed > real, > > > > quality entropy to the kernel. > > > > > > rng-tools can not do that by itself, but needs a real HWRNG or > > > something like jitterentropy-rng (which gets its entropy from CPU > > > execution timing jitter). So rng-tools alone doesn't help you, > > > especially if your hardware has no hwrng. > > > > > > > The user should pick what he needs, haveged will never give you > better > > > > entropy over the kernel or real HW sources, systemd-random-seed will > > > > not let you boot faster (by default). > > > > > > I'm curious, where do you think the kernel gets entropy from? ;-) > > > > > > What you all might find interesting: newer OpenSSL versions, I think > > > from some 1.1.1 bugfix release onwards block until the kernel has > > > initialized its crng. The upcoming (not yet released) dropbear will > > > do that, too. Both don't rely on /dev/urandom for that but on the > > > getrandom(2) syscall IIRC. Without having looked in systemd source, I > > > would guess they do something similar? > > > > > > Yes it's exactly that. systemd-random-seed will block until urng is > ready > > so > > other services don't have to do that themselves (it makes sense for > > dropbear/openssl to do that themselves anyway, for the non-systemd case, > > but in a systemd-based distro, they won't wait because > systemd-random-seed > > will already have done the waiting) > > > > So at this point, I am more and more convinced that haveged must be > > ordered before systemd-random-seed. Not doing so is incorrect. At best > > it will work by luck and at worst the entropy provided by haveged will > > arrive > > too late. > > > > On a read-only filesystem, systemd-random-seed will not read the file and > > feed > > entropy (which is not credited anyway) but it will still block the boot > and > > thus > > ensure that any "normal" (post sysinit) daemon will have proper urng. > > > > Please add the Before= it has no ill effect AFAICT and not doing so might > > prevent faster boots in the very cases where you try to avoid it. > > Did not follow the thread in detail, but did a quick search for > haveged and systemd, found two relevant hits [1], [2], debian > (and other) had 'After=systemd-random-seed.service' but dropped > it leaving only: > > After=apparmor.service systemd-tmpfiles-setup.service > Before=sysinit.target shutdown.target > > Regards, > Peter > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938939 > [2] > https://salsa.debian.org/debian/haveged/-/merge_requests/1?commit_id=f92a246e53de88a346a2fb6dc770a624f0660bef > > > > > Regards. > > Jeremy > > > > > > > > > So, it's complicated … ;-) > > > > > > Greets > > > Alex > > > > > > -- > > > /"\ 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) > > > _______________________________________________ > > > buildroot mailing list > > > buildroot@busybox.net > > > http://lists.busybox.net/mailman/listinfo/buildroot > > > > > > > > >
diff --git a/package/haveged/haveged.service b/package/haveged/haveged.service index 91035c6711..ed9f043a91 100644 --- a/package/haveged/haveged.service +++ b/package/haveged/haveged.service @@ -1,10 +1,13 @@ [Unit] Description=Entropy Harvesting Daemon Documentation=man:haveged(8) +DefaultDependencies=no +Conflicts=shutdown.target +Before=sysinit.target shutdown.target systemd-update-done.service [Service] ExecStart=/usr/sbin/haveged -F -w 1024 -v 1 SuccessExitStatus=143 [Install] -WantedBy=multi-user.target +WantedBy=sysinit.target
Drop default dependencies, haveged needs nothing but local sockets and /dev/random. This allows the entropy to be available earlier. Signed-off-by: Norbert Lange <nolange79@gmail.com> --- package/haveged/haveged.service | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)