Well this change made the ID 392 "known" to all architectures (in a try
to sync numbers across everywhere) but it fails on those it isn't
implemented (32bit, ppc, s390x + sparc which we don't have).
The path registering these calls goes
seccomp_rule_add
-> seccomp_rule_add_array
-> db_col_valid
-> _syscall_valid
-> db_col_rule_add <- still -204/392
-> _db_rule_new
-> db_col_transaction_start <- dups old rule (-201) ITERATES
-> arch_filter_rule_add
-> arch_syscall_translate
-> arch_syscall_resolve_num <- returns "semop" for -201
-> arch_syscall_resolve_name <- returns -201 for "semop"
Returns RC=0 (db_col_transaction_start)
The above defined the transaction start
-> arch_filter_rule_add <- this adds the new rule -204/392
-> arch_syscall_translate
-> arch_syscall_resolve_num
Good case returns "semtimedop" for
Bad case returns 0x0 for 392
From here it now returns -EFAULT (=> -14) and things break
So we enter:
Good: Breakpoint 14, s390x_syscall_resolve_num (num=-204) at
arch-s390x-syscalls.c:533
Bad: Breakpoint 13, s390x_syscall_resolve_num (num=392) at
arch-s390x-syscalls.c:533
This searches the table s390x_syscall_table and fails to find 392, from there
things break.
The worst is, that "semtimedop" is there, but with __PNR_semtimedop as number.
As it used to have no number yet when last time generated.
If it would use __NR_semtimedop instead of __PNR_semtimedop it might even work
as-is.
I'm not sure if src/arch-s390x-syscalls.c is allowed to use include/seccomp.h
(where these compat defines are).
I need to suggest that upstream (or check if a change exists)
Summary of the above:
- kernel change defined numbers for all calls (implemented or not)
- due to that no more the fallback "#define __PNR_semtimedop -204" but provided
392 is used
- arch_syscall_translate tries to translate 392 in the context of the native
architecure to the provided architecture and fails
- src/arch-s390x-syscalls.c contains syscall tables derived from 4.15-rc7 which
need to be updated
- Definitions in this table should use __NR_ instead of __PNR_ to get the
kernel value once it is defined (will be ==__PNR when not defined)
- Even if not using __NR it needs a redefine for newer kernels
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1849785
Title:
FTBFS on i386/ppc64/s390x (Eoan+Focal)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1849785/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
