Merge version 2.4.4-1+rpi1 and 2.5.0-3 to produce 2.5.0-3+rpi1

Merge libseccomp (2.5.0-3) import into refs/heads/workingbranch

[PATCH] arch: ensure we don't "munge" pseudo syscall numbers

A number of arches/ABIs have either syscall offsets (the MIPS
family) or specific bits (x32) which are applied to their normal
syscall numbers.  We generally handle that via "munging" in
libseccomp, and it works reasonably well.  Unfortunately we were
applying this munging process to the negative pseudo syscall
numbers as well and this was causing problems.

This patch fixes the various offset/bit arches/ABIs by not applying
the munging to the negative pseudo syscall numbers.

This resolves GH issue #284:
* https://github.com/seccomp/libseccomp/issues/284

Reported-by: Harald van Dijk <harald@gigawatt.nl>
Acked-by: Tom Hromatka <tom.hromatka@oracle.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
(imported from commit 34cde704979defcbddb8eea64295acf0e477c250)

Gbp-Pq: Name arch_ensure_we_dont_munge_pseudo_syscall_numbers.patch

[PATCH] tests: use openat and fstat instead of open and stat syscalls in tests 04 and 06

Architectures like aarch64 and riscv64, and all future architectures that
use the generic syscall table, do not support the open and stat syscalls.
Use the openat and fstat syscalls instead.

Signed-off-by: Andreas Schwab <schwab@suse.de>
Acked-by: Tom Hromatka <tom.hromatka@oracle.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
(imported from commit a317fabc1fd915f19f7e7326bf7dcb77493f1210)

Gbp-Pq: Name tests_use_openat_and_fstat_instead_of_open_and_stat_syscalls.patch

[PATCH] build: undefine "mips" to prevent build problems for MIPS targets

It turns out that the MIPS GCC compiler defines a "mips" cpp macro
which was resulting in build failures on MIPS so we need to
undefine the "mips" macro during build.  As this should be safe
to do in all architectures, just add it to the compiler flags by
default.

This was reported in the following GH issue:
* https://github.com/seccomp/libseccomp/issues/274

Reported-by: Rongwei Zhang <pudh4418@gmail.com>
Suggested-by: Rongwei Zhang <pudh4418@gmail.com>
Acked-by: Tom Hromatka <tom.hromatka@oracle.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
(imported from commit 5cd9059618a0810ee47c21e6b44c5a876b75e23d)

Gbp-Pq: Name build_undefine_mips_to_prevent_build_problems.patch

[PATCH] system: change our notification fd handling

This commit changes how we handle the notification fd by only
requesting it via _NEW_LISTENER if the filter has a _NOTIFY action
in it.  We also augment the seccomp_reset(NULL, ...) behavior so
that it closes the notification fd before resetting the global
state; applications that need to keep their notification fd open
across a call to seccomp_reset(NULL, ...) can simply dup() it.
Although one would have to wonder why the application would be
calling seccomp_reset(NULL, ...) in that case.

Acked-by: Tom Hromatka <tom.hromatka@oracle.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
(imported from commit 02812f99e8d1df2e671dac675b4af663d0266303)

Gbp-Pq: Name system_change_our_notification_fd_handling.patch

[PATCH] all: only request the userspace notification fd once

It turns out that requesting the seccomp userspace notifcation fd
more than once is a bad thing which causes the kernel to complain
(rightfully so for a variety of reasons).  Unfortunately as we were
always requesting the notification fd whenever possible this results
in problems at filter load time.

Our solution is to move the notification fd out of the filter context
and into the global task context, using a newly created task_state
structure.  This allows us to store, and retrieve the notification
outside the scope of an individual filter context.  It also provides
some implementation improvements by giving us a convenient place to
stash all of the API level related support variables.  We also extend
the seccomp_reset() API call to reset this internal global state when
passed a NULL filter context.

There is one potential case which we don't currently handle well:
threads.  At the moment libseccomp is thread ignorant, and that works
well as the only global state up to this point was the currently
supported API level information which was common to all threads in a
process.  Unfortunately, it appears that the notification fd need not
be common to all threads in a process, yet this patch treats it as if
it is common.  I suspect this is a very unusual use case so I decided
to keep this patch simple and ignore this case, but in the future if
we need to support this properly we should be able to do so without
API changes by keeping an internal list of notification fds indexed
by gettid(2).

This fixes the GitHub issue below:
* https://github.com/seccomp/libseccomp/issues/273

Reported-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Acked-by: Tom Hromatka <tom.hromatka@oracle.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
(imported from commit ce314fe4111887c593e3c6b17c60d93bc6ab66b9)

