[Bug 1853852] Re: hard to reproduce issues in systemd autopkgtest against new libseccomp 2.4.2

[Christian Ehrhardt ]

I've simplified the test to a small case - running that I can reproduce the error.
This should be enough to go to upstreams with it.

cat > test-seccomp-shmat.c << EOF
#include <linux/seccomp.h>

#include <errno.h>
#include <seccomp.h>
#include <stdio.h>

#include <sys/shm.h>

/*
 * Test issues with libseccomp 2.4.1 -> 2.4.2
 * Derived from systemd testcase test_memory_deny_write_execute_shmat
 * which fails to install shmat rules with 2.4.2 on i386 and s390x
 */

int main()
{
   int shmat_syscall = -1;
   int rc = -1;
   scmp_filter_ctx ctx;

   ctx = seccomp_init(SCMP_ACT_ALLOW);
   if (ctx == NULL)
       return -1;

   shmat_syscall = SCMP_SYS(shmat);
   printf("SCMP_SYS(shmat) = %d\n", shmat_syscall);

   rc = seccomp_rule_add_exact(ctx, SCMP_ACT_ERRNO(EPERM), shmat_syscall, 1, SCMP_A2(SCMP_CMP_MASKED_EQ, SHM_EXEC, SHM_EXEC));
   printf("Rule installed RC = %d\n", rc);

   return 0;
}
EOF


$ gcc -Wall test-seccomp-shmat.c -o test-seccomp-shmat -lseccomp


i386:
2.4.1:
./test-seccomp-shmat
SCMP_SYS(shmat) = 397
Rule installed RC = 0
2.4.2
./test-seccomp-shmat
SCMP_SYS(shmat) = 397
Rule installed RC = -22

s390x looks identical to the i386 output

Note: rebuilding on new libseccomp2 does not change this behavior

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1853852

Title:
  hard to reproduce issues in systemd autopkgtest against new libseccomp
  2.4.2

Status in libseccomp package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Hi,
  I'm mostly reporting this if to one of the people watching systemd more closely this is in any form a known issue or if there are any hints.

  I recently merged libseccomp 2.4.2 and after a few initial cleanups that worked well.
  But on propsoed-migration I hit systemd test issues.

  I have read about issues with arm NR_open defines - I had the same in
  chrony - but that is fixed in libseccomp and that isn't failing in
  systemd.

  i386 and s390x (only those) have failing tests
  - http://autopkgtest.ubuntu.com/packages/s/systemd/focal/s390x
  - http://autopkgtest.ubuntu.com/packages/s/systemd/focal/i386

  Example:
  https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/s/systemd/20191120_105726_aea23@/log.gz

  Failnig subtests are:
  root-unittests       FAIL non-zero exit status 134
  upstream             FAIL non-zero exit status 1

  And looking at the details of root-unittest I found: http://paste.ubuntu.com/p/N7q9PX3hFN/
  ====== test-seccomp =======
  ...
  /* test_memory_deny_write_execute_mmap */
  Operating on architecture: s390
  Failed to add shmat() rule for architecture s390, skipping: Invalid argument
  Operating on architecture: s390x
  Failed to add shmat() rule for architecture s390x, skipping: Invalid argument
  Assertion 'p == MAP_FAILED' failed at src/test/test-seccomp.c:493, function test_memory_deny_write_execute_mmap(). Aborting.
  memoryseccomp-mmap terminated by signal ABRT.
  Assertion 'wait_for_terminate_and_check("memoryseccomp-mmap", pid, WAIT_LOG) == EXIT_SUCCESS' failed at src/test/test-seccomp.c:507, function test_memory_deny_write_execute_mmap(). Aborting.
  FAIL: test-seccomp (code: 134)

  But when installing source of systemd and the new libseccomp in a
  Focal VM with proposed enabled it works just fine. Actually I just
  found that it does have a good RC but breaks so maybe it is debuggable
  after all.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1853852/+subscriptions