Bug#1055285: libseccomp misbehave on loong64

2023-11-05 Thread Felix Geyer

Hi,

On 03.11.23 15:39, Miao Wang wrote:

Package: libseccomp2
Version: 2.5.4-1+loong64
Severity: normal
Tags: patch

libseccomp2 in debian ports lonng64 cannot work properly because it is using a
wrong mapping between syscall numbers and names, which can be reproduced by
first installing package seccomp and then execute:

```
scmp_sys_resolver accept
```

The syscall number in the output is not correct, which should be 202 on loong64
architecture.


Please report this to debian-loonga...@lists.debian.org instead since
version 2.5.4-1+loong64 is not part of the Debian archive but added
by the loongarch porter team.

Felix



Bug#1055285: libseccomp misbehave on loong64

2023-11-03 Thread Miao Wang
Package: libseccomp2
Version: 2.5.4-1+loong64
Severity: normal
Tags: patch

libseccomp2 in debian ports lonng64 cannot work properly because it is using a
wrong mapping between syscall numbers and names, which can be reproduced by
first installing package seccomp and then execute:

```
scmp_sys_resolver accept
```

The syscall number in the output is not correct, which should be 202 on loong64
architecture. 

The root cause of this bug lies in the patch
`add-loongarch64-support-from-libseccomp-upstream.patch` applied in the version
2.5.4-1+loong64: 

```
--- libseccomp-2.5.4.orig/src/syscalls.csv
+++ libseccomp-2.5.4/src/syscalls.csv
@@ -1,4 +1,4 @@
-#syscall (v5.17.0 
2022-04-05),x86,x86_64,x32,arm,aarch64,mips,mips64,mips64n32,parisc,parisc64,ppc,ppc64,riscv64,s390,s390x
+#syscall (v5.17.0 
2022-04-05),x86,x86_64,x32,arm,aarch64,loongarch64,mips,mips64,mips64n32,parisc,parisc64,ppc,ppc64,riscv64,s390,s390x
accept,PNR,43,43,285,202,168,42,42,35,35,330,330,202,PNR,PNR
accept4,364,288,288,366,242,334,293,297,320,320,344,344,242,364,364
access,33,21,21,33,PNR,33,20,20,33,33,33,33,PNR,33,33
```

which only changes the header of the syscall table but fails to include syscall
numbers for loong64 architecture. The result is that on loong64 architecture,
the syscall number mapping for mips is actually in effect. All the mappings for
architectures listed after mips are also wrong. Especially for s390x, when
trying to convert between syscall names and numbers, memory overflow will
happen and the output will be totally garbage.

This issue prevents container manage applications such as Podman from working
correctly on loong64 architecture.

To fix this issue, correct syscall mapping should be introduced. The attached
patch (on top of the original patch) should work. It also includes a fix for
the tests so that the package can be built without nocheck.

Cheers,

Miao Wang

Index: libseccomp-2.5.4/include/seccomp-syscalls.h
===
--- libseccomp-2.5.4.orig/include/seccomp-syscalls.h
+++ libseccomp-2.5.4/include/seccomp-syscalls.h
@@ -276,6 +276,7 @@
 #define __PNR_renameat -10242
 #define __PNR_riscv_flush_icache   -10243
 #define __PNR_memfd_secret -10244
+#define __PNR_fstat-10245
 
 /*
  * libseccomp syscall definitions
Index: libseccomp-2.5.4/src/syscalls.csv
===
--- libseccomp-2.5.4.orig/src/syscalls.csv
+++ libseccomp-2.5.4/src/syscalls.csv
@@ -1,482 +1,482 @@
 #syscall (v5.17.0 
2022-04-05),x86,x86_64,x32,arm,aarch64,loongarch64,mips,mips64,mips64n32,parisc,parisc64,ppc,ppc64,riscv64,s390,s390x
-accept,PNR,43,43,285,202,168,42,42,35,35,330,330,202,PNR,PNR
-accept4,364,288,288,366,242,334,293,297,320,320,344,344,242,364,364
-access,33,21,21,33,PNR,33,20,20,33,33,33,33,PNR,33,33
-acct,51,163,163,51,89,51,158,158,51,51,51,51,89,51,51
-add_key,286,248,248,309,217,280,239,243,264,264,269,269,217,278,278
-adjtimex,124,159,159,124,171,124,154,154,124,124,124,124,171,124,124
-afs_syscall,137,183,183,PNR,PNR,137,176,176,PNR,PNR,137,137,PNR,137,137
-alarm,27,37,37,PNR,PNR,27,37,37,27,27,27,27,PNR,27,27
-arch_prctl,384,158,158,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR
-arm_fadvise64_64,PNR,PNR,PNR,270,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR
-arm_sync_file_range,PNR,PNR,PNR,341,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR
-bdflush,134,PNR,PNR,134,PNR,134,PNR,PNR,134,134,134,134,PNR,134,134
-bind,361,49,49,282,200,169,48,48,22,22,327,327,200,361,361
-bpf,357,321,321,386,280,355,315,319,341,341,361,361,280,351,351
-break,17,PNR,PNR,PNR,PNR,17,PNR,PNR,PNR,PNR,17,17,PNR,PNR,PNR
-breakpoint,PNR,PNR,PNR,983041,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR
-brk,45,12,12,45,214,45,12,12,45,45,45,45,214,45,45
-cachectl,PNR,PNR,PNR,PNR,PNR,148,198,198,PNR,PNR,PNR,PNR,PNR,PNR,PNR
-cacheflush,PNR,PNR,PNR,983042,PNR,147,197,197,PNR,PNR,PNR,PNR,PNR,PNR,PNR
-capget,184,125,125,184,90,204,123,123,106,106,183,183,90,184,184
-capset,185,126,126,185,91,205,124,124,107,107,184,184,91,185,185
-chdir,12,80,80,12,49,12,78,78,12,12,12,12,49,12,12
-chmod,15,90,90,15,PNR,15,88,88,15,15,15,15,PNR,15,15
-chown,182,92,92,182,PNR,202,90,90,180,180,181,181,PNR,182,212
-chown32,212,PNR,PNR,212,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,212,PNR
-chroot,61,161,161,61,51,61,156,156,61,61,61,61,51,61,61
-clock_adjtime,343,305,305,372,266,341,300,305,324,324,347,347,266,337,337
-clock_adjtime64,405,PNR,PNR,405,PNR,405,PNR,405,405,PNR,405,PNR,PNR,405,PNR
-clock_getres,266,229,229,264,114,264,223,227,257,257,247,247,114,261,261
-clock_getres_time64,406,PNR,PNR,406,PNR,406,PNR,406,406,PNR,406,PNR,PNR,406,PNR
-clock_gettime,265,228,228,263,113,263,222,226,256,256,246,246,113,260,260
-clock_gettime64,403,PNR,PNR,403,PNR,403,PNR,403,403,PNR,403,PNR,PNR,403,PNR
-clock_nanosleep,267,230,230,265,115,265,224,228,258,258,248,248,115,262,262
-clock_nanosleep_time64,