The rng-tools official repository (formerly part of the gkernel project on sourceforge)
License: GNU General Public License v2.0
This is a random number generator daemon.
It monitors a set of entropy sources, and supplies entropy from them to the system kernel's /dev/random machinery.
Operation is fully documented in the man page, and should be fairly intuitive
At a Hetzner server (AV101) I do get:
mr-fox ~ # rngd -l
Entropy sources that are available but disabled
1: TPM RNG Device (tpm)
Available and enabled entropy sources:
2: Intel RDRAND Instruction RNG (rdrand)
5: JITTER Entropy generator (jitter)
Available entropy sources that failed initalization:
0: Hardware RNG Device (hwrng)
mr-fox ~ # uname -a
Linux mr-fox 5.12.10 #9 SMP Thu Jun 10 17:47:42 CEST 2021 x86_64 AMD Ryzen 9 5950X 16-Core Processor AuthenticAMD GNU/Linux
mr-fox ~ # rngd -v
rngd 6.12
Copyright 2001-2004 Jeff Garzik
Copyright 2017 Neil Horman
Copyright (c) 2001 by Philipp Rumpf
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
While cleaning up the Buildroot patches against rng-tools 5, I found this patch / bug and wasn't sure if it had been resolved or still needed upstreaming. Thoughts?
Original bug with proposed patch
https://bugzilla.redhat.com/show_bug.cgi?id=892178
Buildroot patch we've been carrying as of version 5.
https://github.com/buildroot/buildroot/blob/master/package/rng-tools/0001-rngd-exit-code.patch
Rationale: Different distros use different locations for libs, (Arch for example uses /usr/lib/ which differs from the hardcoded value). The addition of a variable would provide more flexibility without the need to add an -O line as you pointed out in #58.
I'm forwarding an issue that was reported to Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847962
While it was reported against the Debian specific rng-tools implementation, it appears to be applicable to this implementation as well.
I have no idea or opinion on the validity of the bug/assertion, I'm only forwarding it.
Original bug report text (relevant parts anyway):
==============================================================
So I recently wrote some code to do the FIPS 140 tests, and though test
suites are good and all that, for something like this I also wanted to
run it against an independent implementation as a cross correlation on
sanity, and found the code in rng-tools which looked like it would be a
good candidate for that ...
Except they disagreed on a small, but large enough to be disturbing,
number of blocks for the Runs and Poker tests. At first glance we did
appear to be using the same thresholds, so clearly Something Was Wrong.
Happily (for me :), it turns out that my code was correct.
Also happily (for you, I hope ;), I've attached a patch that fixes two
bugs in the Runs test in rng-tools (which broke both tests).
==============================================================
The full .patch file can be downloaded here: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=847962;filename=0001-Fix-the-broken-FIPS-140-2-runs-test.patch;msg=5 (apparently I couldn't attach it here)
Below you'll find the diff of that patch.
diff --git a/fips.c b/fips.c
index a4d5e32..f1c82ca 100644
--- a/fips.c
+++ b/fips.c
@@ -93,11 +93,10 @@ static void fips_test_store(fips_ctx_t *ctx, unsigned int rng_data)
if (ctx->current_bit != ctx->last_bit) {
/* If runlength is 1-6 count it in correct bucket. 0's go in
runs[0-5] 1's go in runs[6-11] hence the 6*current_bit below */
- if (ctx->rlength < 5) {
- ctx->runs[ctx->rlength +
- (6 * ctx->current_bit)]++;
- } else {
- ctx->runs[5 + (6 * ctx->current_bit)]++;
+ if (ctx->rlength > 4) {
+ ctx->runs[5 + (6 * ctx->last_bit)]++;
+ } else if (ctx->rlength >= 0 ) {
+ ctx->runs[ctx->rlength + (6 * ctx->last_bit)]++;
}
/* Check if we just failed longrun test */rng-tools v6.10. Though rngd --list shows both hwrng and jitter, only jitter calls will be made to get entropy. Only after disabling the jitter dependency during the configuration step, I could successfully use the hwrng from OMAP3 (am335x SoC), linux kernel 5.4.x.
Any idea why I am observing such behaviour?
Hello! I think that it would be a great to have PKCS#11 tokens supported in rng-tools as one of the entropy sources. Here is a description of C_GenerateRandom function
https://www.cryptsoft.com/pkcs11doc/v220/group__SEC__11__15__RANDOM__NUMBER__GENERATION__FUNCTIONS.html
Jun 08 14:09:30 bumblebee-21c24c rngd[428]: libgcrypt not available. Disabling AES in JITTER source
Jun 08 14:09:30 bumblebee-21c24c rngd[428]: Enabling JITTER rng support
Jun 08 14:09:30 bumblebee-21c24c rngd[428]: Initalizing entropy source jitter
Jun 08 14:09:38 bumblebee-21c24c systemd[1]: Stopping Hardware RNG Entropy Gatherer Daemon...
Jun 08 14:09:48 bumblebee-21c24c rngd[428]: Error on pipe write: Bad file descriptor
Jun 08 14:09:53 bumblebee-21c24c rngd[428]: Error on pipe write: Bad file descriptor
Jun 08 14:09:53 bumblebee-21c24c rngd[428]: Closing thread 0
Jun 08 14:09:53 bumblebee-21c24c rngd[428]: Closing thread 1
Jun 08 14:09:53 bumblebee-21c24c systemd[1]: rngd.service: Succeeded.
Jun 08 14:09:53 bumblebee-21c24c systemd[1]: Stopped Hardware RNG Entropy Gatherer Daemon.
Hi, I'm the Alpine package maintainer for rng-tools and jitterentropy-library.
I've just packaged up rng-tools 6.13 and the compile is failing as follows:
rngd_jitter.c:70:2: warning: implicit declaration of function 'pthread_attr_seta
ffinity_np'; did you mean 'pthread_setaffinity_np'? [-Wimplicit-function-declara
tion]
70 | pthread_attr_setaffinity_np(&thread_ctx->notime_pthread_attr, cpusize,
cpus);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
| pthread_setaffinity_np
...
...
...
gcc -I/usr/include/ -I/usr/include/libusb-1.0 -I/usr/include/libxml2 -pth
read -Os -fomit-frame-pointer -pthread -Wl,--as-needed,-O1,--sort-common -o rng
d rngd-rngd.o rngd-rngd_entsource.o rngd-rngd_linux.o rngd-util.o rngd-ossl_help
ers.o rngd-rngd_nistbeacon.o rngd-rngd_rdrand.o rdrand_asm.o rngd-rngd_jitter.o rngd-rngd_rtlsdr.o librngd.a -ljitterentropy -largp -lrtlsdr -lusb-1.0 -ljansson -lcurl -lxml2 -lssl -lcrypto -ljitterentropy -largp
/usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../../x86_64-alpine-linux-musl/bin/ld: rngd-rngd_jitter.o: in function `rngd_notime_start':
rngd_jitter.c:(.text+0x9de): undefined reference to `pthread_attr_setaffinity_np'
collect2: error: ld returned 1 exit status
make: *** [Makefile:630: rngd] Error 1
So it appears that pthread_attr_setaffinity_np does not exist in the MUSL C library, it appears to a GLIBC-ism. I found another unrelated project which fixed the same issue (https://github.com/awslabs/aws-c-common/pull/766/files) by using pthread_setaffinity_np for both MUSL and BSD systems.
Could reproduce the issue on versions 6.7 and 6.8.
Here is the log output (journalctl -u rngd) for version 6.8 when issuing systemctl stop rngd:
Nov 11 13:14:33 localhost rngd[115]: Initializing available sources
Nov 11 13:14:33 localhost rngd[115]: Initializing entropy source hwrng
Nov 11 13:14:33 localhost rngd[115]: JITTER starts 4 threads
Nov 11 13:14:33 localhost rngd[115]: JITTER thread on cpu 0 wakes up for refill
Nov 11 13:14:33 localhost rngd[115]: JITTER thread on cpu 1 wakes up for refill
Nov 11 13:14:33 localhost rngd[115]: JITTER thread on cpu 2 wakes up for refill
Nov 11 13:14:33 localhost rngd[115]: JITTER thread on cpu 3 wakes up for refill
Nov 11 13:14:51 localhost rngd[115]: jent_read_entropy time on cpu 3 is 1.831008672600e+01 sec
Nov 11 13:14:51 localhost rngd[115]: Writing to pipe
Nov 11 13:14:51 localhost rngd[115]: DONE Writing to pipe with return 16535
Nov 11 13:14:51 localhost rngd[115]: JITTER thread on cpu 3 wakes up for refill
Nov 11 13:14:52 localhost rngd[115]: jent_read_entropy time on cpu 1 is 1.936495688200e+01 sec
Nov 11 13:14:52 localhost rngd[115]: Writing to pipe
Nov 11 13:14:52 localhost rngd[115]: DONE Writing to pipe with return 16535
Nov 11 13:14:52 localhost rngd[115]: JITTER thread on cpu 1 wakes up for refill
Nov 11 13:14:52 localhost rngd[115]: jent_read_entropy time on cpu 2 is 1.934331052800e+01 sec
Nov 11 13:14:52 localhost rngd[115]: Writing to pipe
Nov 11 13:14:52 localhost rngd[115]: DONE Writing to pipe with return 16535
Nov 11 13:14:52 localhost rngd[115]: JITTER thread on cpu 2 wakes up for refill
Nov 11 13:14:53 localhost rngd[115]: jent_read_entropy time on cpu 0 is 2.051571401800e+01 sec
Nov 11 13:14:53 localhost rngd[115]: Writing to pipe
Nov 11 13:14:53 localhost rngd[115]: DONE Writing to pipe with return 16535
Nov 11 13:14:53 localhost rngd[115]: JITTER thread on cpu 0 wakes up for refill
Nov 11 13:14:53 localhost rngd[115]: CPU Thread 0 is ready
Nov 11 13:14:53 localhost rngd[115]: CPU Thread 1 is ready
Nov 11 13:14:53 localhost rngd[115]: CPU Thread 2 is ready
Nov 11 13:14:53 localhost rngd[115]: CPU Thread 3 is ready
Nov 11 13:14:53 localhost rngd[115]: Initializing AES buffer
Nov 11 13:14:53 localhost rngd[115]: xread_jitter requests 16 bytes from pipe
Nov 11 13:14:53 localhost rngd[115]: xread_jitter gets 16 bytes
Nov 11 13:14:53 localhost rngd[115]: xread_jitter requests 128 bytes from pipe
Nov 11 13:14:53 localhost rngd[115]: xread_jitter gets 128 bytes
Nov 11 13:14:53 localhost rngd[115]: xread_jitter requests 16535 bytes from pipe
Nov 11 13:14:53 localhost rngd[115]: xread_jitter gets 16535 bytes
Nov 11 13:14:53 localhost rngd[115]: Enabling JITTER rng support
Nov 11 13:14:53 localhost rngd[115]: xread_jitter requests 4 bytes from pipe
Nov 11 13:14:53 localhost rngd[115]: xread_jitter gets 4 bytes
Nov 11 13:14:53 localhost rngd[115]: xread_jitter requests 4 bytes from pipe
Nov 11 13:14:53 localhost rngd[115]: xread_jitter gets 4 bytes
Nov 11 13:14:53 localhost rngd[115]: Initializing entropy source jitter
Nov 11 13:14:53 localhost rngd[194]: [[0;38;5;245m[[0;1;31m[[0;38;5;245mReading entropy from Hardware RNG Device[[0m
Nov 11 13:14:53 localhost systemd[1]: Started Hardware RNG Entropy Gatherer Daemon.
Nov 11 13:14:53 localhost rngd[194]: [[0;38;5;245m[[0;1;31m[[0;38;5;245mAdded 1153/4096 bits entropy[[0m
<...>
Nov 11 13:14:53 localhost rngd[194]: [[0;38;5;245m[[0;1;31m[[0;38;5;245mPool full at 4096, sleeping![[0m
Nov 11 13:28:29 localhost rngd[194]: [[0;38;5;245m[[0;1;31m[[0;38;5;245mChecking on done for thread 0[[0m
Nov 11 13:28:29 localhost systemd[1]: Stopping Hardware RNG Entropy Gatherer Daemon...
Nov 11 13:29:59 localhost systemd[1]: [[0;1;38;5;185m[[0;1;39m[[0;1;38;5;185mrngd.service: State 'stop-sigterm' timed out. Killing.[[0m
Nov 11 13:29:59 localhost systemd[1]: [[0;1;39m[[0;1;31m[[0;1;39mrngd.service: Killing process 194 (rngd) with signal SIGKILL.[[0m
Nov 11 13:29:59 localhost systemd[1]: [[0;1;38;5;185m[[0;1;39m[[0;1;38;5;185mrngd.service: Main process exited, code=killed, status=9/KILL[[0m
Nov 11 13:29:59 localhost systemd[1]: [[0;1;38;5;185m[[0;1;39m[[0;1;38;5;185mrngd.service: Failed with result 'timeout'.[[0m
Nov 11 13:29:59 localhost systemd[1]: Stopped Hardware RNG Entropy Gatherer Daemon.
System information:
Raspberry Pi 3 B+: Linux 4.14.95
/sys/class/misc/hw_random/rng_current: bcm2835
rngd.service:
[Unit]
Description=Hardware RNG Entropy Gatherer Daemon
DefaultDependencies=no
After=systemd-udev-settle.service
Before=sysinit.target shutdown.target
Conflicts=shutdown.target
[Service]
Type=forking
ExecStart=/usr/sbin/rngd -b -d -r /dev/hwrng
[Install]
WantedBy=multi-user.target
On version 6.6 the issue is not reproducible.
Hello! I've found that despite no one is reading from /dev/random, rngd is not sleeping as it should. rngd from rng-tools-5 is sleeping
fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
write(4, "3072\n", 5) = 5
close(4) = 0
ioctl(3, RNDADDENTROPY, 0x7ffcc63b59f0) = 0
poll([{fd=3, events=POLLOUT}], 1, -1
but rngd from master is not
ioctl(3, RNDADDENTROPY, 0x7ffe4b241c80) = 0
ioctl(3, RNDADDENTROPY, 0x7ffe4b241c80) = 0
ioctl(3, RNDADDENTROPY, 0x7ffe4b241c80) = 0
ioctl(3, RNDADDENTROPY, 0x7ffe4b241c80) = 0
ioctl(3, RNDADDENTROPY, 0x7ffe4b241c80) = 0
ioctl(3, RNDADDENTROPY, 0x7ffe4b241c80) = 0
ioctl(3, RNDADDENTROPY, 0x7ffe4b241c80) = 0
ioctl(3, RNDADDENTROPY, 0x7ffe4b241c80) = 0
ioctl(3, RNDADDENTROPY, 0x7ffe4b241c80) = 0
ioctl(3, RNDADDENTROPY, 0x7ffe4b241c80) = 0
ioctl(3, RNDADDENTROPY, 0x7ffe4b241c80) = 0
ioctl(3, RNDADDENTROPY, 0x7ffe4b241c80) = 0
ioctl(3, RNDADDENTROPY, 0x7ffe4b241c80) = 0
ioctl(3, RNDADDENTROPY, 0x7ffe4b241c80) = 0
ioctl(3, RNDADDENTROPY, 0x7ffe4b241c80) = 0
ioctl(3, RNDADDENTROPY, 0x7ffe4b241c80) = 0
ioctl(3, RNDADDENTROPY, 0x7ffe4b241c80) = 0
ioctl(3, RNDADDENTROPY, 0x7ffe4b241c80) = 0
ioctl(3, RNDADDENTROPY, 0x7ffe4b241c80) = 0
ioctl(3, RNDADDENTROPY, 0x7ffe4b241c80) = 0
ioctl(3, RNDADDENTROPY, 0x7ffe4b241c80) = 0
ioctl(3, RNDADDENTROPY, 0x7ffe4b241c80) = 0
I'm currently using rdrand source
Hi
Whilst looking at updating Alpine Linux's package of rng-tools to the new 6.11 release (once you get it out, no pressure!) I noticed 1 existing patch that is not in your Git tree. However there's no comments with the patch to understand if its still relevant, perhaps the filename give you an idea of its purpose?
The patch is here: https://git.alpinelinux.org/aports/tree/main/rng-tools/fix-textrels-on-PIC-x86.patch
Should this be upstreamed? If so, could this be done before the new release?
Hi,
The NIST entropy source doesn't seem to work anymore. I haven't looked too deeply but I noticed this:
Line 65 in 9fc873c
According to the timestamp of the last pulse, version 1.0 hasn't been active since 2018. To use version 2.0, it should look like this:
#define NIST_RECORD_URL "https://beacon.nist.gov/beacon/2.0/pulse/last"It also looks like there are some significant protocol/format changes between 1.0 and 2.0:
<record xmlns="http://beacon.nist.gov/record/0.1/">
<version>Version 1.0</version>
<frequency>60</frequency>
<timeStamp>1545840420</timeStamp>
<seedValue>
C2E5D63FA9B8276C1E4568BAE5B50C242856707519C295AEC71B99E72A0588CFEE2D79A7BC7ADD71D8BAC87FF753730D8DBDC171CE2DF6D0717C7E7AC45EE197
</seedValue>
<previousOutputValue>
2BF94CA75B69061C4440C606270AF37F2993782ED52FF80485BE221318465577A10D27AB93BEA19188BEFF14703BD723E356D4D5E9EEC420F1A64412A7A7FE6D
</previousOutputValue>
<signatureValue>
8D99A4E546A9DA0CA8F88F1C28EA411CF086125CE9B9728DDE0997E3C7EC8C32BA1CC764D745D372F79B5607E338003B3C1684CD1EA5972C06F1FB80AD363B77BF63E186C6E514DB39FFF12E190234FE12C4494D44D3A9BFE175AF04560F99DD1AA0724C5111ADC22268C6B8ADB4ECFCF0059266F673FA3F3EA02D404F505CCB6338808944E22C510871037993123C9932EBDF7802F45FBE280146121688BCBE08CE11DDE12B95CC57C028BDE2653C3612C754ACC2A7F8249F7E7EAC98C32354E6C06C9909C707A597AE7D99951B52F893F23167725347B5953E9416DE229F7E4B4361CC81D7D17A1DD779759A82CE48B4FF2774FFEE1AD33BA12493E2DA025D
</signatureValue>
<outputValue>
1A13A30ED048D48603F062993C69648C0FBF56DB5FE13FA3817511FFCD6AD1E7C81C7F82055DB20E18993678E9C71BBC1C4228C29C8320CE477DF1CE9945AF1E
</outputValue>
<statusCode>0</statusCode>
</record>{
"pulse" : {
"uri" : "https://beacon.nist.gov/beacon/2.0/chain/1/pulse/220394",
"version" : "Version 2.0",
"cipherSuite" : 0,
"period" : 60000,
"certificateId" : "5501e3d72bc42f3b96e16de4dcadcb16768e109662bd16d667d5fd9aee585af31bbdc5dd4f53592276064b53dddd76c8f3604b2a41db6e09f78f82bb5d6569e7",
"chainIndex" : 1,
"pulseIndex" : 220394,
"timeStamp" : "2018-12-26T16:07:00.000Z",
"localRandomValue" : "5FF1E44E70C019C42C77FA72D5228A2E663416D0778BFAC826F6B4757B634B076C50ED2D5A3975CBAF237C211A027EDAFF3E241A885D69EAA7237E2744E6C1E2",
"external" : {
"sourceId" : "00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
"statusCode" : 0,
"value" : "00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
},
"listValues" : [ {
"uri" : "https://beacon.nist.gov/beacon/2.0/chain/1/pulse/220393",
"type" : "previous",
"value" : "BA646CC4E7AE195D2C85E9D3AE9C9722B974F2134699D2493FA9E296C34995E8E471B329CB5F63235982CEE3395A749C618E61466847951D543ADC2FBAD23ECB"
}, {
"uri" : "https://beacon.nist.gov/beacon/2.0/chain/1/pulse/220387",
"type" : "hour",
"value" : "E75A5877169CC15220BCB11C8DA18159F14B880D85C5F3E9E462D010DC49BFCFE36D116D72C1D32A95AE8FFD9F0B6CE20DC073ED881BA36D5EF4687DC5B12328"
}, {
"uri" : "https://beacon.nist.gov/beacon/2.0/chain/1/pulse/219427",
"type" : "day",
"value" : "CDD24473B4427C3D3C856C66DF669444CE79D1262F94F4CC745E037AB781245A560E722514A62BEFF9ABE3B72EAFDF5EAE5A43EA806F5571B05EA04B8E7B02B7"
}, {
"uri" : "https://beacon.nist.gov/beacon/2.0/chain/1/pulse/183558",
"type" : "month",
"value" : "A9EDA202336C7DB1F05DE3BB24AAC1B54E98C9BD46CDF3D193FAE2BF4E0CD696AD6A743DFDF4DC48E5985BE329652E0A74816C7B69BBAF644FF0ACA352207FFB"
}, {
"uri" : "https://beacon.nist.gov/beacon/2.0/chain/1/pulse/1",
"type" : "year",
"value" : "7665F054F21B50DF62CD3E50AF8EB783E30D271B091DE051212D301E0E3D17FFCF0367DB41CFFD3C51E88BDE0B0621F49EB03435BC373D5D49480941A8B3547E"
} ],
"precommitmentValue" : "269908B840E79BE71991FFE62CEC4EBAEB3C050E93D71248CBB3E4358445FF0858D1D2CCF899A19B861C0C11CECCF16A0859AFD68E58481D4ADB1BE61F30E419",
"statusCode" : 0,
"signatureValue" : "17943D886DA8C7C24B9244BE5BD5DF281983D28CFFC8928846BC26529309C9724F6849F039591361DAF6B8DDAB6BC275CF86F448AF1800996889508D08D8AAAD19586E7A4B04FC4C97F1DA6D619EFAE2332150328C79C23BB9FE6A03E8FABDFF1AD66C5A8789D28AED4D25FF0FC5E88BE366280D7516A504EFD63706641828DDBF3C7082524F36E77EE9E07A9801D0C3BAD0646AA89DDDD8E2B4C0D7F8ED67664864B598E59ABF20CA8D761BB7B32B9A32698A22935D2C7127952625BB5580B2847FBBC8DFEF9039C4F5ACF12877E11121D031AED58217286F8DCF291C6E315773B42FF470B1AB587F787D44381F6E655DB903F1601B65AAC86BC2B7083AEEA9B3A27A5A208674056EFBB3C44629F333C810ADAD00E4FCFCE48E54F8FB7FC700598EA3E6497821736D24E5DA801A8B9DEC28A2B68E50FE13752270EB9CA7912B21EB6C104E78D105D0C0A635686B9A8CA26F87A1E63F0E411FD228F21B08BCD24660B305A4A42A9229154DE364FAB4DFF257A59DEA814034BF65C38A4C7AAEE79FEE5CC69010B1FE9759E23F192E218A19D9B8E95F6DD37D5D2F672E6CF0A0D457D9C619B1808274C2B0B2D3A3A7A8D8B1BB423FDDC56110784F2E0B7A23F065B56EC6E40234786DAB8C840E47811950331CBCFADEAD2EEE901D1C0A3A7E18D18A93089FC4E1CEFBA7571D2E47F10893D24BAD967FCA9DAEA67AD6B7F390AFC0",
"outputValue" : "0A8863E03E200F694CBA50F0F9A009B078555FE637B07CA2C0A0E4D564080173787B26376C4762377A139D1BCAA916A10419504850EB7CF91552A17FDCAA0463"
}
}It does not look good :)
rngd_linux.c: In function 'default_watermark':
rngd_linux.c:64:9: warning: unused variable 'l' [-Wunused-variable]
64 | size_t l;
| ^
rngd_linux.c:62:16: warning: unused variable 'ps' [-Wunused-variable]
62 | unsigned long ps;
| ^~
rngd_linux.c:61:19: warning: unused variable 'p' [-Wunused-variable]
61 | char psbuf[64], *p;
| ^
rngd_linux.c:61:7: warning: unused variable 'psbuf' [-Wunused-variable]
61 | char psbuf[64], *p;
| ^~~~~
rngd_linux.c:70:2: warning: ignoring return value of 'fscanf', declared with attribute warn_unused_result [-Wunused-result]
70 | fscanf(f,"%d", &wm);
| ^~~~~~~~~~~~~~~~~~~
rngd_linux.c: In function 'random_add_entropy':
rngd_linux.c:150:3: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result]
150 | write(random_fd, buf, size);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from rngd.c:53:
rngd.c: In function 'find_ent_src_idx':
rngd.c:361:31: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'int' [-Wformat=]
361 | message(LOG_CONS|LOG_INFO, "option index out of range: %lu\n", idx);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~
| |
| int
rngd.h:149:22: note: in definition of macro 'message'
149 | syslog((priority), fmt, ##args); \
| ^~~
rngd.c:361:61: note: format string is defined here
361 | message(LOG_CONS|LOG_INFO, "option index out of range: %lu\n", idx);
| ~~^
| |
| long unsigned int
| %u
In file included from rngd.c:53:
rngd.c:361:31: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'int' [-Wformat=]
361 | message(LOG_CONS|LOG_INFO, "option index out of range: %lu\n", idx);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~
| |
| int
rngd.h:152:20: note: in definition of macro 'message'
152 | fprintf(stderr, fmt, ##args); \
| ^~~
rngd.c:361:61: note: format string is defined here
361 | message(LOG_CONS|LOG_INFO, "option index out of range: %lu\n", idx);
| ~~^
| |
| long unsigned int
| %u
In file included from rngd.c:53:
rngd.c: In function 'parse_opt':
rngd.c:452:30: warning: format '%d' expects argument of type 'int', but argument 4 has type 'long int' [-Wformat=]
452 | message(LOG_CONS|LOG_INFO, "Option %s not found for source idx %d\n", optkey, idx);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~
| |
| long int
rngd.h:149:22: note: in definition of macro 'message'
149 | syslog((priority), fmt, ##args); \
| ^~~
rngd.c:452:67: note: format string is defined here
452 | message(LOG_CONS|LOG_INFO, "Option %s not found for source idx %d\n", optkey, idx);
| ~^
| |
| int
| %ld
In file included from rngd.c:53:
rngd.c:452:30: warning: format '%d' expects argument of type 'int', but argument 4 has type 'long int' [-Wformat=]
452 | message(LOG_CONS|LOG_INFO, "Option %s not found for source idx %d\n", optkey, idx);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~
| |
| long int
rngd.h:152:20: note: in definition of macro 'message'
152 | fprintf(stderr, fmt, ##args); \
| ^~~
rngd.c:452:67: note: format string is defined here
452 | message(LOG_CONS|LOG_INFO, "Option %s not found for source idx %d\n", optkey, idx);
| ~^
| |
| int
| %ld
In file included from rngd.c:53:
rngd.c: In function 'main':
rngd.c:831:31: warning: format '%d' expects argument of type 'int', but argument 4 has type 'long unsigned int' [-Wformat=]
831 | message(LOG_CONS|LOG_INFO, "\nEntropy rate: %6.4g Mbits/sec averaged over %d iterations for %6.4g seconds\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
832 | (sum_entropy/test_time/MEGABITS), test_iterations, test_time);
| ~~~~~~~~~~~~~~~
| |
| long unsigned int
rngd.h:149:22: note: in definition of macro 'message'
149 | syslog((priority), fmt, ##args); \
| ^~~
rngd.c:831:79: note: format string is defined here
831 | message(LOG_CONS|LOG_INFO, "\nEntropy rate: %6.4g Mbits/sec averaged over %d iterations for %6.4g seconds\n",
| ~^
| |
| int
| %ld
In file included from rngd.c:53:
rngd.c:831:31: warning: format '%d' expects argument of type 'int', but argument 4 has type 'long unsigned int' [-Wformat=]
831 | message(LOG_CONS|LOG_INFO, "\nEntropy rate: %6.4g Mbits/sec averaged over %d iterations for %6.4g seconds\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
832 | (sum_entropy/test_time/MEGABITS), test_iterations, test_time);
| ~~~~~~~~~~~~~~~
| |
| long unsigned int
rngd.h:152:20: note: in definition of macro 'message'
152 | fprintf(stderr, fmt, ##args); \
| ^~~
rngd.c:831:79: note: format string is defined here
831 | message(LOG_CONS|LOG_INFO, "\nEntropy rate: %6.4g Mbits/sec averaged over %d iterations for %6.4g seconds\n",
| ~^
| |
| int
| %ld
In file included from rngd.c:53:
rngd.c:834:31: warning: format '%d' expects argument of type 'int', but argument 4 has type 'long unsigned int' [-Wformat=]
834 | message(LOG_CONS|LOG_INFO, "\nEntropy rate: %6.4g Kbits/sec averaged over %d iterations for %6.4g seconds\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
835 | (sum_entropy/test_time/KILOBITS), test_iterations, test_time);
| ~~~~~~~~~~~~~~~
| |
| long unsigned int
rngd.h:149:22: note: in definition of macro 'message'
149 | syslog((priority), fmt, ##args); \
| ^~~
rngd.c:834:79: note: format string is defined here
834 | message(LOG_CONS|LOG_INFO, "\nEntropy rate: %6.4g Kbits/sec averaged over %d iterations for %6.4g seconds\n",
| ~^
| |
| int
| %ld
In file included from rngd.c:53:
rngd.c:834:31: warning: format '%d' expects argument of type 'int', but argument 4 has type 'long unsigned int' [-Wformat=]
834 | message(LOG_CONS|LOG_INFO, "\nEntropy rate: %6.4g Kbits/sec averaged over %d iterations for %6.4g seconds\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
835 | (sum_entropy/test_time/KILOBITS), test_iterations, test_time);
| ~~~~~~~~~~~~~~~
| |
| long unsigned int
rngd.h:152:20: note: in definition of macro 'message'
152 | fprintf(stderr, fmt, ##args); \
| ^~~
rngd.c:834:79: note: format string is defined here
834 | message(LOG_CONS|LOG_INFO, "\nEntropy rate: %6.4g Kbits/sec averaged over %d iterations for %6.4g seconds\n",
| ~^
| |
| int
| %ld
At top level:
rngd.c:156:3: warning: 'entropy_indexes' defined but not used [-Wunused-variable]
156 | } entropy_indexes;
| ^~~~~~~~~~~~~~~
rngd_rdrand.c: In function 'init_drng_entropy_source':
rngd_rdrand.c:356:3: warning: ignoring return value of 'read', declared with attribute warn_unused_result [-Wunused-result]
356 | read(fd, key, sizeof key);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from rngd_jitter.c:36:
rngd_jitter.c: In function 'xread_jitter':
rngd_jitter.c:156:33: warning: format '%d' expects argument of type 'int', but argument 3 has type 'ssize_t' {aka 'long int'} [-Wformat=]
156 | message(LOG_DAEMON|LOG_DEBUG, "xread_jitter requests %d bytes from pipe\n", need);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~
| |
| ssize_t {aka long int}
rngd.h:149:22: note: in definition of macro 'message'
149 | syslog((priority), fmt, ##args); \
| ^~~
rngd_jitter.c:156:57: note: format string is defined here
156 | message(LOG_DAEMON|LOG_DEBUG, "xread_jitter requests %d bytes from pipe\n", need);
| ~^
| |
| int
| %ld
In file included from rngd_jitter.c:36:
rngd_jitter.c:156:33: warning: format '%d' expects argument of type 'int', but argument 3 has type 'ssize_t' {aka 'long int'} [-Wformat=]
156 | message(LOG_DAEMON|LOG_DEBUG, "xread_jitter requests %d bytes from pipe\n", need);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~
| |
| ssize_t {aka long int}
rngd.h:152:20: note: in definition of macro 'message'
152 | fprintf(stderr, fmt, ##args); \
| ^~~
rngd_jitter.c:156:57: note: format string is defined here
156 | message(LOG_DAEMON|LOG_DEBUG, "xread_jitter requests %d bytes from pipe\n", need);
| ~^
| |
| int
| %ld
rngd_jitter.c:165:19: warning: pointer targets in passing argument 1 of 'gcrypt_mangle' differ in signedness [-Wpointer-sign]
165 | gcrypt_mangle(aes_buf, current->buf_sz);
| ^~~~~~~
| |
| char *
rngd_jitter.c:115:48: note: expected 'unsigned char *' but argument is of type 'char *'
115 | static inline int gcrypt_mangle(unsigned char *tmp, size_t size)
| ~~~~~~~~~~~~~~~^~~
In file included from rngd_jitter.c:36:
rngd_jitter.c:176:35: warning: format '%d' expects argument of type 'int', but argument 3 has type 'ssize_t' {aka 'long int'} [-Wformat=]
176 | message(LOG_DAEMON|LOG_DEBUG, "request of random data returns %d less than need %d\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
177 | request, need);
| ~~~~~~~
| |
| ssize_t {aka long int}
rngd.h:149:22: note: in definition of macro 'message'
149 | syslog((priority), fmt, ##args); \
| ^~~
rngd_jitter.c:176:68: note: format string is defined here
176 | message(LOG_DAEMON|LOG_DEBUG, "request of random data returns %d less than need %d\n",
| ~^
| |
| int
| %ld
In file included from rngd_jitter.c:36:
rngd_jitter.c:176:35: warning: format '%d' expects argument of type 'int', but argument 4 has type 'ssize_t' {aka 'long int'} [-Wformat=]
176 | message(LOG_DAEMON|LOG_DEBUG, "request of random data returns %d less than need %d\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
177 | request, need);
| ~~~~
| |
| ssize_t {aka long int}
rngd.h:149:22: note: in definition of macro 'message'
149 | syslog((priority), fmt, ##args); \
| ^~~
rngd_jitter.c:176:86: note: format string is defined here
176 | message(LOG_DAEMON|LOG_DEBUG, "request of random data returns %d less than need %d\n",
| ~^
| |
| int
| %ld
In file included from rngd_jitter.c:36:
rngd_jitter.c:176:35: warning: format '%d' expects argument of type 'int', but argument 3 has type 'ssize_t' {aka 'long int'} [-Wformat=]
176 | message(LOG_DAEMON|LOG_DEBUG, "request of random data returns %d less than need %d\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
177 | request, need);
| ~~~~~~~
| |
| ssize_t {aka long int}
rngd.h:152:20: note: in definition of macro 'message'
152 | fprintf(stderr, fmt, ##args); \
| ^~~
rngd_jitter.c:176:68: note: format string is defined here
176 | message(LOG_DAEMON|LOG_DEBUG, "request of random data returns %d less than need %d\n",
| ~^
| |
| int
| %ld
In file included from rngd_jitter.c:36:
rngd_jitter.c:176:35: warning: format '%d' expects argument of type 'int', but argument 4 has type 'ssize_t' {aka 'long int'} [-Wformat=]
176 | message(LOG_DAEMON|LOG_DEBUG, "request of random data returns %d less than need %d\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
177 | request, need);
| ~~~~
| |
| ssize_t {aka long int}
rngd.h:152:20: note: in definition of macro 'message'
152 | fprintf(stderr, fmt, ##args); \
| ^~~
rngd_jitter.c:176:86: note: format string is defined here
176 | message(LOG_DAEMON|LOG_DEBUG, "request of random data returns %d less than need %d\n",
| ~^
| |
| int
| %ld
In file included from rngd_jitter.c:36:
rngd_jitter.c:188:33: warning: format '%d' expects argument of type 'int', but argument 3 has type 'ssize_t' {aka 'long int'} [-Wformat=]
188 | message(LOG_DAEMON|LOG_DEBUG, "xread_jitter gets %d bytes\n", request);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~
| |
| ssize_t {aka long int}
rngd.h:149:22: note: in definition of macro 'message'
149 | syslog((priority), fmt, ##args); \
| ^~~
rngd_jitter.c:188:53: note: format string is defined here
188 | message(LOG_DAEMON|LOG_DEBUG, "xread_jitter gets %d bytes\n", request);
| ~^
| |
| int
| %ld
In file included from rngd_jitter.c:36:
rngd_jitter.c:188:33: warning: format '%d' expects argument of type 'int', but argument 3 has type 'ssize_t' {aka 'long int'} [-Wformat=]
188 | message(LOG_DAEMON|LOG_DEBUG, "xread_jitter gets %d bytes\n", request);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~
| |
| ssize_t {aka long int}
rngd.h:152:20: note: in definition of macro 'message'
152 | fprintf(stderr, fmt, ##args); \
| ^~~
rngd_jitter.c:188:53: note: format string is defined here
188 | message(LOG_DAEMON|LOG_DEBUG, "xread_jitter gets %d bytes\n", request);
| ~^
| |
| int
| %ld
rngd_jitter.c:150:18: warning: unused variable 'sleep' [-Wunused-variable]
150 | struct timespec sleep;
| ^~~~~
In file included from rngd_jitter.c:36:
rngd_jitter.c: In function 'thread_entropy_task':
rngd_jitter.c:290:34: warning: format '%d' expects argument of type 'int', but argument 3 has type 'ssize_t' {aka 'long int'} [-Wformat=]
290 | message(LOG_DAEMON|LOG_DEBUG, "DONE Writing to pipe with return %d\n", ret);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~
| |
| ssize_t {aka long int}
rngd.h:149:22: note: in definition of macro 'message'
149 | syslog((priority), fmt, ##args); \
| ^~~
rngd_jitter.c:290:69: note: format string is defined here
290 | message(LOG_DAEMON|LOG_DEBUG, "DONE Writing to pipe with return %d\n", ret);
| ~^
| |
| int
| %ld
In file included from rngd_jitter.c:36:
rngd_jitter.c:290:34: warning: format '%d' expects argument of type 'int', but argument 3 has type 'ssize_t' {aka 'long int'} [-Wformat=]
290 | message(LOG_DAEMON|LOG_DEBUG, "DONE Writing to pipe with return %d\n", ret);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~
| |
| ssize_t {aka long int}
rngd.h:152:20: note: in definition of macro 'message'
152 | fprintf(stderr, fmt, ##args); \
| ^~~
rngd_jitter.c:290:69: note: format string is defined here
290 | message(LOG_DAEMON|LOG_DEBUG, "DONE Writing to pipe with return %d\n", ret);
| ~^
| |
| int
| %ld
rngd_jitter.c:239:9: warning: unused variable 'need' [-Wunused-variable]
239 | size_t need;
| ^~~~
rngd_jitter.c: In function 'close_jitter_entropy_source':
rngd_jitter.c:489:5: warning: ignoring return value of 'read', declared with attribute warn_unused_result [-Wunused-result]
489 | read(pipefds[0], tmpbuf, 1024);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At top level:
rngd_jitter.c:75:12: warning: 'init_gcrypt' defined but not used [-Wunused-function]
75 | static int init_gcrypt(const void *key)
| ^~~~~~~~~~~
rngd_jitter.c:41:26: warning: 'ec' defined but not used [-Wunused-variable]
41 | static struct rand_data *ec = NULL;
| ^~
In file included from rngd_nistbeacon.c:54:
rngd_nistbeacon.c: In function 'get_nist_record':
rngd_nistbeacon.c:417:33: warning: format '%d' expects argument of type 'int', but argument 3 has type 'uint64_t' {aka 'long unsigned int'} [-Wformat=]
417 | message(LOG_DAEMON|LOG_DEBUG, "NIST: timestamp is %d, frequency is %d, tv_sec is %d\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
418 | block.timestamp, block.frequency, ct.tv_sec);
| ~~~~~~~~~~~~~~~
| |
| uint64_t {aka long unsigned int}
rngd.h:149:22: note: in definition of macro 'message'
149 | syslog((priority), fmt, ##args); \
| ^~~
rngd_nistbeacon.c:417:54: note: format string is defined here
417 | message(LOG_DAEMON|LOG_DEBUG, "NIST: timestamp is %d, frequency is %d, tv_sec is %d\n",
| ~^
| |
| int
| %ld
In file included from rngd_nistbeacon.c:54:
rngd_nistbeacon.c:417:33: warning: format '%d' expects argument of type 'int', but argument 5 has type '__time_t' {aka 'long int'} [-Wformat=]
417 | message(LOG_DAEMON|LOG_DEBUG, "NIST: timestamp is %d, frequency is %d, tv_sec is %d\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
418 | block.timestamp, block.frequency, ct.tv_sec);
| ~~~~~~~~~
| |
| __time_t {aka long int}
rngd.h:149:22: note: in definition of macro 'message'
149 | syslog((priority), fmt, ##args); \
| ^~~
rngd_nistbeacon.c:417:85: note: format string is defined here
417 | message(LOG_DAEMON|LOG_DEBUG, "NIST: timestamp is %d, frequency is %d, tv_sec is %d\n",
| ~^
| |
| int
| %ld
In file included from rngd_nistbeacon.c:54:
rngd_nistbeacon.c:417:33: warning: format '%d' expects argument of type 'int', but argument 3 has type 'uint64_t' {aka 'long unsigned int'} [-Wformat=]
417 | message(LOG_DAEMON|LOG_DEBUG, "NIST: timestamp is %d, frequency is %d, tv_sec is %d\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
418 | block.timestamp, block.frequency, ct.tv_sec);
| ~~~~~~~~~~~~~~~
| |
| uint64_t {aka long unsigned int}
rngd.h:152:20: note: in definition of macro 'message'
152 | fprintf(stderr, fmt, ##args); \
| ^~~
rngd_nistbeacon.c:417:54: note: format string is defined here
417 | message(LOG_DAEMON|LOG_DEBUG, "NIST: timestamp is %d, frequency is %d, tv_sec is %d\n",
| ~^
| |
| int
| %ld
In file included from rngd_nistbeacon.c:54:
rngd_nistbeacon.c:417:33: warning: format '%d' expects argument of type 'int', but argument 5 has type '__time_t' {aka 'long int'} [-Wformat=]
417 | message(LOG_DAEMON|LOG_DEBUG, "NIST: timestamp is %d, frequency is %d, tv_sec is %d\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
418 | block.timestamp, block.frequency, ct.tv_sec);
| ~~~~~~~~~
| |
| __time_t {aka long int}
rngd.h:152:20: note: in definition of macro 'message'
152 | fprintf(stderr, fmt, ##args); \
| ^~~
rngd_nistbeacon.c:417:85: note: format string is defined here
417 | message(LOG_DAEMON|LOG_DEBUG, "NIST: timestamp is %d, frequency is %d, tv_sec is %d\n",
| ~^
| |
| int
| %ld
In function 'get_nist_record',
inlined from 'refill_rand' at rngd_nistbeacon.c:120:6:
rngd_nistbeacon.c:432:2: warning: call to '_curl_easy_setopt_err_cb_data' declared with attribute warning: curl_easy_setopt expects a private data pointer as argument for this option [-Wattribute-warning]
432 | curl_easy_setopt(curl, CURLOPT_WRITEDATA, nist_rand_buf);
| ^
Here https://github.com/nhorman/rng-tools/blob/master/rngd.c#L218 the path to the opensc is hardcoded. It would be great if it would find it either automatically or be overridable with the ./configure script.
We have to patch it when packaging for a distribution where the libraries are in a different place: NixOS/nixpkgs#60247
Hi
It has been 9 months since the last release and there have been quite a number of important fixes/changes since then.
Could you publish a 6.11 release soon?
Thanks in advance
Dear @nhorman,
I see:
And:
Can you remove 2 bad tags?
rng-tools-6.9-r0.core2_64
Feb 25 05:08:14 qemux86-64 rngd[133]: Initializing available sources
Feb 25 05:08:14 qemux86-64 rngd[133]: [hwrng ]: Initialized
Feb 25 05:08:14 qemux86-64 rngd[133]: [rdrand]: Initialization Failed
Feb 25 05:08:14 qemux86-64 rngd[133]: [jitter]: Initializing AES buffer
Feb 25 05:08:31 qemux86-64 rngd[133]: [jitter]: Enabling JITTER rng support
Feb 25 05:08:39 qemux86-64 rngd[133]: [jitter]: Initialized
Warning: Journal has been rotated since unit was started. Log output is incompl
Hello!
Subj kinda breaks some of our packaging automation, so I'm wondering whether I should make an exception for this release only, or should permanently change scripts for future releases also.
Hi
I just saw those patches on the gentoo recipe
https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/rng-tools/rng-tools-6.7.ebuild
https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/rng-tools/files/test-for-argp.patch
https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/rng-tools/files/rng-tools-5-fix-textrels-on-PIC-x86.patch
https://bugs.gentoo.org/469962
can you check if they apply?
Thanks
Nick
Thanks
The rngd seems to allocate a buffer of buf_sz that must be filled by the Jitter RNG with data. Could you please help me understand why this buffer is required to be 16536 bytes in size per default? I am having the following considerations that would like to share:
entropy is in short supply during boot time and badly needed at that time - i.e. I think entropy data should be available as fast as possible
entropy at run time is less of a concern assuming a fully seeded RNG - i.e. if entropy data is not available at the precise microsecond of the request, but a couple of ticks later, I think it is harmless
entropy data in a buffer may be more of a challenge to manage than entropy generated at the time it is needed
The filling of the some 16kBytes during startup takes some time on some systems. As the rngd is intended to be started during early user space boot to support subsequent crypto libraries and the seeding of their RNGs, would it make sense to reduce the buffer size?
As I am not fully sure about the reason of having such a buffer, could you please help me understand the purpose of the buffer? I would have expected that data from the Jitter RNG is generated on the fly.
Lastly, the function thread_entropy_task seems to allocate tmpbuf on the stack that is filled with the data from the Jitter RNG. Wouldn't it make sense to zeroize it before the free() operation to ensure the sensitive data is gone? Similarly, wouldn't it be good to zeroize openssl_mangle():ciphertext if my interpretation is correct that it contains the AES cipher text that would be used as entropy data (I understand that this buffer is stack buffer, so it may not matter too much after all)?
Thank you very much
Hi,
Our project cross-compiles rng-tools (much thanks, BTW), and the gcc 4.8.3 toolchain assembler does not recognize the rdseed instruction ...
/home/dev/astlinux/trunk/output/host/usr/bin/x86_64-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -I. -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -pipe -Os -MT rdrand_asm.o -MD -MP -MF .deps/rdrand_asm.Tpo -c -o rdrand_asm.o rdrand_asm.S
rdrand_asm.S: Assembler messages:
rdrand_asm.S:61: Error: no such instruction: `rdseed %rax'
make[3]: *** [rdrand_asm.o] Error 1
We worked around this by patching configure.ac
https://github.com/astlinux-project/astlinux/blob/master/package/rng-tools/rng-tools-0001-disable-RDRAND.patch
REQUEST: please add a --without-rdrand configure option so we don't have to maintain the patch.
Followup, more interestingly, we looked for alternatives for a rdrand-rng and discovered an elegant kernel patch by the VMware "photon" folks:
vmware/photon@d694d7b
The referenced patch for Linux 4.4 and 4.9 was trivial to back-port to our 3.16 kernel, and works perfectly with rng-tools 6.3.1. At least for our use case, it is more desirable to have rdrand as a 0: Hardware RNG Device. Also no need for libgcrypt for non-aes-ni CPU's.
Possibly others will find the referenced rdrand-rng kernel module useful wrt rng-tools, as we have.
RDRAND isn’t (in most circumstances) an entropy source, per say. It’s an excellent DRBG with security strength 128, so you should be able to claim a 128-bit computational resistance to attack for the outputs of the call. This isn't really the same thing as "entropy", and in particular, this is a problem for any system trying to create larger keys (say making a 256-bit AES key that you wanted to claim actually had a full 256 bit strength).
This also applies to rngd’s behavior when using RDRAND, as by default the kernel is told that the input RDRAND output should be considered full entropy. (This is surely incorrect, no matter what the underlying attack model is!)
In the case where an attacker can directly query RDRAND any time they choose to, it's not appropriate to claim any entropy (as compared to computational resistance to attack). In the case where the attacker can be denied this access, then the appropriate amount of entropy to credit is on the order of 128 bits per 2^14 bytes. (This is two seed intervals of 128-bit DRBG "generate" calls). This is as a consequence of the reseed interval).
Hello. It would be great to have a configuration parameter that would prohibit the output of hourly statistics. RSysLog and Journald is full of statistics output for this service. If I can disable "rngd" logging in RSysLog, then Journald still drags these logs to itself. I am very disturbed by the hourly output of "rngd" statistics.
Line 143 in 199fb82
This line looks incorrect.
shouldn't it be:
bw_avg = (1000000.0 * blocksize * stat->sum) / stat->num_samples;
Hello,
This code from rngd_nistbeacon.c will cause NULL-deref in an unlikely event of memory allocation failure:
static void get_json_byte_array(json_t *parent, char *key, char **val, uint32_t *len)
{
...
newval = malloc(rawlen/2);
...
newval[j] = tmpval;
Unfortunately, I do not see how to fix this easily. In case we just add if (!newval) a NULL-deref will happen later on accessing NULL pointed by static struct nist_data_block block char * fields.
I am experiencing times of rngd saturating all 4 cores of my RPi4B and am wondering what is the cause. I see nothing in the logs nor in the journal. It happened when the headless box was just sitting idle just now. Other times, it can go for days without issue.
Distro: Arch ARM aarch64
rng-tools: 6.13-1
Note that the failure around opensc-pkcs11.so is not to blame. If I install opensc the problem will still occur.
% systemctl status rngd
● rngd.service - Hardware RNG Entropy Gatherer Daemon
Loaded: loaded (/usr/lib/systemd/system/rngd.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2021-05-19 10:12:09 EDT; 1 months 10 days ago
Main PID: 273 (rngd)
Tasks: 5 (limit: 8757)
CPU: 1min 4.169s
CGroup: /system.slice/rngd.service
└─273 /usr/bin/rngd -f
Jun 29 11:47:39 workbench rngd[273]: Initializing available sources
Jun 29 11:47:39 workbench rngd[273]: [hwrng ]: Initialized
Jun 29 11:47:39 workbench rngd[273]: [rndr ]: No HW SUPPORT
Jun 29 11:47:39 workbench rngd[273]: [rndr ]: Initialization Failed
Jun 29 11:47:39 workbench rngd[273]: [jitter]: Initializing AES buffer
Jun 29 11:47:45 workbench rngd[273]: [jitter]: Enabling JITTER rng support
Jun 29 11:47:45 workbench rngd[273]: [jitter]: Initialized
Jun 29 11:47:45 workbench rngd[273]: [pkcs11]: PKCS11 Engine /usr/lib64/opensc-pkcs11.so Error: No such file or directory
Jun 29 11:47:45 workbench rngd[273]: [pkcs11]: Initialization Failed
Jun 29 11:47:45 workbench rngd[273]: [rtlsdr]: Initialization Failed
Seems that after commit aee7070 the rngtestjitter.sh reports a failure, but the problem has always been there (no ./rngd).
test-suite.log contains
FAIL: rngtestjitter.sh
======================
./rngtestjitter.sh: line 4: ./rngd: No such file or directory
FAIL rngtestjitter.sh (exit status: 1)
RDSEED does produce entropy, and it is reasonable to credit it at full (or nearly full) entropy.
In the code that reads from RDSEED ("x86_rdseed_or_rdrand_bytes"), after RDSEED is called, if the carry bit is not set then the code falls back to RDRAND.
As I pointed out in issue #50 RDRAND isn't a reasonable source for entropy (though it is a reasonable source for computational resistance to attack with a security strength of 128 bits). It would be useful to retry the RDSEED operation, as suggested in section 5.3.1.1. and 5.3.1.2 of Intel's DRNG Implementation Guide.
I suggest retrying up to 100 times, and then falling back to RDRAND. In all cases, data from RDRAND should not be credited as containing full entropy.
Lately my system has been hanging on shutdown for 1:30, which indicated some process was timing out before systemd kills it. I booted up my system with loglevel=7 and without the quiet for kernel parameters and took the following screenshot on shutdown.
(sorry for the blurriness)
This happens often when I do a shutdown now or sudo shutdown now from a terminal (Alacritty) in sway (Wayland compositor) as a regular user with sudo privileges, but if I do a fresh login on tty1 and immediately do a shutdown now, it usually doesn't have a problem shutting down within a few seconds.
I'm pretty sure rngd is the culprit because if I stop the service before shutting down, then the system has no problems shutting down within a few seconds after invoking shutdown now.
EDIT: FYI This is on Arch Linux with AMD processor and GPU, linux-hardened kernel.
EDIT2: rngd --version output:
rngd 6.13
Copyright 2001-2004 Jeff Garzik
Copyright 2017 Neil Horman
Copyright (c) 2001 by Philipp Rumpf
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Hi
on this line is used the pthread_yield call there is any particular reason to not use
sched_yield() ?
Lines 168 to 172 in 4cfb882
I am asking this because on my particular platform pthread_yield is not defined -> causes a compilation error.
If there's no particular reason I have this patch to fix it (but I don't know enough of rng-tools to be sure that it will not cause any problems
From 2a2f6102e53e2effbe057423e77627318994118c Mon Sep 17 00:00:00 2001
From: Nicola Lunghi <[email protected]>
Date: Fri, 31 May 2019 16:39:11 +0100
Subject: [PATCH] rngd_jitter: replace pthread_yield with sched_yield
This was causing errors in pthread
---
rngd_jitter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rngd_jitter.c b/rngd_jitter.c
index 8991bbd..708ef23 100644
--- a/rngd_jitter.c
+++ b/rngd_jitter.c
@@ -168,7 +168,7 @@ try_again:
} else if (request < need) {
if (request == -1) {
message(LOG_DAEMON|LOG_DEBUG, "failed read: %s\n", strerror(errno));
- pthread_yield();
+ sched_yield();
} else
message(LOG_DAEMON|LOG_DEBUG, "request of random data returns %ld less than need %ld\n",
request, need);
--
2.20.1
or give at least a hint about that situation would help to debug this:
rngd -l
Entropy sources that are available but disabled
1: TPM RNG Device (tpm)
Available and enabled entropy sources:
2: Intel RDRAND Instruction RNG (rdrand)
6: JITTER Entropy generator (jitter)
Available entropy sources that failed initalization:
0: Hardware RNG Device (hwrng)
CPU:
Intel Core i5-3210M
lsmod | grep rng:
tpm_tis,tpm_infineon,tpm_rng,tpm_tis_core
lscpu | grep -o -a -m 1 -h rdrand:
rdrand
/dev/tpm0 and /dev/hwrng are present.
Then I run:
rngd --rng-device=/dev/hwrng -f:
Initializing available sources
[hwrng ]: Initialized
[rdrand]: Enabling RDRAND rng support
[rdrand]: Initialized
[jitter]: Initializing AES buffer
[jitter]: Unable to obtain AES key, disabling AES in JITTER source
[jitter]: Enabling JITTER rng support
[jitter]: Initialized
[pkcs11]: PKCS11 Engine /usr/lib64/opensc-pkcs11.so Error: No such file or directory
[pkcs11]: Initialization Failed
[rtlsdr]: Initialization Failed
And as I run rngd -l I got:
Entropy sources that are available but disabled
1: TPM RNG Device (tpm)
4: NIST Network Entropy Beacon (nist)
Available and enabled entropy sources:
2: Intel RDRAND Instruction RNG (rdrand)
5: JITTER Entropy generator (jitter)
Why TPM is listed ad disabled?
Am I miss something?
EDIT
Despite the fact that rng-tools reports tpm as available but disabled, I hower tried:
As I rebooted, the sytemd unit systemd-random-seed.service tooked about three seconds; without TPM but with only rdrand of the CPU, instead, systemd-random-seed.service tooked 430ms.
So, maybe, TPM is not reliable?
But remains the question why is reported as present but disabled.
Upgrade to 6.6 on Alpinelinux fails on s390x alpinelinux/aports#6282
Build log https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/community/rng-tools/rng-tools-6.6-r0.log
rngd_darn.c: In function 'refill_rand':
rngd_darn.c:129:15: error: 'struct rng' has no member named 'options'; did you mean 'rng_options'?
if (ent_src->options[DARN_USE_AES].int_val) {
^~~~~~~
rng_options
rngd_darn.c:129:23: error: 'DARN_USE_AES' undeclared (first use in this function); did you mean 'DARN_OPT_AES'?
if (ent_src->options[DARN_USE_AES].int_val) {
^~~~~~~~~~~~
DARN_OPT_AES
rngd_darn.c:129:23: note: each undeclared identifier is reported only once for each function it appears in
Hello,
A recent update of rng-tools introduced a 100% CPU usage from rngd, this is related to that jitter source and rngd -f -x jitter fixes the issue.
I'm using a raspberry pi (armv6) machine running archlinuxarm, the same issue has been reported on raspberry pi zero, 1b, 3b and 4.
An strace leads to believe that rngd gets stuck in an endless loop of clock_gettime64 which does not happen when -x jitter is used.
Here's a sample strace output:
write(2, "Initializing available sources\n", 31Initializing available sources
) = 31
openat(AT_FDCWD, "/dev/hwrng", O_RDONLY|O_NOCTTY) = 3
read(3, "\23IJ4\255\330\340\312z\tn\367&\270g\243", 16) = 16
read(3, "Nc)`", 4) = 4
read(3, "\347\3\270\334", 4) = 4
write(2, "[hwrng ]: Initialized\n", 22[hwrng ]: Initialized
) = 22
rt_sigaction(SIGUSR1, {sa_handler=0x46a7e0, sa_mask=[USR1], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x76b02120}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
openat(AT_FDCWD, "/proc/sys/crypto/fips_enabled", O_RDONLY) = -1 ENOENT (No such file or directory)
clock_gettime64(CLOCK_REALTIME, {tv_sec=1610569934, tv_nsec=579021205}) = 0
clock_gettime64(CLOCK_REALTIME, {tv_sec=1610569934, tv_nsec=581817181}) = 0
clock_gettime64(CLOCK_REALTIME, {tv_sec=1610569934, tv_nsec=583609165}) = 0
... (gets stuck doing endless clock_gettime64)
The same thing arise when using rngd --list where the program gets stuck mid list and has to be killed.
I'm afraid i can't give you much details, --debug doesn't give any useful information and there isn't anything useful in the logs.
I'm not confident in my capacity to pinpoint and tell you exactly where the problem is, but i'mhappy to assist however i can if you need more information, i'm willing to try anything and/or give you an ssh access to somewhere where you could replicate the issue.
Have a good day!
sending rngd the SIGTERM or SIGINT signals does nothing. The daemon continues to run. Only SIGUSR1 effectively terminates the service.
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether make supports the include directive... yes (GNU style)
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking dependency style of gcc... gcc3
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking for ranlib... ranlib
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking whether gcc needs -traditional... no
checking for ar... ar
checking for a sed that does not truncate output... /usr/bin/sed
checking whether gcc is Clang... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking whether more special flags are required for pthreads... no
checking for PTHREAD_PRIO_INHERIT... yes
configure: Searching for jitterentropy library
checking for library containing jent_version... no
configure: No Jitterentropy library found
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for libcurl... yes
checking for libxml2... yes
checking for jansson... yes
checking for libp11... yes
checking for libcrypto... yes
checking for openssl... yes
checking for library containing sysfs_get_mnt_path... -lsysfs
checking dependency style of gcc... (cached) gcc3
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating contrib/Makefile
config.status: creating tests/Makefile
config.status: creating rngd.8
config.status: creating rngtest.1
config.status: creating rng-tools-config.h
config.status: rng-tools-config.h is unchanged
config.status: executing depfiles commands
ls /usr/include | grep jitter && ls /usr/lib | grep jitter
jitterentropy-base-user.h
jitterentropy.h
libjitterentropy.so
libjitterentropy.so.3
libjitterentropy.so.3.0.0
lmn if you need anything else.
I have rngd 6.11 built with NIST Beacon and RTLSDR is addition to the usual set.
When I run "rngd --list" the output is:
Entropy sources that are available but disabled
1: TPM RNG Device (tpm)
4: NIST Network Entropy Beacon (nist)
Available and enabled entropy sources:
0: Hardware RNG Device (hwrng)
5: JITTER Entropy generator (jitter)
However RTLSDR is not mentioned in the output at all. "ldd" confirms that librtlsdr is compiled into the rngd binary.
I'm using rngd on an embedded device because it generates very little entropy on its own. When starting up the rngd daemon will block for a long time in initializing the AES key and initial vector. Which makes sense, because there is no entropy to generate those.
Is this the intended behavior? It seems odd for rngd, a daemon that exists to generate entropy, to require entropy during initialization. Could the AES key and initial vector initialization be deferred until the rest of the rngd daemon is running and generating entropy? Thus, solving the chicken-and-egg problem?
I tested the current master and even with patch
I still have problem on reboot with systemd
systemd-shutdown[1]: Sending SIGTERM to remaining processes...
systemd-journald[442]: Received SIGTERM from PID 1 (systemd-shutdow).
systemd-shutdown[1]: Sending SIGKILL to remaining processes...
after this it hangs until the watchdog kicks in then
systemd-shutdown[1]: Sending SIGKILL to PID 437 (rngd).
systemd-shutdown[1]: Hardware watchdog 'imx2+ watchdog', version 0
systemd-shutdown[1]: Unmounting file systems.
systemd-shutdown[1]: All filesystems unmounted.
systemd-shutdown[1]: Deactivating swaps.
systemd-shutdown[1]: All swaps deactivated.
systemd-shutdown[1]: Detaching loop devices.
systemd-shutdown[1]: All loop devices detached.
systemd-shutdown[1]: Detaching DM devices.
ci_hdrc ci_hdrc.2: remove, state 1
usb usb3: USB disconnect, device number 1
usb 3-1: USB disconnect, device number 2
usb 3-1.2: USB disconnect, device number 3
ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
ftdi_sio 3-1.2:1.0: device disconnected
ci_hdrc ci_hdrc.2: USB bus 3 deregistered
imx2-wdt 30280000.wdog: Device shutdown: Expect reboot!
ci_hdrc ci_hdrc.1: remove, state 4
usb usb2: USB disconnect, device number 1
ci_hdrc ci_hdrc.1: USB bus 2 deregistered
ci_hdrc ci_hdrc.0: remove, state 4
usb usb1: USB disconnect, device number 1
ci_hdrc ci_hdrc.0: USB bus 1 deregistered
reboot: Restarting system
can you help me debug it?
If I start the service with jitter disabled
-x jitter
It reboots correctly
When I start rngd I get this output:
$ sudo rngd -f
Initializing available sources
Initializing entropy source hwrng
Enabling RDSEED rng support
Initializing entropy source rdrand
Initializing AES buffer
Enabling JITTER rng support
Initializing entropy source jitter
No pkcs11 slots available
Failed to init entropy source pkcs11
It's not immediately obvious which sources were properly initialized and which weren't.
Messages belonging to the same source are separated by a newline.
Enabling JITTER rng support belongs to Initializing entropy source jitter
but do Initializing entropy source hwrng, Enabling RDSEED rng support and Initializing entropy source rdrand all belong together?
I'd suggest to group them together or add a prefix like Jitter source: Enabling JITTER rng support.
When initialization is successful, it would be nice to have a Successfully initialized entropy source jitter message.
Do I assume correctly, that my output means:
But what does Initializing AES buffer mean? To which source does it belong?
Another question: Why does Initializing available sources try to initialize pkcs11 which later notices it's not available? I guess available means rngd was compiled with support for it?
I'd suggest to change the wording of either phrase to distinguish the different usages of the word "available". What do you think?
Hi!
I'm running internal tests during RPM package build in chrooted environment
%check
make check
and getting random test failures like below log represents.
What could be done to stabilize test result?
What issues with /dev/urandom are these results revealing?
=========================================
rng-tools 6.7: tests/test-suite.log
=========================================
# TOTAL: 3
# PASS: 2
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: rngtesturandom.sh
=======================
rngtest: bits received from input: 2000064
rngtest: bits sent to output: 1980000
rngtest: FIPS 140-2 successes: 99
rngtest: FIPS 140-2 failures: 1
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 1
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=953.674; avg=5465.182; max=19073.486)Mibits/s
rngtest: FIPS tests speed: (min=89.128; avg=124.201; max=167.311)Mibits/s
rngtest: output channel speed: (min=952380952.381; avg=14776119402.985; max=0.000)bits/s
rngtest: Program run time: 16444 microseconds
5 times OK
=========================================
rng-tools 6.7: tests/test-suite.log
=========================================
# TOTAL: 3
# PASS: 2
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: rngtesturandom.sh
=======================
rngtest: bits received from input: 2000064
rngtest: bits sent to output: 1980000
rngtest: FIPS 140-2 successes: 99
rngtest: FIPS 140-2 failures: 1
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 1
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=340.598; avg=5045.896; max=19073.486)Mibits/s
rngtest: FIPS tests speed: (min=95.847; avg=143.593; max=168.792)Mibits/s
rngtest: output channel speed: (min=9.313; avg=23.050; max=18.626)Gibits/s
rngtest: Program run time: 14249 microseconds
11 times OK
=========================================
rng-tools 6.7: tests/test-suite.log
=========================================
# TOTAL: 3
# PASS: 2
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: rngtesturandom.sh
=======================
rngtest: bits received from input: 2000064
rngtest: bits sent to output: 1980000
rngtest: FIPS 140-2 successes: 99
rngtest: FIPS 140-2 failures: 1
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 1
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=560.985; avg=3791.946; max=19073.486)Mibits/s
rngtest: FIPS tests speed: (min=108.372; avg=141.694; max=167.311)Mibits/s
rngtest: output channel speed: (min=1.164; avg=17.731; max=18.626)Gibits/s
rngtest: Program run time: 14392 microseconds
16 times OK
=========================================
rng-tools 6.7: tests/test-suite.log
=========================================
# TOTAL: 3
# PASS: 2
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: rngtesturandom.sh
=======================
rngtest: bits received from input: 2000064
rngtest: bits sent to output: 1980000
rngtest: FIPS 140-2 successes: 99
rngtest: FIPS 140-2 failures: 1
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 1
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=346.791; avg=4334.883; max=19073.486)Mibits/s
rngtest: FIPS tests speed: (min=89.969; avg=146.471; max=168.792)Mibits/s
rngtest: output channel speed: (min=9.313; avg=21.694; max=18.626)Gibits/s
rngtest: Program run time: 14300 microseconds
0 times OK
=========================================
rng-tools 6.7: tests/test-suite.log
=========================================
# TOTAL: 3
# PASS: 2
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: rngtesturandom.sh
=======================
rngtest: bits received from input: 2000064
rngtest: bits sent to output: 1980000
rngtest: FIPS 140-2 successes: 99
rngtest: FIPS 140-2 failures: 1
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 1
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=2.070; avg=6.445; max=18.626)Gibits/s
rngtest: FIPS tests speed: (min=89.969; avg=125.129; max=168.792)Mibits/s
rngtest: output channel speed: (min=4.657; avg=20.719; max=18.626)Gibits/s
rngtest: Program run time: 16191 microseconds
1 time OK
=========================================
rng-tools 6.7: tests/test-suite.log
=========================================
# TOTAL: 3
# PASS: 2
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: rngtesturandom.sh
=======================
rngtest: bits received from input: 2000064
rngtest: bits sent to output: 1980000
rngtest: FIPS 140-2 successes: 99
rngtest: FIPS 140-2 failures: 1
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 1
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=596.046; avg=5006.164; max=19073.486)Mibits/s
rngtest: FIPS tests speed: (min=79.473; avg=122.683; max=161.640)Mibits/s
rngtest: output channel speed: (min=1.164; avg=15.897; max=18.626)Gibits/s
rngtest: Program run time: 16619 microseconds
In order to compile with the musl c library, <limits.h> needs to be included by rngd.c. This should be a harmless enough change.
I am still having some issues with the rngtestjitter.sh test. Looks to me that the 5 second "timeout" is too short for the test to pass consistently across all arches/VMs in our CI.
eg. on a ppc64le machine (a VM on a Power8 hw) I get
[root@localhost tests]# cat rngtestjitter.sh.log
Disabling 0: Hardware RNG Device (hwrng)
Disabling 2: Intel RDRAND Instruction RNG (rdrand)
Disabling 1: TPM RNG Device (tpm)
Initializing available sources
[darn ]: No HW SUPPORT
[darn ]: Initialization Failed
[jitter]: Initializing AES buffer
[jitter]: Enabling JITTER rng support
[jitter]: Initialized
killing
rngd(809): Operation not permitted
FAIL rngtestjitter.sh (exit status: 1)
but for example running the test for a 2nd time, it passes.
[jenkins@localhost ppc64le]$ cat tests/rngtestjitter.sh.log
Disabling 0: Hardware RNG Device (hwrng)
Disabling 2: Intel RDRAND Instruction RNG (rdrand)
Disabling 1: TPM RNG Device (tpm)
Initializing available sources
[darn ]: No HW SUPPORT
[darn ]: Initialization Failed
[jitter]: Initializing AES buffer
[jitter]: Enabling JITTER rng support
[jitter]: Initialized
[pkcs11]: No pkcs11 slots available
[pkcs11]: Initialization Failed
[rtlsdr]: Initialization Failed
unable to adjust write_wakeup_threshold: Permission denied
rngtest: bits received from input: 2000064
rngtest: bits sent to output: 2000000
rngtest: FIPS 140-2 successes: 100
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=2.652; avg=136.171; max=19073.486)Mibits/s
rngtest: FIPS tests speed: (min=69.107; avg=116.872; max=119.209)Mibits/s
rngtest: output channel speed: (min=953.674; avg=17825.688; max=19073.486)Mibits/s
rngtest: Program run time: 4969298 microseconds
killing
rngd(809): Operation not permitted
PASS rngtestjitter.sh (exit status: 0)
I know there have been several issues raised in the past regarding excessive CPU usage with Raspberry Pis. Indeed I commented in at least one of those previous issues that I only observed CPU load for no more than 30 seconds after starting rngd.
However, after a recent report from another Alpine Linux RPI user regarding 100% CPU on a RPI running older versions of jitterentropy-library and rngd I assumed this issue would be eliminated by creating Alpine packages (which I maintain) of the current jitterentropy-library and rng-tools versions. This proved not to be the case.
So I built and tested git Master versions of both jitterentropy-library and rng-tools for Alpine (which is musl, not glibc) x86, x86_64 and aarch64. As expected I observed no issues for x86 and x86_64. However with aarch64 on a RPI3B (4 cores) I see that all 4 cores are maxed out for almost exactly 3 minutes - this is reproducable every time I start/restart rngd.
Here's an example set of logs, with the log divided up into 3 distinct time periods each almost exactly 1 minute apart:
Startup:
2021-10-02T19:46:00.826124+01:00 waffle rngd: Initializing available sources
2021-10-02T19:46:00.826393+01:00 waffle rngd: [hwrng ]: Initialized
2021-10-02T19:46:00.826449+01:00 waffle rngd: [rndr ]: No HW SUPPORT
2021-10-02T19:46:00.826512+01:00 waffle rngd: [rndr ]: Initialization Failed
2021-10-02T19:46:00.994403+01:00 waffle rngd: [jitter]: JITTER attempting to start 4 threads
2021-10-02T19:46:01.108763+01:00 waffle rngd: [jitter]: JITTER thread on cpu 0 wakes up for refill
2021-10-02T19:46:01.108867+01:00 waffle rngd: [jitter]: CPU Thread 0 is ready
2021-10-02T19:46:01.223127+01:00 waffle rngd: [jitter]: JITTER thread on cpu 1 wakes up for refill
2021-10-02T19:46:01.223251+01:00 waffle rngd: [jitter]: CPU Thread 1 is ready
2021-10-02T19:46:01.337774+01:00 waffle rngd: [jitter]: JITTER thread on cpu 2 wakes up for refill
2021-10-02T19:46:01.338551+01:00 waffle rngd: [jitter]: CPU Thread 2 is ready
2021-10-02T19:46:01.454444+01:00 waffle rngd: [jitter]: CPU Thread 3 is ready
2021-10-02T19:46:01.455231+01:00 waffle rngd: [jitter]: Initializing AES buffer
2021-10-02T19:46:01.455833+01:00 waffle rngd: [jitter]: xread_jitter requests 16 bytes from pipe
2021-10-02T19:46:01.456352+01:00 waffle rngd: [jitter]: JITTER thread on cpu 3 wakes up for refill
1 minute later jitter source completes initialisation:
2021-10-02T19:46:59.938817+01:00 waffle rngd: [jitter]: jent_read_entropy time on cpu 1 is 5.971542820700e+01 sec
2021-10-02T19:46:59.939468+01:00 waffle rngd: [jitter]: Writing to pipe
2021-10-02T19:46:59.940221+01:00 waffle rngd: [jitter]: DONE Writing to pipe with return 16535
2021-10-02T19:46:59.940588+01:00 waffle rngd: [jitter]: JITTER thread on cpu 1 wakes up for refill
2021-10-02T19:46:59.943257+01:00 waffle rngd: [jitter]: xread_jitter gets 16 bytes
2021-10-02T19:46:59.945122+01:00 waffle rngd: [jitter]: xread_jitter requests 128 bytes from pipe
2021-10-02T19:46:59.947659+01:00 waffle rngd: [jitter]: xread_jitter gets 128 bytes
2021-10-02T19:46:59.949339+01:00 waffle rngd: [jitter]: xread_jitter requests 16535 bytes from pipe
2021-10-02T19:46:59.951927+01:00 waffle rngd: [jitter]: xread_jitter falls back to AES
2021-10-02T19:46:59.959410+01:00 waffle rngd: [jitter]: Enabling JITTER rng support
2021-10-02T19:46:59.960973+01:00 waffle rngd: [jitter]: xread_jitter requests 4 bytes from pipe
2021-10-02T19:46:59.963440+01:00 waffle rngd: [jitter]: xread_jitter falls back to AES
2021-10-02T19:46:59.965008+01:00 waffle rngd: [jitter]: xread_jitter requests 4 bytes from pipe
2021-10-02T19:46:59.967443+01:00 waffle rngd: [jitter]: xread_jitter falls back to AES
2021-10-02T19:46:59.971675+01:00 waffle rngd: [jitter]: Initialized
2021-10-02T19:46:59.990498+01:00 waffle rngd: Kernel entropy pool size 4096, pool watermark 3072
2021-10-02T19:47:00.004241+01:00 waffle rngd: Reading entropy from Hardware RNG Device
2021-10-02T19:47:00.038747+01:00 waffle rngd: [jitter]: jent_read_entropy time on cpu 2 is 5.929929882400e+01 sec
2021-10-02T19:47:00.039409+01:00 waffle rngd: [jitter]: Writing to pipe
2021-10-02T19:47:00.039821+01:00 waffle rngd: [jitter]: DONE Writing to pipe with return 16535
2021-10-02T19:47:00.040165+01:00 waffle rngd: [jitter]: JITTER thread on cpu 2 wakes up for refill
2021-10-02T19:47:00.055550+01:00 waffle rngd: Added 4039/4096 bits entropy
2021-10-02T19:47:00.057022+01:00 waffle rngd: Pool full at 4096, sleeping!
2021-10-02T19:47:00.096834+01:00 waffle rngd: [jitter]: jent_read_entropy time on cpu 3 is 5.936005330300e+01 sec
2021-10-02T19:47:00.097762+01:00 waffle rngd: [jitter]: Writing to pipe
2021-10-02T19:47:00.098330+01:00 waffle rngd: [jitter]: DONE Writing to pipe with return 16535
2021-10-02T19:47:00.098775+01:00 waffle rngd: [jitter]: JITTER thread on cpu 3 wakes up for refill
2021-10-02T19:47:00.325529+01:00 waffle rngd: [jitter]: jent_read_entropy time on cpu 0 is 6.021652471700e+01 sec
2021-10-02T19:47:00.326309+01:00 waffle rngd: [jitter]: Writing to pipe
2021-10-02T19:47:00.326746+01:00 waffle rngd: [jitter]: DONE Writing to pipe with return 16535
2021-10-02T19:47:00.327060+01:00 waffle rngd: [jitter]: JITTER thread on cpu 0 wakes up for refill
2 minutes later:
2021-10-02T19:47:58.688620+01:00 waffle rngd: [jitter]: jent_read_entropy time on cpu 1 is 5.925237413700e+01 sec
2021-10-02T19:47:58.689583+01:00 waffle rngd: [jitter]: Writing to pipe
2021-10-02T19:47:58.690179+01:00 waffle rngd: [jitter]: DONE Writing to pipe with return 16535
2021-10-02T19:47:58.690636+01:00 waffle rngd: [jitter]: JITTER thread on cpu 1 wakes up for refill
2021-10-02T19:47:58.964370+01:00 waffle rngd: [jitter]: jent_read_entropy time on cpu 3 is 5.986506279000e+01 sec
2021-10-02T19:47:58.965306+01:00 waffle rngd: [jitter]: Writing to pipe
2021-10-02T19:47:58.965899+01:00 waffle rngd: [jitter]: DONE Writing to pipe with return 16535
2021-10-02T19:47:58.966374+01:00 waffle rngd: [jitter]: JITTER thread on cpu 3 wakes up for refill
2021-10-02T19:47:59.112600+01:00 waffle rngd: [jitter]: jent_read_entropy time on cpu 2 is 6.007200940500e+01 sec
2021-10-02T19:47:59.113283+01:00 waffle rngd: [jitter]: Writing to pipe
2021-10-02T19:47:59.113707+01:00 waffle rngd: [jitter]: DONE Writing to pipe with return 16535
2021-10-02T19:47:59.114018+01:00 waffle rngd: [jitter]: JITTER thread on cpu 2 wakes up for refill
2021-10-02T19:47:59.412193+01:00 waffle rngd: [jitter]: jent_read_entropy time on cpu 0 is 6.008466133200e+01 sec
2021-10-02T19:47:59.413136+01:00 waffle rngd: [jitter]: Writing to pipe
2021-10-02T19:47:59.413711+01:00 waffle rngd: [jitter]: DONE Writing to pipe with return 16535
2021-10-02T19:47:59.414186+01:00 waffle rngd: [jitter]: JITTER thread on cpu 0 wakes up for refill
3 minutes later and CPU drops to basically zero and remains like that:
2021-10-02T19:48:57.424467+01:00 waffle rngd: [jitter]: jent_read_entropy time on cpu 1 is 5.926667689800e+01 sec
2021-10-02T19:48:57.425453+01:00 waffle rngd: [jitter]: Writing to pipe
2021-10-02T19:48:57.725030+01:00 waffle rngd: [jitter]: jent_read_entropy time on cpu 3 is 5.924184543900e+01 sec
2021-10-02T19:48:57.725151+01:00 waffle rngd: [jitter]: Writing to pipe
2021-10-02T19:48:58.007510+01:00 waffle rngd: [jitter]: jent_read_entropy time on cpu 2 is 5.910691418900e+01 sec
2021-10-02T19:48:58.007594+01:00 waffle rngd: [jitter]: Writing to pipe
2021-10-02T19:48:58.418678+01:00 waffle rngd: [jitter]: jent_read_entropy time on cpu 0 is 6.000398456100e+01 sec
2021-10-02T19:48:58.418755+01:00 waffle rngd: [jitter]: Writing to pipe
I had expected that jitter initialisation might be an issue on slow CPUs like on RPIs but it always completes in approx 1 minute after rngd is started. So what exactly is causing the further 2 minutes of 100% CPU usage?
I did also run rngd via strace but did not see anything in the output that looked like an issue.
I have not yet tested on the RPI with armv7 but I'm assuming the same behaviour to be observed.
Unlikely to be relevant, but mentioning it for completeness, when building rngd I see this compilation warning (on all arches):
rngd_jitter.c: In function 'rngd_notime_start':
rngd_jitter.c:86:25: warning: passing argument 1 of 'pthread_setaffinity_np' from incompatible pointer type [-Wincompatible-pointer-types]
86 | pthread_setaffinity_np(&thread_ctx->notime_thread_id, cpusize, cpus);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| struct __pthread **
In file included from rngd_jitter.c:25:
/usr/include/pthread.h:221:28: note: expected 'pthread_t' {aka 'struct __pthread *'} but argument is of type 'struct __pthread **'
221 | int pthread_setaffinity_np(pthread_t, size_t, const struct cpu_set_t *);
| ^~~~~~~~~
Hi. Funtoo upgraded from rng-tools-6.2 which works fine to rng-tools-6.3 which works not at all. Trying to start from openrc I get:
`
# /etc/init.d/rngd start
Failed to init entropy source 1: TPM RNG Device
can't open any entropy source
Maybe RNG device modules are not loaded
I tried command line:
`
# rngd -r /dev/hwrng -x 1 -n 0 -f
Disabling 1: TPM RNG Device
Enabling 0: Hardware RNG Device
Initalizing available sources
I is 1
I is 2
I is 3
I is 4
I is 5
...
I is 1
I is 2
I is 3
I is 4
I is 5
No entropy sources working, exiting rngd
Compared with rng-tools-6.2:
# rngd -r /dev/hwrng -x 1 -n 0 -f
Disabling 1: TPM RNG Device
Enabling 0: Hardware RNG Device
<keeps on tickin'...>
And openrc:
# /etc/init.d/rngd start
With only the jitter source available, we're seeing nondeterministic startup behaviour:
--debug), but then continue and run as expected[jitter]: Initializing AES buffer
[jitter]: xread_jitter requests 16 bytes from pipe
[jitter]: failed read: Resource temporarily unavailable
[jitter]: xread_jitter requests 16 bytes from pipe
[jitter]: failed read: Resource temporarily unavailable
[jitter]: Unable to obtain AES key, disabling AES in JITTER source
In the second case, rngd will then spam the message "Entropy Generation is slow, consider tuning/adding sources" for a few seconds.
It turned out that this nondeterministic behaviour is caused by an incorrect fcntl, fixed by the following patch:
--- a/rngd_jitter.c
+++ b/rngd_jitter.c
@@ -449,7 +449,7 @@ int init_jitter_entropy_source(struct rng *ent_src)
flags = fcntl(pipefds[0], F_GETFL, 0);
flags |= O_NONBLOCK;
- fcntl(pipefds[0], F_SETFL, &flags);
+ fcntl(pipefds[0], F_SETFL, flags);
if (ent_src->rng_options[JITTER_OPT_USE_AES].int_val) {
/*This sets various random flags on the pipefd - in particular O_NONBLOCK was often not actually set, which can be seen using strace.
The above patch fixes the fcntl to its intended effect, but by doing so, it makes the AES key generation fail consistently: The initial jent_read_entropy() takes roughly 6.5 seconds on my test system, so with O_NONBLOCK set, reading from the entropy pipe will always fail.
Current help is somewhat confusing -- it suggests --without-rtlsdr to disable rtlsdr while in practice it is already default behavior:
Lines 44 to 49 in 54c9139
with_rtlsdr should be set to check instead of no like in other flags (and I think that was the intention) or option should be updated.I do run sys-apps/rng-tools-6.9 at a hardened stable gentoo Linux at a
# uname -a
Linux mr-fox 5.7.11 #14 SMP Wed Jul 29 13:13:26 CEST 2020 x86_64 Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz GenuineIntel GNU/Linux
and do wonder about this syslog message:
Jul 29 13:44:40 mr-fox rngd[1434]: [jitter]: jent_read_entropy time on cpu 3 is 2.215905712000e+00 sec
Jul 29 13:44:40 mr-fox rngd[1434]: [jitter]: Writing to pipe
Jul 29 13:44:40 mr-fox rngd[1434]: [jitter]: DONE Writing to pipe with return 16535
Jul 29 13:44:40 mr-fox rngd[1434]: [jitter]: JITTER thread on cpu 3 wakes up for refill
Jul 29 13:44:40 mr-fox rngd[1434]: [jitter]: jent_read_entropy time on cpu 0 is 2.212319587000e+00 sec
Jul 29 13:44:40 mr-fox rngd[1434]: [jitter]: Writing to pipe
Jul 29 13:44:40 mr-fox rngd[1434]: [jitter]: DONE Writing to pipe with return 16535
Jul 29 13:44:40 mr-fox rngd[1434]: [jitter]: JITTER thread on cpu 0 wakes up for refill
Jul 29 13:44:40 mr-fox rngd[1434]: [jitter]: jent_read_entropy time on cpu 2 is 2.215113605000e+00 sec
Jul 29 13:44:40 mr-fox rngd[1434]: [jitter]: Writing to pipe
Jul 29 13:44:40 mr-fox rngd[1434]: [jitter]: DONE Writing to pipe with return 16535
Jul 29 13:44:40 mr-fox rngd[1434]: [jitter]: JITTER thread on cpu 2 wakes up for refill
Jul 29 13:44:40 mr-fox rngd[1434]: [jitter]: jent_read_entropy time on cpu 1 is 2.216819959000e+00 sec
Jul 29 13:44:40 mr-fox rngd[1434]: [jitter]: Writing to pipe
Jul 29 13:44:40 mr-fox rngd[1434]: [jitter]: DONE Writing to pipe with return 16535
Jul 29 13:44:40 mr-fox rngd[1434]: [jitter]: JITTER thread on cpu 1 wakes up for refill
Jul 29 13:44:41 mr-fox rngd[1434]: [jitter]: jent_read_entropy time on cpu 3 is 2.215902896000e+00 sec
Jul 29 13:44:41 mr-fox rngd[1434]: [jitter]: Writing to pipe
Jul 29 13:44:41 mr-fox rngd[1434]: [jitter]: jent_read_entropy time on cpu 0 is 2.215203839000e+00 sec
Jul 29 13:44:41 mr-fox rngd[1434]: [jitter]: Writing to pipe
Jul 29 13:44:41 mr-fox rngd[1434]: [jitter]: jent_read_entropy time on cpu 2 is 2.214067906000e+00 sec
Jul 29 13:44:41 mr-fox rngd[1434]: [jitter]: Writing to pipe
Jul 29 13:44:41 mr-fox rngd[1434]: [jitter]: jent_read_entropy time on cpu 1 is 2.215650770000e+00 sec
Jul 29 13:44:41 mr-fox rngd[1434]: [jitter]: Writing to pipe
b/c the CPU is a 6-core CPU == 12 threads.
May ask ask, where the other CPUs are (or is this rather related to the packageapp-crypt/jitterentropy-rngd of http://www.chronox.de/jent.html ?)
@nhorman : Starting with OpenSSL 1.1.1d, a new function wait_random_seeded() was added that uses shared memory calls (ex. shmget) to note when a check for /dev/random is readable.
https://github.com/openssl/openssl/blob/OpenSSL_1_1_1d/crypto/rand/rand_unix.c#L373
This causes a problem with sandboxes with syscall whitelists, without tweaking the whitelists.
This OpenSSL 1.1.1d check can be disabled by compiling it with
-DOPENSSL_RAND_SEED_DEVRANDOM_SHM_ID=-1
So this is where rng-tools comes in ...
Would it make sense for rng-tools to perform the same basic check at start (before forking):
/* Open /dev/random and wait for it to be readable */
if ((fd = open(DEVRANDOM_WAIT, O_RDONLY)) != -1) {
if (DEVRANDM_WAIT_USE_SELECT && fd < FD_SETSIZE) {
FD_ZERO(&fds);
FD_SET(fd, &fds);
while ((r = select(fd + 1, &fds, NULL, NULL, NULL)) < 0
&& errno == EINTR);
} else {
while ((r = read(fd, &c, 1)) < 0 && errno == EINTR);
}
close(fd);
}
so distros could safely disable the check in OpenSSL ?
Presumably rngd is called before OpenSSL's libcrypto.
Thoughts ?
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.