jirka-h / haveged Goto Github PK

I have a reliable crasher when using haveged with the LRNG patch set.

The problem is in haveged in function run_daemon with the following lines:

 if (ioctl(random_fd, RNDGETENTCNT, &current) == -1)
         error_exit("Couldn't query entropy-level from kernel");
      /* get number of bytes needed to fill pool */
      nbytes = (poolSize  - current)/8;

This code assumes that the poolsize is strictly larger than the available
entropy /dev/random can process. This is true for the legacy /dev/random but
it is not true for the LRNG considering that it has additional entropy
sources.

Here is a gdb output:

(gdb) p poolSize
$10 = 1024
(gdb)
696 if (ioctl(random_fd, RNDGETENTCNT, &current) == -1)
(gdb)
699 nbytes = (poolSize - current)/8;
(gdb) p current
$13 = 1093
(gdb) p nbytes
$14 =
(gdb) p (poolSize - current)
$15 = 4294967227
(gdb) p (poolSize - current)/8
$16 = 536870903
(gdb) n
700 if(nbytes<1) continue;
(gdb) p nbytes
$17 = 536870903

This value is now used to pull the given amount of bytes from the kernel which naturally is a bit too much.

This debug log also shows that (poolSize - current)/8 will not turn negative as the division by 8 is done before any potential type cast.

Raspberry Pi 4 8GB running Kali Linux armv7l(armhf) - Linux kali 5.4.83-Re4son-v7l+ . Failed to start Entropy Daemon based on the HAVEGE algorithm durinng boot .
haveged --version haveged 1.9.14
$sudo systemctl status haveged
haveged.service - Entropy Daemon based on the HAVEGE algorithm
Loaded: loaded (/lib/systemd/system/haveged.service; enabled; vendor preset: enabled)
Active: failed (Result: signal) since Fri 2021-10-01 06:11:47 UTC; 1 day 21h ago
Docs: man:haveged(8)
http://www.issihosts.com/haveged/
Process: 504 ExecStart=/usr/sbin/haveged --Foreground --verbose=1 $DAEMON_ARGS (code=killed, signal=SYS)
Main PID: 504 (code=killed, signal=SYS)
CPU: 60ms

Oct 01 06:11:47 kali systemd[1]: haveged.service: Failed with result 'signal'.
Oct 01 06:11:47 kali systemd[1]: haveged.service: Scheduled restart job, restart counter is at 5.
Oct 01 06:11:47 kali systemd[1]: Stopped Entropy Daemon based on the HAVEGE algorithm.
Oct 01 06:11:47 kali systemd[1]: haveged.service: Start request repeated too quickly.
Oct 01 06:11:47 kali systemd[1]: haveged.service: Failed with result 'signal'.
Oct 01 06:11:47 kali systemd[1]: Failed to start Entropy Daemon based on the HAVEGE algorithm.

Hi,

I installed the 1.9.13 version from EPEL testing and find these on my Centos 8.2 box

systemd[1]: /usr/lib/systemd/system/haveged.service:21: Unknown lvalue 'ProtectHostname' in section 'Service'
systemd[1]: /usr/lib/systemd/system/haveged.service:22: Unknown lvalue 'ProtectKernelLogs' in section 'Service'

from the SPEC file I see that the haveged.service is created from Fedora's
init.d/service.fedora %{buildroot}%{_unitdir}/%{name}.service
but it appears to use systemd features not enabled for Centos 8.2.

Line 21 and 22 sets:

ProtectHostname=true
ProtectKernelLogs=true

This does not break haveged from starting.

haveged[20794]: haveged: command socket is listening at fd 3
haveged[20794]: haveged: ver: 1.9.13; arch: x86; vend: GenuineIntel; build: (gcc 8.3.1 ITV); collect: 128K
haveged[20794]: haveged: cpu: (L4 VC); data: 32K (L2 L4 V); inst: 32K (L2 L4 V); idx: 24/40; sz: 31434/52909
haveged[20794]: haveged: tot tests(BA8): A:1/1 B:1/1 continuous tests(B):  last entropy estimate 8.00452
haveged[20794]: haveged: fills: 0, generated: 0

Hi

