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