Gbp-Pq: Name all_only_request_the_userspace_notification_fd_once.patch

libseccomp (2.5.0-3) unstable; urgency=medium

  * Cherry-pick patch from the 2.5 branch to fix test error on mips:
    - arch_ensure_we_dont_munge_pseudo_syscall_numbers.patch

[dgit import unpatched libseccomp 2.5.0-3]

Import libseccomp_2.5.0-3.debian.tar.xz

[dgit import tarball libseccomp 2.5.0-3 libseccomp_2.5.0-3.debian.tar.xz]

Import libseccomp_2.5.0.orig.tar.gz

[dgit import orig libseccomp_2.5.0.orig.tar.gz]

Merge version 2.4.3-1+rpi1 and 2.4.4-1 to produce 2.4.4-1+rpi1

Merge libseccomp (2.4.4-1) import into refs/heads/workingbranch

[PATCH] arch: Add RISC-V 64-bit support

Signed-off-by: Andreas Schwab <schwab@suse.de>
[PM: minor macro shuffling in seccomp.h.in]
Signed-off-by: Paul Moore <paul@paul-moore.com>
Gbp-Pq: Name riscv64_support.patch

cython3

https://github.com/seccomp/libseccomp/pull/188

From 8d09eb9314ad00aa0584345ae66d4419b38da8e0 Mon Sep 17 00:00:00 2001
From: Paul Moore <paul@paul-moore.com>
Date: Wed, 13 Nov 2019 20:54:25 -0500
Subject: [PATCH] build: try to use explicitly marked Python 3.x tools first

Python 2.x is going EOL very soon, so let's require Python 3.x now
and attempt to use the explicitly marked Python 3.x tools first.

Signed-off-by: Paul Moore <paul@paul-moore.com>
Gbp-Pq: Name cython3.patch

libseccomp (2.4.4-1) unstable; urgency=medium

  * Team upload.

  [ Debian Janitor ]
  * Set upstream metadata fields: Repository, Repository-Browse.
  * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository.

  [ Felix Geyer ]
  * New upstream release.
  * Download and verify orig gpg signature.

[dgit import unpatched libseccomp 2.4.4-1]

Import libseccomp_2.4.4.orig.tar.gz

[dgit import orig libseccomp_2.4.4.orig.tar.gz]

Import libseccomp_2.4.4-1.debian.tar.xz

[dgit import tarball libseccomp 2.4.4-1 libseccomp_2.4.4-1.debian.tar.xz]

Merge version 2.4.2-2+rpi1 and 2.4.3-1 to produce 2.4.3-1+rpi1

Merge libseccomp (2.4.3-1) import into refs/heads/workingbranch

[PATCH] arch: Add RISC-V 64-bit support

Signed-off-by: Andreas Schwab <schwab@suse.de>
[PM: minor macro shuffling in seccomp.h.in]
Signed-off-by: Paul Moore <paul@paul-moore.com>
Gbp-Pq: Name riscv64_support.patch

cython3

https://github.com/seccomp/libseccomp/pull/188

From 8d09eb9314ad00aa0584345ae66d4419b38da8e0 Mon Sep 17 00:00:00 2001
From: Paul Moore <paul@paul-moore.com>
Date: Wed, 13 Nov 2019 20:54:25 -0500
Subject: [PATCH] build: try to use explicitly marked Python 3.x tools first

Python 2.x is going EOL very soon, so let's require Python 3.x now
and attempt to use the explicitly marked Python 3.x tools first.

Signed-off-by: Paul Moore <paul@paul-moore.com>
Gbp-Pq: Name cython3.patch