Sorry for the harsh question, but with the jitter entropy added in v5.4 (merge commit, commit, LKML) and removal of the /dev/random blocking pool in v5.6 (commit, LWN), is haveged still useful/relevant? If yes, under what circumstances?

- Kristian

It is often useful to run use haveged directly for creating secure cryptographic keys or passwords, no matter whether the program is also running as a daemon at the same time.

For instance, I frequently use

$ /usr/sbin/haveged -f - -n 32 2> /dev/null | base64 | tr -d =
7/W6YAML1rUHj1J44/vl0n1JcYQ5ijuZ8cQ27r2uHv4

in order to create a password equivalent to a key strength of 256 bit.

Unfortunately, this fails if a daemon (or just another instance of the program as a regular user application) is running at the same time.

The enclosed patch fixes the problem.

Without this patch, the application tries to create the command 
socket, even when running as a regular user application for 
harvesting entropy independent of any daemon.

This will fail if another instance of haveged is already running, 
no matter whether that other instance is a daemon or not.

This patch will make the application ignore the socket when run 
as a regular user application, thus avoiding the problem.

(Patch created 2021-11-03 by Guenther Brunthaler.)

Index: haveged-1.9.14/src/haveged.c
===================================================================
--- haveged-1.9.14.orig/src/haveged.c
+++ haveged-1.9.14/src/haveged.c
@@ -429,7 +429,7 @@ int main(int argc, char **argv)
       close(socket_fd);
       return ret;
       }
