seccomp-util: fix alarming debug message (#8002, #8001)
authorAlan Jenkins <alan.christopher.jenkins@gmail.com>
Wed, 31 Jan 2018 17:11:47 +0000 (17:11 +0000)
committerAlan Jenkins <alan.christopher.jenkins@gmail.com>
Wed, 31 Jan 2018 17:20:14 +0000 (17:20 +0000)
Booting with `systemd.log_level=debug` and looking in `dmesg -u` showed
messages like this:

    systemd[433]: Failed to add rule for system call n/a() / 156, ignoring:
    Numerical argument out of domain

This commit fixes it to:

    systemd[449]: Failed to add rule for system call _sysctl() / 156,
    ignoring: Numerical argument out of domain

Some of the messages could be even more misleading, e.g. we were reporting
that utimensat() / 320 was skipped as non-existent on x86, when actually
the syscall number 320 is kexec_file_load() on x86 .

The problem was that syscall NRs are looked up (and correctly passed to
libseccomp) as native syscall NRs.  But we forgot that when we tried to
go back from the syscall NR to the name.

I think the natural way to write this would be
seccomp_syscall_resolve_num(nr), however there is no such function.
I couldn't work out a short comment that would make this clearer.  FWIW
I wrote it up as a ticket for libseccomp instead.
https://github.com/seccomp/libseccomp/issues/104

src/shared/seccomp-util.c

index fbb232c..e4bc803 100644 (file)
@@ -935,7 +935,7 @@ int seccomp_load_syscall_filter_set_raw(uint32_t default_action, Hashmap* set, u
                                 /* If the system call is not known on this architecture, then that's fine, let's ignore it */
                                 _cleanup_free_ char *n = NULL;
 
-                                n = seccomp_syscall_resolve_num_arch(arch, PTR_TO_INT(id) - 1);
+                                n = seccomp_syscall_resolve_num_arch(SCMP_ARCH_NATIVE, PTR_TO_INT(id) - 1);
                                 log_debug_errno(r, "Failed to add rule for system call %s() / %d, ignoring: %m", strna(n), PTR_TO_INT(id) - 1);
                         }
                 }