libseccomp (2.4.3-1) unstable; urgency=medium

  * New upstream release.
  * Drop patches that have been applied upstream:
    - tests-rely-on-__SNR_xxx-instead-of-__NR_xxx-for-sysc.patch
    - api_define__SNR_ppoll_again.patch
  * Cherry-pick support for the riscv64 architecture. (Closes: #952386)
    - Add riscv64_support.patch

[dgit import unpatched libseccomp 2.4.3-1]

Import libseccomp_2.4.3.orig.tar.gz

[dgit import orig libseccomp_2.4.3.orig.tar.gz]

Import libseccomp_2.4.3-1.debian.tar.xz

[dgit import tarball libseccomp 2.4.3-1 libseccomp_2.4.3-1.debian.tar.xz]

Merge version 2.4.1-2+rpi1 and 2.4.2-2 to produce 2.4.2-2+rpi1

Merge libseccomp (2.4.2-2) import into refs/heads/workingbranch

api_define__SNR_ppoll_again

From 2e54815cd843687d750cc9822f992389bb7b76cd Mon Sep 17 00:00:00 2001
From: Miroslav Lichvar <mlichvar@redhat.com>
Date: Wed, 13 Nov 2019 13:36:10 +0100
Subject: [PATCH] api: define __SNR_ppoll again

Commit bf747eb21e428c2b3ead6ebcca27951b681963a0 accidentally removed the
__SNR_ppoll definition. Add it back, using a PNR value if disabled in
the kernel headers.

Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
Gbp-Pq: Name api_define__SNR_ppoll_again.patch

cython3

From 8d09eb9314ad00aa0584345ae66d4419b38da8e0 Mon Sep 17 00:00:00 2001
From: Paul Moore <paul@paul-moore.com>
Date: Wed, 13 Nov 2019 20:54:25 -0500
Subject: [PATCH] build: try to use explicitly marked Python 3.x tools first

Python 2.x is going EOL very soon, so let's require Python 3.x now
and attempt to use the explicitly marked Python 3.x tools first.

Signed-off-by: Paul Moore <paul@paul-moore.com>
Gbp-Pq: Name cython3.patch

tests: rely on __SNR_xxx instead of __NR_xxx for syscalls

We recently changed how libseccomp handles syscall numbers that are
not defined natively, but we missed test #15.

Signed-off-by: Paul Moore <paul@paul-moore.com>
Note: Tagged for v2.5, but needed to build 2.4.2 with newer kernels on arm
This is part of PR: https://github.com/seccomp/libseccomp/pull/182
Upstream Bug: https://github.com/seccomp/libseccomp/issues/184
Origin: upstream, https://github.com/pcmoore/misc-libseccomp/commit/35803ceb43c453762a3ab5177c5f8d5dbb813478
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1849785
Last-Update: 2019-11-12

Gbp-Pq: Name tests-rely-on-__SNR_xxx-instead-of-__NR_xxx-for-sysc.patch

libseccomp (2.4.2-2) unstable; urgency=medium

  [ Christian Ehrhardt ]
  * d/rules: fix potential FTFBS after full python3 switch
  * d/t/control: drop python2 test following the removal of the package

  [ Felix Geyer ]
  * Remove build-dependency on valgrind for mips64el as it's broken there.
  * Backport patch to define __SNR_ppoll again.
    - Add api_define__SNR_ppoll_again.patch
  * Replace custom patch for cython3 with the upstream fix.

[dgit import unpatched libseccomp 2.4.2-2]

Import libseccomp_2.4.2-2.debian.tar.xz

[dgit import tarball libseccomp 2.4.2-2 libseccomp_2.4.2-2.debian.tar.xz]

Import libseccomp_2.4.2.orig.tar.gz

[dgit import orig libseccomp_2.4.2.orig.tar.gz]

Merge libseccomp (2.4.1-2+rpi1) import into refs/heads/workingbranch

python_install_dir

From 830929096665eab2b910d676ccab1df90908cb02 Mon Sep 17 00:00:00 2001
From: Felix Geyer <debfx@fobos.de>
Date: Mon, 15 Jul 2019 21:12:05 +0200
Subject: [PATCH] Install the python extension to the root package dir

Commit 8ad3638ea9023c3948976dfadebd1554380a31c9 effectively added libseccomp/
to the install path of the python extension.
This changed the import module name from "seccomp" to "libseccomp.seccomp",
breaking existing users.

Revert the install path like it was before 2.4.0

Signed-off-by: Felix Geyer <debfx@fobos.de>
Gbp-Pq: Name python_install_dir.patch

libseccomp (2.4.1-2+rpi1) bullseye-staging; urgency=medium

  * Move valigrind from build-depends to build-conflicts, raspbians valgrind
    is somewhat broken and causes testsuite failures.

[dgit import unpatched libseccomp 2.4.1-2+rpi1]

Import libseccomp_2.4.1-2+rpi1.debian.tar.xz

[dgit import tarball libseccomp 2.4.1-2+rpi1 libseccomp_2.4.1-2+rpi1.debian.tar.xz]

Merge libseccomp (2.4.1-2) import into refs/heads/workingbranch

python_install_dir

From 830929096665eab2b910d676ccab1df90908cb02 Mon Sep 17 00:00:00 2001
From: Felix Geyer <debfx@fobos.de>
Date: Mon, 15 Jul 2019 21:12:05 +0200
Subject: [PATCH] Install the python extension to the root package dir

Commit 8ad3638ea9023c3948976dfadebd1554380a31c9 effectively added libseccomp/
to the install path of the python extension.
This changed the import module name from "seccomp" to "libseccomp.seccomp",
breaking existing users.

Revert the install path like it was before 2.4.0

Signed-off-by: Felix Geyer <debfx@fobos.de>
Gbp-Pq: Name python_install_dir.patch

libseccomp (2.4.1-2) unstable; urgency=medium

  * Remove build-dependency on valgrind for mipsel and x32 as it's broken
    on those archs.
  * Set Rules-Requires-Root: no.

[dgit import unpatched libseccomp 2.4.1-2]

Import libseccomp_2.4.1-2.debian.tar.xz

[dgit import tarball libseccomp 2.4.1-2 libseccomp_2.4.1-2.debian.tar.xz]

Import libseccomp_2.4.1.orig.tar.gz

[dgit import orig libseccomp_2.4.1.orig.tar.gz]

Merge libseccomp (2.3.3-4) import into refs/heads/workingbranch

parisc_syscalls_linux415

Gbp-Pq: Name 31-parisc_syscalls_linux415.patch

parisc_syscalls_linux414

Gbp-Pq: Name 30-parisc_syscalls_linux414.patch

parisc_syscalls_linux49

Gbp-Pq: Name 29-parisc_syscalls_linux49.patch

arch: Add parisc architecture support

This patch (v4) adds support for the parisc and parisc64 architectures
to libseccomp.

I didn't split up the patch, because it's pretty trivial.
Those parisc-specific files gets added:
 src/arch-parisc-syscalls.c
 src/arch-parisc.c
 src/arch-parisc.h
 src/arch-parisc64.c

All other changes are trivial because they simply add parisc-specific
case statements in variouse switch statements.

I did ran a "make check" on x86-64 and parisc and all testcases succeeded.
All live testcases succeed as well when running "./regression -T live".

The patch applies cleanly to current libseccomp git head.

Changes between v4 and v3 of this patch:
- Added parisc arch to arch-syscall-check.c and fixup syscall table as
  needed
- Fixed copyright notices in parisc files as suggested by Mike Frysinger

Changes between v3 and v2 of this patch:
- Stripped out patch which reports if a check was skipped because
  valgrind isn't installed.
- Added tuxcall pseudo syscall for 19-sim-missing_syscalls testcase
- Added sysmips pseudo syscall for 29-sim-pseudo_syscall testcase

Changes between v2 and v1 of this patch:
- Enabled seccomp mode 2 regression tests on parisc. Kernel support for
  hppa was added in kernel 4.6-rc1 and backported into the kernel v4.5.2
  stable series.

Signed-off-by: Helge Deller <deller@gmx.de>
[PM: corrected a number or errors from 'make check-syntax']
Signed-off-by: Paul Moore <paul@paul-moore.com>
Gbp-Pq: Name 28-parisc_support.patch

libseccomp (2.3.3-4) unstable; urgency=medium

  [ Ondřej Nový ]
  * d/copyright: Change Format URL to correct one

  [ Helmut Grohne ]
  * Fix FTCBFS: (Closes: #903556)
    + Multiarchify python Build-Depends.
    + Annotate cython dependencies with :native for now.
    + Drop noop dh_auto_build invocations.
    + Pass a suitable PYTHONPATH for python2.
    + Pass _PYTHON_SYSCONFIGDATA_NAME for python3.

[dgit import unpatched libseccomp 2.3.3-4]

Import libseccomp_2.3.3-4.debian.tar.xz

[dgit import tarball libseccomp 2.3.3-4 libseccomp_2.3.3-4.debian.tar.xz]

Import libseccomp_2.3.3.orig.tar.gz

[dgit import orig libseccomp_2.3.3.orig.tar.gz]

build-ldflags

Gbp-Pq: Name build-ldflags.patch

manpage-typo

Gbp-Pq: Name manpage-typo.patch

pkgconfig-macro

Gbp-Pq: Name pkgconfig-macro.patch

libseccomp (2.1.1-1) unstable; urgency=low

  * New upstream release (Closes: 733293).
  * copyright: add a few missed people.
  * rules: adjusted for new test target.
  * libseccomp2.symbols: drop accidentally exported functions.
  * control:
    - bump standards, no changes needed.
    - add armel target

[dgit import unpatched libseccomp 2.1.1-1]

Import libseccomp_2.1.1.orig.tar.gz

[dgit import orig libseccomp_2.1.1.orig.tar.gz]

Import libseccomp_2.1.1-1.debian.tar.xz

[dgit import tarball libseccomp 2.1.1-1 libseccomp_2.1.1-1.debian.tar.xz]