Merge ~paelzer/ubuntu/+source/systemd:focal-fix-vs-new-libseccomp into ~ubuntu-core-dev/ubuntu/+source/systemd:ubuntu-focal

[Christian Ehrhardt ]

[Christian Ehrhardt  (paelzer)]

Hi,
this isn't in 244 upstream so we will need it sooner or later I guess.
Unless you plan to directly go to 245 at some point.

Without the fix systemd and the new libseccomp won't work together.
If we decide to accept, but postpone this upload (since systemd uploads are rather work intensive) I'd ask if you agree that we force-badtest the tests for now to get things in focal migrating again.

[Balint Reczey (rbalint)]

LGTM, thanks for the thorough follow-up.

It arrived just in time to be in the 244 upload. :-)

review: Approve

[Christian Ehrhardt  (paelzer)]

Great, glad to hear that - if there is anything from my side to do on this let me know.
Otherwise I'll leave it in your and the 244 uploads hands.

diff --git a/debian/changelog b/debian/changelog
index 480f1c2..b67c6ea 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+systemd (243-3ubuntu2) focal; urgency=medium
+
+  * fix issues with muliplexed shmat calls (LP: #1853852)
+    - d/p/lp-1853852-*: add upstream backports
+    - drop d/p/test-expect-mmap-to-fail-in-seccomp-test-on-s390-and-s390.patch
+
+ -- Christian Ehrhardt <[e-mail]>  Mon, 09 Dec 2019 12:57:07 +0100
+
 systemd (243-3ubuntu1) focal; urgency=medium
 
   [ Dan Streetman ]
diff --git a/debian/patches/lp-1853852-seccomp-fix-multiplexed-system-calls.patch b/debian/patches/lp-1853852-seccomp-fix-multiplexed-system-calls.patch
new file mode 100644
index 0000000..2faee37
--- /dev/null
+++ b/debian/patches/lp-1853852-seccomp-fix-multiplexed-system-calls.patch
@@ -0,0 +1,74 @@
+From bed4668d1daeb640c1d55e79e6a1725c81118e39 Mon Sep 17 00:00:00 2001
+From: Christian Ehrhardt <[e-mail]>
+Date: Wed, 27 Nov 2019 09:52:07 +0100
+Subject: [PATCH] seccomp: fix multiplexed system calls
+
+Since libseccomp 2.4.2 more architectures have shmat handled as multiplexed
+call. Those will fail to be added due to seccomp_rule_add_exact failing
+on them since they'd need to add multiple rules [1].
+See the discussion at https://github.com/seccomp/libseccomp/issues/193
+
+After discussions about the options rejected [2][3] the initial thought of
+a fallback to the non '_exact' version of the seccomp rule adding the next
+option is to handle those now affected (i386, s390, s390x) the same way as
+ppc which ignores and does not block shmat.
+
+[1]: https://github.com/seccomp/libseccomp/issues/193
+[2]: https://github.com/systemd/systemd/pull/14167#issuecomment-559136906
+[3]: https://github.com/systemd/systemd/commit/469830d1
+
+Origin: upstream, https://github.com/systemd/systemd/commit/bed4668d1daeb640c1d55e79e6a1725c81118e39
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1853852
+Last-Update: 2019-12-09
+
+---
+ src/shared/seccomp-util.c | 16 ++++++++--------
+ 1 file changed, 8 insertions(+), 8 deletions(-)
+
+diff --git a/src/shared/seccomp-util.c b/src/shared/seccomp-util.c
+index bd4f004cc8..fc813dd515 100644
+--- a/src/shared/seccomp-util.c
++++ b/src/shared/seccomp-util.c
+@@ -1593,22 +1593,23 @@ int seccomp_memory_deny_write_execute(void) {
+ 
+                 switch (arch) {
+ 
++                /* Note that on some architectures shmat() isn't available, and the call is multiplexed through ipc().
++                 * We ignore that here, which means there's still a way to get writable/executable
++                 * memory, if an IPC key is mapped like this. That's a pity, but no total loss. */
++
+                 case SCMP_ARCH_X86:
+                 case SCMP_ARCH_S390:
+                         filter_syscall = SCMP_SYS(mmap2);
+                         block_syscall = SCMP_SYS(mmap);
+-                        shmat_syscall = SCMP_SYS(shmat);
++                        /* shmat multiplexed, see above */
+                         break;
+ 
+                 case SCMP_ARCH_PPC:
+                 case SCMP_ARCH_PPC64:
+                 case SCMP_ARCH_PPC64LE:
++                case SCMP_ARCH_S390X:
+                         filter_syscall = SCMP_SYS(mmap);
+-
+-                        /* Note that shmat() isn't available, and the call is multiplexed through ipc().
+-                         * We ignore that here, which means there's still a way to get writable/executable
+-                         * memory, if an IPC key is mapped like this. That's a pity, but no total loss. */
+-
++                        /* shmat multiplexed, see above */
+                         break;
+ 
+                 case SCMP_ARCH_ARM:
+@@ -1619,8 +1620,7 @@ int seccomp_memory_deny_write_execute(void) {
+                 case SCMP_ARCH_X86_64:
+                 case SCMP_ARCH_X32:
+                 case SCMP_ARCH_AARCH64:
+-                case SCMP_ARCH_S390X:
+-                        filter_syscall = SCMP_SYS(mmap); /* amd64, x32, s390x, and arm64 have only mmap */
++                        filter_syscall = SCMP_SYS(mmap); /* amd64, x32 and arm64 have only mmap */
+                         shmat_syscall = SCMP_SYS(shmat);
+                         break;
+ 
+-- 
+2.24.0
+
diff --git a/debian/patches/lp-1853852-seccomp-mmap-test-results-depend-on-kernel-libseccom.patch b/debian/patches/lp-1853852-seccomp-mmap-test-results-depend-on-kernel-libseccom.patch
new file mode 100644
index 0000000..ca68178
--- /dev/null
+++ b/debian/patches/lp-1853852-seccomp-mmap-test-results-depend-on-kernel-libseccom.patch
@@ -0,0 +1,49 @@
+From 49219b5c2a654ee6639887aa21a78b41da0576f1 Mon Sep 17 00:00:00 2001
+From: Christian Ehrhardt <[e-mail]>
+Date: Wed, 4 Dec 2019 11:44:32 +0100
+Subject: [PATCH] seccomp: mmap test results depend on kernel/libseccomp/glibc
+
+Like with shmat already the actual results of the test
+test_memory_deny_write_execute_mmap depend on kernel/libseccomp/glibc
+of the platform it is running on.
+
+There are known-good platforms, but on the others do not assert success
+(which implies test has actually failed as no seccomp blocking was achieved),
+but instead make the check dependent to the success of the mmap call
+on that platforms.
+
+Finally the assert of the munmap on that valid pointer should return ==0,
+so that is what the check should be for in case of p != MAP_FAILED.
+
+Signed-off-by: Christian Ehrhardt <[e-mail]>
+
+Origin: upstream, https://github.com/systemd/systemd/commit/49219b5c2a654ee6639887aa21a78b41da0576f1
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1853852
+Last-Update: 2019-12-09
+
+---
+ src/test/test-seccomp.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/src/test/test-seccomp.c b/src/test/test-seccomp.c
+index 7323e79f7b..69b1c788aa 100644
+--- a/src/test/test-seccomp.c
++++ b/src/test/test-seccomp.c
+@@ -535,10 +535,11 @@ static void test_memory_deny_write_execute_mmap(void) {
+ #if defined(__x86_64__) || defined(__i386__) || defined(__powerpc64__) || defined(__arm__) || defined(__aarch64__)
+                 assert_se(p == MAP_FAILED);
+                 assert_se(errno == EPERM);
+-#else /* unknown architectures */
+-                assert_se(p != MAP_FAILED);
+-                assert_se(munmap(p, page_size()) >= 0);
+ #endif
++                /* Depending on kernel, libseccomp, and glibc versions, other architectures
++                 * might fail or not. Let's not assert success. */
++                if (p != MAP_FAILED)
++                        assert_se(munmap(p, page_size()) == 0);
+ 
+                 p = mmap(NULL, page_size(), PROT_WRITE|PROT_READ, MAP_PRIVATE|MAP_ANONYMOUS, -1,0);
+                 assert_se(p != MAP_FAILED);
+-- 
+2.24.0
+
diff --git a/debian/patches/series b/debian/patches/series
index 39b84c6..5db6572 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -76,7 +76,6 @@ fix-build-with-compilers-with-default-stack-protector-ena.patch
 cgroup-fix-typo-in-BPF-firewall-support-warning-message.patch
 docs-fix-inadvertent-change-in-uid-range.patch
 test-Pass-personality-test-even-when-i686-userland-runs-o.patch
-test-expect-mmap-to-fail-in-seccomp-test-on-s390-and-s390.patch
 resolved-set-stream-type-during-DnsStream-creation.patch
 boot-Load-LoadOptions-cmdline-if-none-is-available.patch
 debian/Use-Debian-specific-config-files.patch
@@ -119,3 +118,5 @@ Revert-cgroup-Continue-unit-reset-if-cgroup-is-busy.patch
 Revert-network-fix-assertion-when-link-get-carrier.patch
 Revert-network-prevent-interfaces-to-be-initialized-multi.patch
 rules-Add-automatic-suspend-udev-rules.patch
+lp-1853852-seccomp-fix-multiplexed-system-calls.patch
+lp-1853852-seccomp-mmap-test-results-depend-on-kernel-libseccom.patch
diff --git a/debian/patches/test-expect-mmap-to-fail-in-seccomp-test-on-s390-and-s390.patch b/debian/patches/test-expect-mmap-to-fail-in-seccomp-test-on-s390-and-s390.patch
deleted file mode 100644
index db05715..0000000
--- a/debian/patches/test-expect-mmap-to-fail-in-seccomp-test-on-s390-and-s390.patch
+++ /dev/null
@@ -1,22 +0,0 @@
-From: Balint Reczey <[e-mail]>
-Date: Tue, 22 Oct 2019 17:10:17 +0200
-Subject: test: expect mmap to fail in seccomp test on s390 and s390x
-
-(cherry picked from commit a81f7aad9a5ddeebbce002e2da36e1dd84f51b36)
----
- src/test/test-seccomp.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/src/test/test-seccomp.c b/src/test/test-seccomp.c
-index a906070..9881768 100644
---- a/src/test/test-seccomp.c
-+++ b/src/test/test-seccomp.c
-@@ -489,7 +489,7 @@ static void test_memory_deny_write_execute_mmap(void) {
-                 assert_se(seccomp_memory_deny_write_execute() >= 0);
- 
-                 p = mmap(NULL, page_size(), PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1,0);
--#if defined(__x86_64__) || defined(__i386__) || defined(__powerpc64__) || defined(__arm__) || defined(__aarch64__)
-+#if defined(__x86_64__) || defined(__i386__) || defined(__powerpc64__) || defined(__arm__) || defined(__aarch64__) || defined(__s390__) || defined(__s390x__)
-                 assert_se(p == MAP_FAILED);
-                 assert_se(errno == EPERM);
- #else /* unknown architectures */