public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Robin Roevens <robin.roevens@disroot.org>
To: development@lists.ipfire.org
Subject: Re: question about checking for HW RNG support on apu4 appliance
Date: Fri, 09 Sep 2022 13:17:04 +0200	[thread overview]
Message-ID: <366042f9e73fa612c42764791d10a4dc4ec0be84.camel@sicho.home> (raw)
In-Reply-To: <8F5A1DEE-E294-40EB-9ECE-6F20C21AF73C@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 6244 bytes --]

Hi

Michael Tremer schreef op vr 09-09-2022 om 11:31 [+0100]:
> Just for reference: https://bugzilla.ipfire.org/show_bug.cgi?id=12900
> 
> This is the current status of the discussion.

I see.. in that case I will leave it to professionals to figure out if
it is still needed :-)

> 
> > On 9 Sep 2022, at 09:26, Paul Simmons <mbatranch(a)gmail.com> wrote:
> > 
> > On 9/8/22 16:37, Robin Roevens wrote:
> > > Hi Michael
> > > 
> > > I was quickly looking into possibly submitting a patch for
> > > removing
> > > rngd from IPFire; and I figured I could remove the rng-tools
> > > package,
> > > initscript, udev rules etc.. from the source. But I wondered, do
> > > we
> > > handle actually removing those files from the system during an
> > > update?
> > > And if so, where/how do we do that ?
> 
> We just rm them in the updater. Like this:
> 
> https://git.ipfire.org/?p=ipfire-
> 2.x.git;a=blob;f=config/rootfiles/oldcore/169/update.sh;h=dc7a2a18abd
> 65d464c862f5a71d6b1a85295865b;hb=HEAD#l89

Good to know for possible future work then. Thanks

Regards
Robin

> 
> > > as keeping it installed on systems would possibly do more harm
> > > (with
> > > crappy hwgenerator) than good, would never be updated anymore and
> > > could
> > > possibly break on a future update.
> 
> Ideally we want to keep all systems, whether freshly installed or
> upgraded, as similar as possible.
> 
> This is never going to be 100% successful, but we can definitely
> delete files.
> 
> -Michael
> 
> > > 
> > > 
> > > Regards
> > > Robin
> > > 
> > > Michael Tremer schreef op do 08-09-2022 om 20:31 [+0100]:
> > > > Hello Robin,
> > > > 
> > > > > On 8 Sep 2022, at 20:16, Robin Roevens
> > > > > <robin.roevens(a)disroot.org>
> > > > > wrote:
> > > > > 
> > > > > Hi all
> > > > > 
> > > > > If I understand it correctly, when HW RNG is supported, the
> > > > > Random
> > > > > Number Generator Daemon (rngd) should be running ?
> > > > No, not quite.
> > > > 
> > > > > So in my Zabbix monitoring template for IPFire, I try to
> > > > > check if
> > > > > HW
> > > > > RNG is available and if so, I monitor the state of the rngd
> > > > > daemon.
> > > > > 
> > > > > Previously I had no HW RNG support on the apu4 appliance
> > > > > until a
> > > > > few
> > > > > core updates ago where this was introduced with a firmware
> > > > > update.
> > > > > So
> > > > > now the rngd daemon is automatically started on the
> > > > > appliance.
> > > > > 
> > > > > To know if HW RNG is supported, I currently check the
> > > > > contents of
> > > > > /proc/cpuinfo for the occurrence of the string "rdrand"
> > > > > (which
> > > > > seems a
> > > > > correct check on x86_64 machines) but this string was and
> > > > > still is
> > > > > not
> > > > > present on the apu4 appliance.
> > > > This is for an extended instruction set which was invented by
> > > > Intel.
> > > > 
> > > > This AMD processor doesn’t have it.
> > > > 
> > > > > So I was wondering if anyone knows how to correctly check if
> > > > > HW RNG
> > > > > support is available? So that this check works for all
> > > > > platforms.
> > > > This is very hard - if possible at all.
> > > > 
> > > > There are different kinds of sources for randomness. The first
> > > > one is
> > > > RDRAND as you pointed out and it is a processor instruction.
> > > > Just
> > > > because it is there, does not mean that it is being used.
> > > > 
> > > > Then, there are other devices which usually emulate a character
> > > > device that is to be found at /dev/hwrng. rngd has (had - see
> > > > below)
> > > > the job to copy any entropy from that device into the kernel.
> > > > 
> > > > So, the current status quo is that if /dev/hwrng exists, rngd
> > > > should
> > > > be running.
> > > > 
> > > > > Sidenote: This information (HW RNG support / rndg daemon
> > > > > state) was
> > > > > previously also available on the entropy page of the IPFire
> > > > > GUI,
> > > > > but it
> > > > > seems this info is now gone together with the now obsolete
> > > > > entropy
> > > > > graph. Was this intentional ? I assume that information is
> > > > > still
> > > > > relevant even when with the entropy value gone?
> > > > No, it is pretty much entirely irrelevant now. Even rngd is.
> > > > 
> > > > The reason is that it has been changed how the kernel deals
> > > > with
> > > > entropy. Many systems do not have very good sources if any at
> > > > all.
> > > > How can we tell if a source is good? We can’t. So why risk
> > > > using it?
> > > > 
> > > > Problems could be either broken implementations or backdoored
> > > > RNGs.
> > > > 
> > > > So, the kernel is now seeding its pool of randomness once it
> > > > boots.
> > > > That happens with RDRAND or RDSEED if available, or with any
> > > > other HW
> > > > RNG and is being mixed together if there are multiple sources.
> > > > Further sources are entropy from disk latency, keyboard strokes
> > > > and
> > > > so on. On servers, these are generally problematic sources.
> > > > 
> > > > The kernel will then use Blake2 and ChaCha20 to generate random
> > > > data
> > > > when needed based on that pool. The result will be mixed into
> > > > the
> > > > pool again and occasionally it is being reseeded automatically
> > > > in the
> > > > same way it was initially seeded.
> > > > 
> > > > So, I personally would prefer for us to drop rngd and just
> > > > trust the
> > > > kernel that it does its job right. This way seems to be the
> > > > most
> > > > sensical and allows us to ignore any dependencies on (crappy)
> > > > HW
> > > > RNGs.
> > > > 
> > > > All systems will always have the same quality of randomness.
> > > > 
> > > > Hope this helps.
> > > > 
> > > > -Michael
> > > > 
> > > > > Thanks
> > > > > 
> > > > > Robin
> > > > > 
> > > > > -- 
> > > > > Dit bericht is gescanned op virussen en andere gevaarlijke
> > > > > inhoud door MailScanner en lijkt schoon te zijn.
> > > > > 
> > > > 
> > I have an external RNG device that performs VERY well, and object
> > to the removal of rng-tools.
> > 
> > Paul
> > 
> > -- 
> > It's just a willerwont - it will, or it won't. -- H D Guenther
> 
> 

-- 
Dit bericht is gescanned op virussen en andere gevaarlijke
inhoud door MailScanner en lijkt schoon te zijn.


      reply	other threads:[~2022-09-09 11:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-08 19:16 Robin Roevens
2022-09-08 19:31 ` Michael Tremer
2022-09-08 20:12   ` Robin Roevens
2022-09-08 21:37   ` Robin Roevens
2022-09-09  8:26     ` Paul Simmons
2022-09-09 10:31       ` Michael Tremer
2022-09-09 11:17         ` Robin Roevens [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=366042f9e73fa612c42764791d10a4dc4ec0be84.camel@sicho.home \
    --to=robin.roevens@disroot.org \
    --cc=development@lists.ipfire.org \
    /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