haveged 1.9.11-1 (armv5tel) code=dumped, signal=SYS

Problems with packages? Post here, using [tags] of the package name.

haveged 1.9.11-1 (armv5tel) code=dumped, signal=SYS

Postby kriztioan » Mon Jun 15, 2020 1:46 am

haveged 1.9.11-1 dies with the following status message from systemd:

$this->bbcode_second_pass_code('', '● haveged.service - Entropy Daemon based on the HAVEGE algorithm
Loaded: loaded (/usr/lib/systemd/system/haveged.service; enabled; vendor preset: disabled)
Active: failed (Result: core-dump) since Sun 2020-06-14 18:16:28 PDT; 8min ago
Docs: man:haveged(8)
http://www.issihosts.com/haveged/
Process: 1167 ExecStart=/usr/bin/haveged -w 1024 -v 1 --Foreground (code=dumped, signal=SYS)
Main PID: 1167 (code=dumped, signal=SYS)')

Downgrading to 1.9.8-2 solves the problem:

$this->bbcode_second_pass_code('', 'sudo pacman -U /var/cache/pacman/pkg/haveged-1.9.8-2-arm.pkg.tar.xz')

Looking through the coredump file with gdb only reveals:

$this->bbcode_second_pass_code('', 'Program terminated with signal SIGSYS, Bad system call')
kriztioan
 
Posts: 51
Joined: Sat Apr 29, 2017 1:32 am

Re: haveged 1.9.11-1 (armv5tel) code=dumped, signal=SYS

Postby starquake » Tue Jun 16, 2020 6:50 am

I have the same problem on Raspberry Pi 4 (armv7l). I switched to rngd from rng-tools which works fine and apparently is preferred judging from the wiki.

Why is haveged installed by default?
starquake
 
Posts: 6
Joined: Mon Jun 02, 2014 10:04 pm

Re: haveged 1.9.11-1 (armv5tel) code=dumped, signal=SYS

Postby haraldwithtwoehs » Tue Jun 16, 2020 3:29 pm

I removed all of the security hardening in /lib/systemd/system/haveged.service and it starts just fine - so the problem is not the daemon itself, but all of the hardening added by upstream arch linux. Note that the same configuration works fine on amd64 servers, so it's something raspberry pi specific.

I did a bit more editing and it's these two lines in /lib/systemd/system/haveged.service:

SystemCallFilter=@basic-io @file-system @io-event @network-io @signal
SystemCallFilter=arch_prctl brk ioctl mprotect sysinfo

Removing them (or commenting out) allows the daemon to start. So the issue may be that the daemon on raspberry Pi is making a system call that it doesn't make on x86 architectures.
haraldwithtwoehs
 
Posts: 8
Joined: Sat Oct 21, 2017 2:49 pm

Re: haveged 1.9.11-1 (armv5tel) code=dumped, signal=SYS

Postby kriztioan » Tue Jun 16, 2020 6:55 pm

@haraldwithwoehs My system is not a Raspberry Pi but rather runs a kirkwood-based SOC (armv5tel).

On my system /lib/systemd/system/haveged.service does not have the lines you mention:

$this->bbcode_second_pass_code('', '[Unit]
Description=Entropy Daemon based on the HAVEGE algorithm
Documentation=man:haveged(8) http://www.issihosts.com/haveged/
DefaultDependencies=no
After=systemd-tmpfiles-setup-dev.service
Before=sysinit.target shutdown.target systemd-journald.service

[Service]
ExecStart=/usr/sbin/haveged -w 1024 -v 1 --Foreground
Restart=always
SuccessExitStatus=137 143
CapabilityBoundingSet=CAP_SYS_ADMIN
PrivateDevices=true
PrivateNetwork=true
ProtectSystem=full

[Install]
WantedBy=sysinit.target')

Perhaps the CAP_SYS_ADMIN rights still blocks a syscall that shouldn't be blocked ... Today's update to libcap-2.35-1-arm seems to avoid the coredump for haveged-1.9.11-1-arm but the daemon still seems to restart every few seconds. Reverting back restores proper behavior.

@starquake rngd doesn't seem to work on my systemd ...
kriztioan
 
Posts: 51
Joined: Sat Apr 29, 2017 1:32 am

Re: haveged 1.9.11-1 (armv5tel) code=dumped, signal=SYS

Postby RonisBR » Thu Jun 18, 2020 3:48 am

I am also having this problem (Raspberry Pi Zero W), and removing those lines from the service solves it. Furthermore, the message when it crashes is:

$this->bbcode_second_pass_code('', '
jun 18 00:38:18 raspberrypi systemd-coredump[14764]: Process 14738 (haveged) of user 0 dumped core.

Stack trace of thread 14738:
#0 0x00000000b6fe40bc uname (/usr/lib/ld-2.31.so + 0x1b0bc)
#1 0x00000000b6fe1a7c _dl_discover_osversion (/usr/lib/ld-2.31.so + 0x18a7c)
')

Before removing those lines, the daemon were being restarted constantly, generating a lot of core dumps:

$this->bbcode_second_pass_code('', '
# coredumpctl -r
TIME PID UID GID SIG COREFILE EXE
Thu 2020-06-18 00:47:00 -03 21927 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:46:48 -03 21827 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:46:41 -03 21721 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:46:34 -03 21626 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:46:27 -03 21533 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:46:21 -03 21445 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:46:15 -03 21369 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:42:12 -03 18156 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:42:05 -03 18054 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:41:58 -03 17963 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:41:52 -03 17860 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:41:45 -03 17757 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:41:38 -03 17653 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:41:32 -03 17553 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:41:25 -03 17448 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:41:19 -03 17348 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:41:12 -03 17243 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:41:06 -03 17142 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:40:59 -03 17040 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:40:53 -03 16938 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:40:46 -03 16835 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:40:39 -03 16734 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:40:33 -03 16631 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:40:19 -03 16378 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:40:11 -03 16265 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:40:03 -03 16163 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:39:56 -03 16070 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:39:47 -03 15973 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:39:40 -03 15875 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:39:32 -03 15780 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:39:23 -03 15702 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:39:17 -03 15612 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:39:11 -03 15533 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:39:05 -03 15445 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:38:59 -03 15358 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:38:53 -03 15270 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:38:48 -03 15184 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:38:42 -03 15096 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:38:36 -03 15011 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:38:30 -03 14930 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:38:24 -03 14833 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:38:18 -03 14738 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:38:12 -03 14640 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:38:06 -03 14542 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:37:59 -03 14460 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:37:52 -03 14375 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:37:47 -03 14293 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:37:41 -03 14210 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:37:35 -03 14126 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:37:29 -03 14041 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:37:23 -03 13945 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:37:17 -03 13846 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:37:11 -03 13749 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:37:05 -03 13651 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:36:58 -03 13554 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:36:52 -03 13456 0 0 31 present /usr/bin/haveged
Thu 2020-06-18 00:36:46 -03 13362 0 0 31 present /usr/bin/haveged
')
RonisBR
 
Posts: 4
Joined: Mon Jun 15, 2020 6:27 pm

Re: haveged 1.9.11-1 (armv5tel) code=dumped, signal=SYS

Postby iefbr14 » Thu Jun 18, 2020 10:05 pm

Same coredump behavior on an Odroid-XU4 board (armv7h). Also had to revert back to haveged-1.9.8 package.

The recent update to systemd-swap-4.2.2 on the XU4 also constantly coredumps.

Haven't had time to dig any deeper into either dump situation -- just wanted to get the XU4 up and working so reverting packages was the quickest way.

Perhaps its noteworthy that haveged-1.9.11 and systemd-swap-4.2.2 on an Odroid-N2 (aarch64) are working fine (no dumps!) while the armv5 and armv7 are having issues.
iefbr14
 
Posts: 10
Joined: Sat Sep 16, 2017 4:09 am

Re: haveged 1.9.11-1 (armv5tel) code=dumped, signal=SYS

Postby xiretza » Sat Jun 20, 2020 8:32 pm

Still a problem with haveged 1.9.12-1 on armv7l, but adding `uname` to the syscall filter seems to fix the problem:

$this->bbcode_second_pass_code('', '
$ cat /run/systemd/system/haveged.service.d/override.conf
[Service]
SystemCallFilter=uname
')

$this->bbcode_second_pass_code('', '
$ sudo systemctl status haveged.service
● haveged.service - Entropy Daemon based on the HAVEGE algorithm
Loaded: loaded (/usr/lib/systemd/system/haveged.service; enabled; vendor preset: disabled)
Drop-In: /run/systemd/system/haveged.service.d
└─override.conf
Active: active (running) since Sat 2020-06-20 22:26:14 CEST; 3min 43s ago
Docs: man:haveged(8)
http://www.issihosts.com/haveged/
Main PID: 1045 (haveged)
Tasks: 1 (limit: 2062)
CGroup: /system.slice/haveged.service
└─1045 /usr/bin/haveged -w 1024 -v 1 --Foreground

Jun 20 22:26:14 orion systemd[1]: Started Entropy Daemon based on the HAVEGE algorithm.
Jun 20 22:26:14 orion haveged[1045]: haveged: command socket is listening at fd 3
Jun 20 22:26:20 orion haveged[1045]: haveged: ver: 1.9.12; arch: generic; vend: ; build: (gcc 9.3.0 CTV); collect: 128K
Jun 20 22:26:20 orion haveged[1045]: haveged: cpu: (VC); data: 16K (D); inst: 16K (D); idx: 11/40; sz: 14660/63044
Jun 20 22:26:20 orion haveged[1045]: haveged: tot tests(BA8): A:1/1 B:1/1 continuous tests(B): last entropy estimate 7.99824
Jun 20 22:26:20 orion haveged[1045]: haveged: fills: 0, generated: 0
')
xiretza
 
Posts: 2
Joined: Sat Apr 13, 2019 5:25 pm

Re: haveged 1.9.11-1 (armv5tel) code=dumped, signal=SYS

Postby kriztioan » Sun Jun 21, 2020 5:08 am

@xiretza Same on armv5tel; haveged 1.9.12-1 still has the same problem, but adding the SystemCallFilter as an override 'fixes'/avoids the issue. Looks like it is a sandboxing/seccomp-filtering issue.
kriztioan
 
Posts: 51
Joined: Sat Apr 29, 2017 1:32 am

Re: haveged 1.9.11-1 (armv5tel) code=dumped, signal=SYS

Postby xiretza » Sun Jun 21, 2020 9:48 am

FYI, the uname syscall comes from ld-linux/glibc, which uses it as a fallback for when "the kernel-supplied DSO [doesn't contain] a note indicating the kernel's version": https://github.com/bminor/glibc/blob/master/sysdeps/unix/sysv/linux/dl-sysdep.c#L87. Might be worth fixing that instead of patching around syscall filters for every binary in existence. Here's a comparison between the syscalls in Arch ARM and Arch x86-64 when executing `echo`:

$this->bbcode_second_pass_code('', '
armv7l $ strace echo
execve("/usr/bin/echo", ["echo"], 0x7ecb9c40 /* 24 vars */) = 0
brk(NULL) = 0x2342000
uname({sysname="Linux", nodename="orion", ...}) = 0
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76f2e000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=102611, ...}) = 0
mmap2(NULL, 102611, PROT_READ, MAP_PRIVATE, 3, 0) = 0x76ee5000
close(3) = 0
openat(AT_FDCWD, "/usr/lib/libc.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0l\255\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1628016, ...}) = 0
mmap2(NULL, 1373916, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x76d95000
mprotect(0x76ecf000, 65536, PROT_NONE) = 0
mmap2(0x76edf000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13a000) = 0x76edf000
mmap2(0x76ee3000, 5852, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x76ee3000
close(3) = 0
set_tls(0x76f2eca0) = 0
mprotect(0x76edf000, 8192, PROT_READ) = 0
mprotect(0x4ee000, 4096, PROT_READ) = 0
mprotect(0x76f30000, 4096, PROT_READ) = 0
munmap(0x76ee5000, 102611) = 0
brk(NULL) = 0x2342000
brk(0x2363000) = 0x2363000
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=3035952, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0x76b95000
mmap2(NULL, 2596864, PROT_READ, MAP_PRIVATE, 3, 0x6c000) = 0x7691b000
close(3) = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x1), ...}) = 0
write(1, "\n", 1
) = 1
close(1) = 0
close(2) = 0
exit_group(0) = ?
+++ exited with 0 +++
')

$this->bbcode_second_pass_code('', '
amd64 $ strace echo
execve("/usr/bin/echo", ["echo"], 0x7ffcd92f7bc0 /* 34 vars */) = 0
brk(NULL) = 0x55f97e864000
arch_prctl(0x3001 /* ARCH_??? */, 0x7ffc2dbde080) = -1 EINVAL (Invalid argument)
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=425744, ...}) = 0
mmap(NULL, 425744, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fe47658d000
close(3) = 0
openat(AT_FDCWD, "/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@q\2\0\0\0\0\0"..., 832) = 832
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
pread64(3, "\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0", 32, 848) = 32
pread64(3, "\4\0\0\0\24\0\0\0\3\0\0\0GNU\0\346~\200\347\6\31qw\t\343\30\16U*\21\242"..., 68, 880) = 68
fstat(3, {st_mode=S_IFREG|0755, st_size=2146832, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe47658b000
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
pread64(3, "\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0", 32, 848) = 32
pread64(3, "\4\0\0\0\24\0\0\0\3\0\0\0GNU\0\346~\200\347\6\31qw\t\343\30\16U*\21\242"..., 68, 880) = 68
mmap(NULL, 1860456, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe4763c4000
mprotect(0x7fe4763e9000, 1671168, PROT_NONE) = 0
mmap(0x7fe4763e9000, 1363968, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x25000) = 0x7fe4763e9000
mmap(0x7fe476536000, 303104, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x172000) = 0x7fe476536000
mmap(0x7fe476581000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bc000) = 0x7fe476581000
mmap(0x7fe476587000, 13160, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fe476587000
close(3) = 0
arch_prctl(ARCH_SET_FS, 0x7fe47658c580) = 0
mprotect(0x7fe476581000, 12288, PROT_READ) = 0
mprotect(0x55f97cead000, 4096, PROT_READ) = 0
mprotect(0x7fe476620000, 4096, PROT_READ) = 0
munmap(0x7fe47658d000, 425744) = 0
brk(NULL) = 0x55f97e864000
brk(0x55f97e885000) = 0x55f97e885000
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=3040304, ...}) = 0
mmap(NULL, 3040304, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fe4760dd000
close(3) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x2), ...}) = 0
write(1, "\n", 1
) = 1
close(1) = 0
close(2) = 0
exit_group(0) = ?
+++ exited with 0 +++
')

As can be seen, the loader uses arch_prctl on x86, but since that's not available on ARM, it has to use uname. Setting LD_ASSUME_KERNEL= as described in ld.so(8) does not seem to change anything.
xiretza
 
Posts: 2
Joined: Sat Apr 13, 2019 5:25 pm

Re: haveged 1.9.11-1 (armv5tel) code=dumped, signal=SYS

Postby NeilMunday » Sun Jun 21, 2020 10:09 am

Hi all,

Just to add I see the same issue on my old Raspberry Pi model B Rev 2 (armv6l).

Adding an ovveride for the haveged service resolved the issue for me also - thanks for info.

Cheers,

Neil.
NeilMunday
 
Posts: 21
Joined: Thu Feb 05, 2015 4:23 pm

Next

Return to Packages

Who is online

Users browsing this forum: No registered users and 8 guests