BUG: test 29 is broken on aarch64 about libseccomp HOT 6 OPEN

I think I have an aarch64 box; I'll hack around with it this morning and see if I can uncover anything

from libseccomp.

Unless we can resolve this rather quickly, I think we may need to revert commit 1852fe3 in the release-2.5 branch simply so the various packagers don't see a bunch of test failures when preparing distro packages from a release branch.

Thoughts @drakenclimber?

from libseccomp.

Test 29 seems to have been problematic from its inception. I went back to the commit 51c46f8 that initially added it, and the PFC looks to be incorrect from day 1.

$ ./tests/29-sim-pseudo_syscall
#
# pseudo filter code start
#
# filter for arch x86 (1073741827)
if ($arch == 1073741827)
  # default action
  action ALLOW;
# invalid architecture action
action KILL;
#
# pseudo filter code end
#

Stating the obvious here - these rule lines have never been added to the filter in any incarnation of libseccomp:

	rc = seccomp_rule_add(ctx, SCMP_ACT_KILL, SCMP_SYS(sysmips), 0);
	if (rc < 0)
		goto out;
	rc = seccomp_rule_add_exact(ctx, SCMP_ACT_KILL, SCMP_SYS(sysmips), 0);
	if (rc == 0)
		goto out;
	/* -10001 == 4294957295 (unsigned) */
	rc = seccomp_rule_add_exact(ctx, SCMP_ACT_KILL, -11001, 0);
	if (rc == 0)
		goto out;

Commit 1852fe3 broke the PFC generation and resulted in no PFC being generated at all. I did a little hacking, and it looks like the lookup of -10001 in the gperf code mapped to arch_prctl() (syscall 384 on x86). When the test was using -11001, it was translated to sysmips() which is a PNR on x86.

from libseccomp.

Based on the above findings, I think the safest and most prudent solution is:

• Revert commit 1852fe3 in the release-2.5 branch
• Use this issue to track the underlying problem with test 29
• Adopt @pcmoore's pull request #407 to update the syscall table
• Release v2.5.5

from libseccomp.

Reverted in the release-2.5 branch in commit 970c2b4. Since the test has been effectively broken since its inception, I've changed the milestone on this to v2.6.0. There seems to be significant issues with the test, and I doubt we will cherry-pick then into the release-2.5 branch

from libseccomp.

On LoongArch 64-bit the same failures happen too.

from libseccomp.