-   else {
+   else if (!(params->setup & RUN_AS_APP)){
       socket_fd = cmd_listen(params);
       if (socket_fd >= 0)
          fprintf(stderr, "%s: command socket is listening at fd %d\n", params->daemon, socket_fd);

Heya,

It would be nice if --version would be supported by the sbin/haveged.

That way I can embed haveged into a commandline script, and display whether the local
computer needs an update to haveged (I tend to compile from source, so it is useful to
me to be able to verify the versions in general).

When systemd switches into real root on my openSUSE Tumbleweed system, haveged crashes with this in kernel log: [ 7.077689] haveged[556]: segfault at 55e02e096000 ip 00007fa8036dad5d sp 00007ffe4e45f520 error 6 in libhavege.so.1.1.0[7fa8036da000+15000]. It doesn't even seem to able to load debug symbols from the real root. However, immediately after that, systemd auto-restarts it and it runs fine.

sudo journalctl -o short-full -b 0 -u haveged shows:

-- Logs begin at Sun 2018-03-18 07:45:02 +05, end at Thu 2018-10-25 20:23:49 +05. --
Thu 2018-10-25 01:13:39 +05 arsenal haveged[556]: haveged: listening socket at 3
Thu 2018-10-25 01:13:41 +05 arsenal haveged[556]: haveged: restart in new root: /sysroot
Thu 2018-10-25 01:13:41 +05 arsenal haveged[556]: haveged: listening socket at 3
Thu 2018-10-25 01:13:43 +05 arsenal systemd[1]: haveged.service: Main process exited, code=dumped, status=11/SEGV
Thu 2018-10-25 01:13:43 +05 arsenal systemd[1]: haveged.service: Failed with result 'core-dump'.
Thu 2018-10-25 01:13:43 +05 arsenal systemd[1]: haveged.service: Consumed 3.429s CPU time
Thu 2018-10-25 01:13:43 +05 arsenal systemd[1]: haveged.service: Service RestartSec=250ms expired, scheduling restart.
Thu 2018-10-25 01:13:43 +05 arsenal systemd[1]: haveged.service: Scheduled restart job, restart counter is at 1.
Thu 2018-10-25 01:13:44 +05 arsenal systemd[1]: Stopped Entropy Daemon based on the HAVEGE algorithm.
Thu 2018-10-25 01:13:44 +05 arsenal systemd[1]: haveged.service: Consumed 3.429s CPU time
Thu 2018-10-25 01:13:44 +05 arsenal systemd[1]: Started Entropy Daemon based on the HAVEGE algorithm.
Thu 2018-10-25 01:13:44 +05 arsenal haveged[1228]: haveged: listening socket at 3

I was unable to build on cygwin until doing the following:

--- "src\haveged.c" 2018-08-10 15:44:19.000000000 -0700
+++ "src\haveged.c.new" 2018-09-04 06:29:12.694437600 -0700
@@ -26,9 +26,9 @@
#include <signal.h>
#include <fcntl.h>
#include <sys/time.h>
+#include <unistd.h>

#ifndef NO_DAEMON
-#include <unistd.h>
#include <syslog.h>
#include <sys/ioctl.h>
#include <asm/types.h>

I was already on 1.9.9.1 and downloaded 1.9.10 and compiled it

Jun 11 14:55:11 centos6 haveged: haveged: Stopping due to signal 15
Jun 11 14:55:11 centos6 haveged: haveged starting up
Jun 11 14:55:11 centos6 haveged: haveged: ver: 1.9.9; arch: x86; vend: GenuineIntel; build: (gcc 4.4.7 ITV); collect: 128K
Jun 11 14:55:11 centos6 haveged: haveged: cpu: (L4 VC); data: 32K (L4 V); inst: 32K (L4 V); idx: 21/40; sz: 32100/59539
Jun 11 14:55:11 centos6 haveged: haveged: tot tests(BA8): A:1/1 B:1/1 continuous tests(B):  last entropy estimate 8.00508
Jun 11 14:55:11 centos6 haveged: haveged: fills: 0, generated: 0 

find . -exec grep -n "1.9.9" {} ;

6:AC_INIT([haveged],[1.9.9])
3:# Generated by GNU Autoconf 2.69 for haveged 1.9.9.
590:PACKAGE_VERSION='1.9.9'
591:PACKAGE_STRING='haveged 1.9.9'
1329:\`configure' configures haveged 1.9.9 to adapt to many kinds of systems.
1399:     short | recursive ) echo "Configuration of haveged 1.9.9:";;
1518:haveged configure 1.9.9
1937:It was created by haveged $as_me 1.9.9, which was
4109: VERSION='1.9.9'

Hi,

Not sure why this happens but every now and then I find that haveged is not longer running. When querying the service I get this output from systemd:
Job haveged.service/start deleted to break ordering cycle starting with sysinit.target/start
I'm running Centos 7 in these cases with the latest haveged from EPEL, 1.9.13.

To fix the issue I install the service again (although I'm not sure if this is a permanent fix yet):
systemctl enable haveged --now

Just noticed what looks like a cut-n-paste error in a somewhat important spot. 😉

On the Haveged download page, in the list of downloads... the URL that's linked to for 1.9.2 actually links to the older 1.9.1 download.

463K Nov 17 12:28 2017 haveged-1.9.2.tar.gz  <-- wrong link here

Not sure if this is the correct place to report it, but it seems as likely a place as any. 😄

Do you have change access to the ISSIHosts website, or should I email the contact person (Gary) listed on that page directly?

Since version 1.9.8 the file service.fedora changed from
< ExecStart=/usr/sbin/haveged -w 1024 -v 1 --Foreground
to
> ExecStart=@SBIN_DIR@/haveged -w 1024 -v 1 --Foreground

which does not get substituted.

I updated the file to point to the binary and built a new version from the included SPEC file, fedora.spec
Note that it has a date issue on line 119, "Tue 09 Jun 2020" should read "Tue Jun 09 2020"

I want to build RPMs using the SPEC file but it is calling for a patch file that I can't find. I wanted to test, building a RPM for Centos 7. I am worried the that missing patch file is something important.

I looked at the source used for FC 32 and that SPEC file does not specify a patch file. I compiled v1.9.8 using the SPEC (I had to remove the tag mentioned on line 14) file supplied by FC 32 and that built a working version on Centos 7.8. The FC 32 version of the SPEC file does not include a Patch file.

# rpmbuild -ba haveged.spec 
error: Bad source: /root/rpmbuild/SOURCES/haveged-link.patch: No such file or directory

havegecmd.c uses error_exit function that is only defined in haveged.c and therefore it is not resolved in libhavege library. error_exit() is rather not suitable for a library so please either drop error_exit usage from havegecmd.c or move havegecmd.c from library to haveged daemon.

haveged --data is not actually falling back to 16 as stated in the help:

haveged -h 2>&1 | grep "\-d"
 --data      , -d [] Data cache size [KB], with fallback to: 16

if -d16 is not added to /etc/default/haveged, haveged will error out with

haveged: Couldn't initialize HAVEGE rng 5

v 1.9.1 maybe #67

Systemd reports failure, as does running from the command line, SegFault

OS: Ubuntu 18.04 (Esxi VM)
Kernel: 5.10.71-xanmod1 #0~git20211006.8e0ccfa SMP PREEMPT

     PID: 21612 (haveged)
       UID: 0 (root)
       GID: 0 (root)
    Signal: 11 (SEGV)
 Timestamp: Mon 2021-10-11 04:14:52 CEST (4min 8s ago)

Command Line: /usr/sbin/haveged --Foreground --verbose=1 -w 1024
Executable: /usr/sbin/haveged
Control Group: /user.slice/user-1000.slice/session-3.scope
Unit: session-3.scope
Slice: user-1000.slice
Session: 3
Owner UID: 1000 ( )
Boot ID: d0aa65c8069044f3952c3382a5523832
Machine ID: 7ae74b38bb314eb08357f142b6314be3
Hostname:
Storage: /var/lib/systemd/coredump/core.haveged.0.d0aa65c8069044f3952c3382a5523832.21612.1633918492000000.lz4
Message: Process 21612 (haveged) of user 0 dumped core.

            Stack trace of thread 21612:
            #0  0x00007f82be920a7d havege_rng (libhavege.so.1)
            #1  0x000056492b402284 n/a (haveged)
            #2  0x00007f82be54fbf7 __libc_start_main (libc.so.6)
            #3  0x000056492b4024ba n/a (haveged)

Trying to use haveged to address entropy starvation that is creating problems for Apache and PHP-FPM at boot (no HWRNG)

See https://github.com/jirka-h/haveged/pull/43/checks?check_run_id=820836997#step:5:11

The version on EPEL 7 is still 1.9.13. I'm running haveged on Amazon Linux 2 hosts with kernel 5.15. Won't the improvements from 1.9.18 make haveged more suited for kernels past version 5.6?

[root@localhost haveged_lcov]# haveged -c "root=./tmp"
haveged: can't restart ./haveged: No such file or directory

or

[root@localhost haveged_lcov]# haveged -c "root=./tmp"
haveged: can't restart ./haveged: Permission denied

Greetings. I don't see a LICENSE file in here. Probably worth adding? Thanks.

Service files are available in the following directories:

• contrib/Fedora/
• contrib/SUSE/
• init.d/

This should be cleaned up... Please remove old files in init.d/.

26d35af broke compilation as sys/auxv.h is not available. Same as getauxval.

https://downloads.openwrt.org/releases/faillogs-19.07/arc_arc700/packages/haveged/compile.txt

$ ./configure runs ok, but make barfs.

$ make
make  all-recursive
make[1]: Entering directory '/haveged-1.9.18'
Making all in src
make[2]: Entering directory '/haveged-1.9.18/src'
gcc -DHAVE_CONFIG_H -I. -I..    -Wall -Wextra -Wpedantic -I.. -g -O2 -c -o haveged.o haveged.c
haveged.c:42:10: fatal error: linux/random.h: No such file or directory
   42 | #include <linux/random.h>
      |          ^~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [Makefile:524: haveged.o] Error 1
make[2]: Leaving directory '/haveged-1.9.18/src'
make[1]: *** [Makefile:476: all-recursive] Error 1
make[1]: Leaving directory '/haveged-1.9.18'
make: *** [Makefile:372: all] Error 2

When I looked to see what files haveged uses, besides /dev/random, to obtain some entropy, I find that the files used are:

/proc/sys/kernel/osrelease
/proc/sys/kernel/random/poolsize
/proc/sys/kernel/random/write_wakeup_threshold

When I look at those three /proc/sys/kernel files, I find that they have very low entropy. They are small (one line) text files recording what look to be three parameters, one per file, that seem to be constant at least for each boot, if not for the entire life of a particular hardware and kernel configuration:

The command:

head /proc/sys/kernel/{osrelease,random/poolsize,random/write_wakeup_threshold}

produces, on my Ryzen 1700 box:

==> /proc/sys/kernel/osrelease <==
5.4.0-100-generic

==> /proc/sys/kernel/random/poolsize <==
4096

==> /proc/sys/kernel/random/write_wakeup_threshold <==
1024

I have been experimenting, on my Ubuntu LTS 20.04 system, with various /proc files, and so far I am finding much more apparent entropy in the following files:

/proc/self/{sched,stat,status}

Reading these three files produces over 3000 bytes of output on my system right now, and the output varies every time I read them, as might be expected from what they purport to show. These files are also quick to read, taking less than 0.01 seconds total to read all three of them on my system.

Wouldn't it make more sense for haveged to use these three /proc/self files? Reading the same /proc/sys/kernel files over and over again, to get the same, short, low entropy results seems like a waste of time and a poor basis for obtaining random entropy.

Hi,
I emailed this through to Gary a couple of years ago (i.e. v1.9.1), I've had a quick search through the current code and it doesn't appear to have been fixed yet. Hopefully I'm wrong...

So my team had a report of a dev host using 100% of a core. We identified haveged as the cause, tested and correlated, and considered the high watermark problem and eliminated it as a possibility. Interestingly, we noticed that in strace, haveged appeared to be stuck in a select loop - which was reported behaviour of the watermark issue - but we definitely did not have the watermark issue.

We soon figured out that a developer, upon instruction from some brainiacs at Oracle, had made this little mess:

[root@redacted]/root> ls -la /dev/random
lrwxrwxrwx 1 root root 12 Jul 15 10:52 /dev/random -> /dev/urandom

Simply removing that and recreating /dev/random (mknod -m 666 /dev/random c 1 8) fixed the issue immediately. Haveged started working as expected without blowing out a CPU core. We were then able to recreate the symlink and replicate the broken behaviour.

My suggestion/vague-request to Gary was to add some kind of cursory check (e.g. lstat S_ISLNK I'm guessing?) to haveged's startup. I think the sane behaviour is for haveged to exit with an error message, rather than chew through an entire core until someone (or a monitoring system) notices.

Cheers!

After the haveged service was started, then repeat the haveged command :
/usr/sbin/haveged -w 1024 -v 1 --Foreground
The command will abort.
The reason is that the "sys/entropy/haveged"socket is already used and can not create again, so cmd_listen return -1.
But the program is not care about the error ,then FD_SET will raise abort.

This commit:

1470a82#diff-3fb7fcf3839c90e687c11965ea6abf98

Removed the @SBIN_DIR@ variable from service.fedora, instead hardcoding /usr/sbin.

We're using Amazon Linux 2 systems, and the following:

	./configure --enable-init=service.fedora
	make
	sudo make install

Puts the installation into the /usr/local path, which is where we want it to go, but we're now having to change the service file after installation to point to /usr/local/sbin; that was automatic prior to that commit.

Hello, I've heard about this amazing project and its goal to increase entropy for a stronger security. I've developed recently after a long road (3-4 years) of personal research a formula that might be used to obtain superior entropy, either we are talking about password generation or bits of entropy. This formula was submitted to OEIS and was approved twice, but without an explanation as we speak it remained in proposal status, from what I've understand the chosen name for the formula was not on editors liking.

To prove my point making this story short I'm gonna briefly show mixed arrangements (how I called them) 2^40, 40 bits based on element repeating (knowing processors work only with 1 and 0). The Idea is simple each string belongs to a pattern these patters can have more or less variants, the goal is to use that pattern that holds the bigger number of variants to obtain superior entropy. From the example bellow we can see the least numerous pattern is the first one that holds only 2 variants (string formed from only 1, and second the string is formed from 0). Based on this criteria patterns hold bigger or smaller number of possible arrangements. The exact calculation of these patterns can be made only thru my recently discovered formula. Now my proposal is that instead of randomly choose from all those possible patterns to use only the 'slice' with the bigger amount of arrangements and because this pattern is still lower than the whole to just increase the length of the string to match the previous entropy but using only that bigger slice.

So instead of 40 bits to have 43 but use from it only that slice with the biggest number of arrangements. For 44 bit string the beefiest slice would be when we have like 21 of 1 and 22 of 0 or vice versa 21 of 0 and 22 of 1. That pattern/slice being approx. 2x bigger (~2*10^12) than the whole 40 bits (~10^12) The reason to do this would be to rule out those extremely guessable patterns and their strings. So instead of having that good old random were gonna have a so called targeted random minimizing almost completely the eventuality of anyone guessing kernel memory allocations.

If I've managed to lit up some light of interest I can go further into details about formula and so on. Last thing that I wanna add is that I'm not a programmer (just some basic stuff some python here and there etc.) the only part I can touch is the math part of this topic.

M symbolizes mixed arrangements for different patterns.

After starting haveged how much time should we wait before we can get success in getrandom(2)?

I'm starting haveged as part of a go init process but I've seen cases where I'm not able to generate random numbers even after two minutes from haveged start.
Other notes:
haveged version: 1.9.13
Ref lib I'm using to generate random numbers: https://github.com/u-root/u-root/blob/main/pkg/rand/random_linux.go#L42

In haveged.service is this line......
"ConditionKernelVersion=<5.6" this stops any kernel > 5.6 being used.
I changed this to .......
"ConditionKernelVersion=<6.1" now all current kernels work.

v14 and the current master fail to build if NO_COMMAND_MODE is used.

The declaration for extern int first_byte will be missing when compiling haveged.c. Fix this by wrapping the line in an assignment:

#ifndef NO_COMMAND_MODE
   first_byte = arg0[0];
#endif

The NEWS file says that it was tested on ARM and the README does not list ARM as supported.

What is the status there?

Just noticed that when someone clicks on the "Wiki" link for the repo, instead of going to a (probably empty) wiki it's just bouncing to the front Code page for the repo.

Do you reckon it's worth enabling the wiki, so people with an interest could potentially start adding useful docs? eg about the new stuff in 1.9.3 and 1.9.4. 😄

Noticed an rpath error on build in rhel systems. Was trying to determine if there was something local, or that I could have been doing to cause this, but I'm not sure. I was maybe a minor version behind on some of the build tools required, but it didn't seem to make a difference with anything else. Anyone know?

0x0002 ... invalid RPATHs; these are RPATHs which are neither absolute
nor relative filenames and can therefore be a SECURITY risk

If haveged had a version option bug reports could be more informative.

haveged --version
haveged: unrecognized option '--version'

Usage: haveged [options]

Collect entropy and feed into random pool or write to file.
  Options:
 --buffer    , -b [] Buffer size [KW], default: 128
 --data      , -d [] Data cache size [KB], with fallback to: 16
 --inst      , -i [] Instruction cache size [KB], with fallback to: 16
 --file      , -f [] Sample output file,  default: 'sample', '-' for stdout
 --Foreground, -F    Run daemon in foreground
 --run       , -r [] 0=daemon, 1=config info, >1=<r>KB sample
 --number    , -n [] Output size in [k|m|g|t] bytes, 0 = unlimited to stdout
 --onlinetest, -o [] [t<x>][c<x>] x=[a[n][w]][b[w]] 't'ot, 'c'ontinuous, default: ta8b
 --pidfile   , -p [] daemon pidfile, default: /var/run/haveged.pid
 --verbose   , -v [] Verbose mask 0=none,1=summary,2=retries,4=timing,8=loop,16=code,32=test
 --write     , -w [] Set write_wakeup_threshold [bits]
 --help      , -h    This help

is not listing the version, but maybe it's in there:

strings "$(which haveged)" | grep -P "\d\.\d\."
1.9.1

Just to mention: many headless Raspberry Pi installations will not boot correctly since the current kernel is using mouse events to generate entropy. Not finding a mouse it will wait for minutes, frequently forever.
Haveged is a life saver!
The headless Raspberry Pi is now rebooting in seconds where it took minutes, or worse got stuck...

In the repository, there is a file ChangeLog, but it was not updated for 9 months and it shows there version changelog up to 1.9.8, there are no changes since then.

I see some changes are mention in Releases, but not many.

At my desktop and at my server (stable hardened Gentoo Linux) I do have this in my syslog:

Jul 22 17:29:15 t44 kernel: haveged[1390]: segfault at 7f2475f4bff8 ip 00007f2475da0c1c sp 00007fffa6b52260 error 4 in libc-2.30.so[7f2475d3b000+146000]

Jul 24 13:45:56 mr-fox kernel: haveged[1195]: segfault at 7fb67255eff8 ip 00007fb6723e6c1c sp 00007ffda75215f0 error 4 in libc-2.30.so (deleted)[7fb672381000+146000]

for sys-apps/haveged-1.9.8c when I stop that service.

Raspberry Pi 3 (ARM8) Running Arch Linux ARM. Linux kernel 5.4.45-1-ARCH. Arch uses init.d/fedora.service from this repo to start the daemon.

systemctl start haveged has started core dumping:

Jun 19 12:17:11 alarm.local systemd[1]: Started Entropy Daemon based on the HAVEGE algorithm.
Jun 19 12:17:11 alarm.local systemd[1]: haveged.service: Main process exited, code=dumped, status=31/SYS
Jun 19 12:17:11 alarm.local systemd[1]: haveged.service: Failed with result 'core-dump'.
Jun 19 12:17:12 alarm.local systemd[1]: haveged.service: Scheduled restart job, restart counter is at 1.

I can make this go away by commenting out (or removing) the two SystemCallFilter lines, but I don't know which extra system calls are being invoked in a Raspberry Pi environment. Others have reported that reverting to 1.9.8 also fixes the core dumps - this was before the SystemCallFilter lines were added.

I'm happy to help debug this, but I don't know how to determine which system call is missing from the filter - if you have advice, I can run tests.

Thanks!

in havege_destroy():

void havege_destroy(       /* RETURN: none            */
  H_PTR hptr)              /* IN-OUT: app anchor      */
{
   if (NULL != hptr) {
      H_COLLECT *htemp;
      void *temp;
#if NUMBER_CORES>1
      if (!havege_exit(hptr))
         return;           /* only main thread continues  */
#endif
      if (0 != (temp=hptr->io_buf)) {
         hptr->io_buf = 0;
         free(temp);
         }
#ifdef ONLINE_TESTS_ENABLE
      else if (0 != (temp=hptr->testData)) {
         double *g = ((procShared *)temp)->G;
         hptr->testData = 0;
         if (0 != g)
            free(g);
         }
#endif
      if (0 != (htemp=hptr->collector)) {
         hptr->collector = 0;
         havege_nddestroy(htemp);
         }
      free(hptr);
      }
}

When ONLINE_TESTS_ENABLE is enabled,if 0 != (temp=hptr->io_buf is satisfied, won't go into free(g). This will cause a memory leak because in havege_create(), h->io_buf and hptr->testData can both be malloced.
I suggest to change else if (0 != (temp=hptr->testData)) to if (0 != (temp=hptr->testData)), so that memory leak will be eliminated.

The origin website (http://www.issihosts.com/haveged/) has all source tarballs up to version 1.9.2, but latest one is missing a gpg signature. As development moved here - Any chance to have a download for latest version with signature? I'd be happy with a signed git tag in the repository as well.

There is a bug in haveged where the diagnostics capture mode does not work. This is due to the timer ( incorrectly ) being considered stuck during startup. I know the fix as well, which I will post in a moment. Here is an example of the issue below:

> src/haveged -r 2 -n 100
havege_diagnostic: listening socket at 3
havege_diagnostic: Couldn't initialize HAVEGE rng 19
tot tests(BA8):  last entropy estimate 0
fills: 0, generated: 0

Can you post a list of Linux capabilities haveged requires? I want to set up Docker to run it with as little capabilities as possible.

After applying PR #74 we found potential security issue with named semaphore. It's using fixed name file (semaphore) in /dev/shm/ which is writable for everybody. So anybody can create this file before haveged started and block it before starting.

I tried to replace named semaphore with something like this:

/src/havegecmd.c
@@ -265,7 +265,23 @@ int socket_handler(                /* RETURN: closed file descriptor        */
       }
 
    if (magic[1] == '\002') {       /* ASCII start of text: read argument provided */
+      int avail = 0;
+
+      /*
+       * wait for the haveged -c instance to finish writing (at least 4 bytes
+       * can be read from socket) before continuing to read from the socket
+       */
+      while (ioctl(fd, FIONREAD, &avail) != 0 || avail < 4) {
+          sleep(1);
+          }
 
       ret = receive_uinteger(fd, &alen);
       if (ret < 0) {

but with no success.

Do you have any idea how to properly synchronize haveged instances during switch root?

While working on the Debian package for haveged, with the latest version I ran into several intermittent test failures, both on my laptop and in CI.