Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH v2] package/haveged: set write_wakeup_threshold to 2048
Date: Mon, 25 Jul 2022 10:58:44 +0200	[thread overview]
Message-ID: <20220725105844.08c153eb@windsurf> (raw)
In-Reply-To: <20210412164733.17098-1-matthew.weber@rockwellcollins.com>

Hello Matt,

On Mon, 12 Apr 2021 11:47:33 -0500
Matt Weber <matthew.weber@rockwellcollins.com> wrote:

> Adjust the low water mark to wake-up the haveged daemon at the
> same time that rngd would wake-up when a hardware RNG is present.
> 
> This supports the theory that rngd then can't dominate the entropy
> pool. Instead haveged and rngd would complete to fill the pool.
> https://tails.boum.org/contribute/design/random/#index5h2

If I read this link correctly, it doesn't really say anything about
"aligning" the low water mark between haveged and rngd.

While not being random number experts, Arnout and I took advantage of
being in the same room today to have some (random?) discussion about
this patch. Our reasoning is that it is actually desirable to have a
lower low water mark for haveged than rngd.

If you have rngd and a hardware random number generator, using in
priority the hardware random number generator over haveged seems like a
good idea: it provides better random numbers, at less CPU cost. So it's
only if the hardware RNG is too slow that you may want haveged to be
involved and contribute to refilling the entropy pool. But if the
hardware RNG is fast enough compared to the "consumption" of random
numbers by the system, we don't really see why haveged should be
involved. It produces random numbers that are less "good", at at higher
CPU cost.

So overall the default of a low water mark of 2048 for rngd and 1024
for haveged seems to implement exactly what is desirable.

So for now I've marked the patch as Rejected. However should you have
other arguments to back your theory, we would be interested to hear
them and we can always revisit that decision.

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

      parent reply	other threads:[~2022-07-25  8:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-12 16:47 [Buildroot] [PATCH v2] package/haveged: set write_wakeup_threshold to 2048 Matt Weber
2021-04-24  9:01 ` Yann E. MORIN
2022-07-25  8:58 ` Thomas Petazzoni via buildroot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220725105844.08c153eb@windsurf \
    --to=buildroot@buildroot.org \
    --cc=matthew.weber@rockwellcollins.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=yann.morin.1998@free.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox