[Buildroot] [PATCH] package/haveged: Allow service to run early

[Buildroot] [PATCH] package/haveged: Allow service to run early

[Norbert Lange]

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
 
 [Service]
 ExecStart=/usr/sbin/haveged -F -w 1024 -v 1
 SuccessExitStatus=143
 
 [Install]
-WantedBy=multi-user.target
+WantedBy=sysinit.target
-- 
2.26.2

[Buildroot] [PATCH] package/haveged: Allow service to run early

[Thomas Petazzoni]

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



-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH] package/haveged: Allow service to run early

[Jérémy ROSEN]

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 at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>


-- 
[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 at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200607/ae7af58a/attachment.html>

[Buildroot] [PATCH] package/haveged: Allow service to run early

[Norbert Lange]

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

[Buildroot] [PATCH] package/haveged: Allow service to run early

[Jérémy ROSEN]

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 at 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
>


-- 
[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 at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200607/76b40797/attachment.html>

[Buildroot] [PATCH] package/haveged: Allow service to run early

[Norbert Lange]

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 at smile.fr
>   +33 6 88 25 87 42
>  http://www.smile.eu

Norbert

[Buildroot] [PATCH] package/haveged: Allow service to run early

[Jérémy ROSEN]

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 at 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 at 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 at smile.fr
> >   +33 6 88 25 87 42
> >  http://www.smile.eu
>
> Norbert
>


-- 
[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 at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200607/d2fc5b36/attachment.html>

[Buildroot] [PATCH] package/haveged: Allow service to run early

[Norbert Lange]

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.

[Buildroot] [PATCH] package/haveged: Allow service to run early

[Jérémy ROSEN]

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 at 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 at 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 at 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.
>


-- 
[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 at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200607/6985a28e/attachment.html>

[Buildroot] [PATCH] package/haveged: Allow service to run early

[Norbert Lange]

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

[Buildroot] [PATCH] package/haveged: Allow service to run early

[Jérémy ROSEN]

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 at 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 at 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 at 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 at 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
>


-- 
[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 at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200607/43b99679/attachment.html>

[Buildroot] [PATCH] package/haveged: Allow service to run early

[Norbert Lange]

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.

[Buildroot] [PATCH] package/haveged: Allow service to run early

[Jérémy ROSEN]

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 at 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 at 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 at 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 at 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 at smile.fr>:
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > Le sam. 6 juin 2020 ? 00:55, Norbert Lange <
> nolange79 at 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.
-- 
[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 at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200607/83b9c7e0/attachment.html>

[Buildroot] [PATCH] package/haveged: Allow service to run early

[Norbert Lange]

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

[Buildroot] [PATCH] package/haveged: Allow service to run early

[Alexander Dahl]

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

-- 
/"\ 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200608/7ae2d73a/attachment.asc>

[Buildroot] [PATCH] package/haveged: Allow service to run early

[Jérémy ROSEN]

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 at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>


-- 
[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 at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200608/daa97438/attachment.html>

[Buildroot] [PATCH] package/haveged: Allow service to run early

[Peter Seiderer]

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 at busybox.net
> > http://lists.busybox.net/mailman/listinfo/buildroot
> >  
> 
> 

[Buildroot] [PATCH] package/haveged: Allow service to run early

[Jérémy ROSEN]

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 at busybox.net
> > > http://lists.busybox.net/mailman/listinfo/buildroot
> > >
> >
> >
>
>

-- 
[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 at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200609/2121d8fb/attachment.html>