I tried to #undef __NR_socket in the systemd sources, to see where this
value is actually being used. Turns out it is in
https://github.com/systemd/systemd/blob/master/src/nspawn/nspawn.c#L1577
in setup_seccomp():
r = seccomp_rule_add(
seccomp,
SCMP_ACT_ERRNO(EAFNOSUPPORT),
SCMP_SYS(socket),
2,
SCMP_A0(SCMP_CMP_EQ, AF_NETLINK),
SCMP_A2(SCMP_CMP_EQ, NETLINK_AUDIT));
if (r < 0) {
log_error_errno(r, "Failed to add audit seccomp rule: %m");
where SCMP_SYS is a macro from libseccomp-dev (/usr/include/seccomp.h):
/**
* Convert a syscall name into the associated syscall number
* @param x the syscall name
*/
#define SCMP_SYS(x) (__NR_##x)
So this links the new syscall definition to seccomp. Apparently
seccomp_rule_add() (in the same seccomp.h file) behaves differently if
the syscall is defined. I just wonder how this actually built on i386
with the 4.2.0 kernel headers which did not have __NR_socket defined?
With current 4.3 kernel headers, the value of SCMP_SYS(socket) == 359,
as defined above. With the previous 4.2 kernel headers, the value is
4294967195 == 0xFFFFFF9B instead, apparently some auto-generated value.
So this explains how it built before.
So it looks like this might be between libseccomp and the kernel now?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1526358
Title:
xenial/i386 regression: nspawn fails with "Failed to add audit seccomp
rule: Bad address"
Status in linux package in Ubuntu:
Confirmed
Status in systemd package in Ubuntu:
Triaged
Bug description:
Four days ago, on Dec 10,
http://autopkgtest.ubuntu.com/packages/s/systemd/xenial/i386/ started
failing:
======================================================================
FAIL: test_boot (__main__.NspawnTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/tmp/adt-run.IG1dKn/build.Yzd/systemd-228/debian/tests/boot-and-services",
line 204, in test_boot
self.assertIn(b'fake container started', out)
AssertionError: b'fake container started' not found in b'Spawning container
c1 on /tmp/tmpl04y_tf8/c1.\nPress ^] three times within 1s to kill
container.\nFailed to create directory /tmp/tmpl04y_tf8/c1/sys/fs/selinux:
Read-only file system\nFailed to create directory
/tmp/tmpl04y_tf8/c1/sys/fs/selinux: Read-only file system\nFailed to add audit
seccomp rule: Bad address\n'
This is reproducible in xenial-release, i. e. it already slipped
through -proposed.
This can be reproduced easily on a xenial i386 VM:
sudo apt-get install busybox-static
mkdir -p /tmp/c/sbin /tmp/c/etc /tmp/c/bin/
cp /bin/busybox /tmp/c/bin/
ln -s ../bin/busybox /tmp/c/sbin/init
ln -s busybox /tmp/c/bin/sh
cp /etc/os-release /tmp/c/etc
sudo systemd-nspawn -b -D /tmp/c
This should normally boot a busybox container; you'll get a few error
messages as there's no SysV init stuff there, but it should start and
pressing enter should get you into a shell. But on i386 it fails with
$ sudo systemd-nspawn -b -D /tmp/c
Spawning container c on /tmp/c.
Press ^] three times within 1s to kill container.
Failed to create directory /tmp/c/sys/fs/selinux: Read-only file system
Failed to create directory /tmp/c/sys/fs/selinux: Read-only file system
Failed to add audit seccomp rule: Bad address
which is what the test case fails on too.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1526358/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
