seccomp_memory_deny_write_execute [1] in src/shared/seccomp-util.c is the one setting the seccomp rules called from test test_memory_deny_write_execute_mmap
It fails at: test_memory_deny_write_execute_mmap But later on we usually get debug info about used syscalls at: test_memory_deny_write_execute_shmat [2] Lets compare this debug info in good/bad case just exchaning libseccomp 2.4.1 <-> 2.4.2 The test aborts at the first error, so we need to "mask" the test_memory_deny_write_execute_mmap to get that data. Also with the "fix" for the new seccomp obviously the old one is failing. Note that at test_memory_deny_write_execute_shmat the arch list expected to work is just: #if defined(__x86_64__) || defined(__arm__) || defined(__aarch64__) While at test_memory_deny_write_execute_mmap it was #if defined(__x86_64__) || defined(__i386__) || defined(__powerpc64__) || defined(__arm__) || defined(__aarch64__) || defined(__s390__) || defined(__s390x__) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
