sdwdate loop - Conclusion: Tor already reports circuit established. - seccomp issue

Support
1

my VM was working fine but after running upgrade-nonroot sdwdate is stuck in a loop:

__ Conclusion: Tor already reports circuit established.
__ ### END: ### Exiting with exit_code '0' indicating 'success'.
2022-01-28 22:29:04 - sdwdate - INFO - PREPARATION RESULT: SUCCESS.
2022-01-28 22:29:04 - sdwdate - INFO -

Anyone else with this problem?

ERROR: Time Synchronization Result:
systemcheck gave up waiting.

Time synchronization status: pending
sdwdate reports: nothing yet.
whonix_firewall status: first run after boot

Possible issues:

  • sdwdate will need a few more moments for fetching the time.
  • sdwdate time sources might be dysfunctional.
2

No such reports.

The log is too short to tell anything.

3

Here’s more logs: https://pastebin.com/raw/QjdSybNR

After this part it spawn a new process ID and keep looping the same logs forever

2022-01-29 20:12:10 - sdwdate - INFO - PREPARATION RESULT: SUCCESS.
2022-01-29 20:12:10 - sdwdate - INFO -

systemcheck logs: https://pastebin.com/raw/8LZmh9Zk

4

I built a brand new UTM VM from 16.0.3.8-developers-only and the sdwdate issue is also present there.

I’m not sure how to debug this issue, I tried to run the python file directly and it seems to work fine except at the end it cannot set the date, but that’s probably because I’m running it wrong.

logs: https://pastebin.com/raw/4pEz9ncX

5

https://www.whonix.org/wiki/Troubleshooting#Daemon_Log_View required for sdwdate.

6

Quite possibly another seccomp issue, see this post: Whonix on Mac M1 (ARM) - User Support (still unsupported at time of writing) - #162 by Patrick

7

I did configure -rtc base=utc in QEMU parameters, but nothing changed.
Surely this issue affect all the aarch64 builds, right? So people just didn’t realize it yet. Or can it be related to my setup?

Daemon log view: https://pastebin.com/raw/vLWTPJ50

SECCOMP audit log:

Jan 30 15:50:36 host audit[3328]: SECCOMP auid=4294967295 uid=102 gid=108 ses=4294967295 subj==/usr/bin/sdwdate (enforce) pid=3328 comm="sdwdate" exe="/usr/bin/python3.9" sig=31 arch=c00000b7 syscall=35 compat=0 ip=0xf37077846c74 code=0x80000000

Does it means there’s a whitelist missing in the SECCOMP ?
syscall=35 name according to systemd/syscalls-arm64.txt at main · systemd/systemd · GitHub is unlinkat

1 Like
8

oh I managed to fix it!
Basically I just added unlinkat to the SECCOMP whitelist and then it worked:

user@host:~$ cat /lib/systemd/system/sdwdate.service.d/20_arch_syscall_whitelist.conf 
## This file has been auto-generated by: /var/lib/dpkg/info/sdwdate.postinst
## Changes will be lost when sdwdate is upgraded.
## See file /lib/systemd/system/sdwdate.service for comments.
## Architecture: aarch64

[Service]
SystemCallFilter=faccessat readlinkat newfstatat mkdirat dup3 ppoll pselect6 unlinkat

user@host:~$ systemctl status sdwdate
● sdwdate.service - Secure Distributed Web Date
     Loaded: loaded (/lib/systemd/system/sdwdate.service; enabled; vendor preset: enabled)
    Drop-In: /lib/systemd/system/sdwdate.service.d
             └─20_arch_syscall_whitelist.conf
     Active: active (running) since Sun 2022-01-30 16:03:07 UTC; 2min 6s ago
       Docs: https://www.whonix.org/wiki/sdwdate
   Main PID: 821 (sdwdate)
     Status: "Running sdwdate main loop. iteration: 1 / 10000"
      Tasks: 2 (limit: 2257)
     Memory: 22.4M
        CPU: 988ms
     CGroup: /system.slice/sdwdate.service
             ├─ 821 /usr/bin/python3 -u /usr/bin/sdwdate
             └─1222 sleep 8548.757159774

Is this a proper fix?

1 Like
9

Could you please send a pull request?

10

done it, thanks Patrick!

1 Like
11

wait I sent you pull request for sdwdate.service but that’s only for x86 right? For ARM64 it should be in 20_arch_syscall_whitelist.conf

1 Like
12

Yes, good catch.

13

Another related issue is that I had to ask for this:

Wasn’t included in sdwdate-log-viewer.

sdwdate/usr/bin/sdwdate-log-viewer at master · Kicksecure/sdwdate · GitHub

This obfuscated this being a seccomp issue.

14

ok I closed the pull request #35 and opened #36 to edit the script that will create 20_arch_syscall_whitelist.conf

1 Like
15
1 Like