Q: request of new minor release with an updated syscall table to support newer kernels

[shaba]

Can you please release new minor version with just the support of actual kernels?

[pcmoore]

Thoughts @drakenclimber?

It's been roughly a year since the last v2.5.x release and while I don't see any significant changes in the release-2.5 branch, and new release with an updated syscall table might be a good idea.

[drakenclimber]

Thoughts @drakenclimber?

It's been roughly a year since the last v2.5.x release and while I don't see any significant changes in the release-2.5 branch, and new release with an updated syscall table might be a good idea.

Yeah, I definitely support doing a new 2.5.x release. I have some obligations that will likely consume the next few weeks, but I should have time after that. Does June or July sound reasonable?

[pcmoore]

Next week I'm going to be spending some quality time stuck on planes/airports, I might be able to put a release together next week, but I don't want to step on your toes :)

I am doing two PRs to update the syscall tables on main and release-2.5, and it looks like we don't need to update main (no syscall changes between v6.2 and v6.3).

[drakenclimber]

Next week I'm going to be spending some quality time stuck on planes/airports, I might be able to put a release together next week, but I don't want to step on your toes :)

I am doing two PRs to update the syscall tables on main and release-2.5, and it looks like we don't need to update main (no syscall changes between v6.2 and v6.3).

If you have the time and the desire to release v2.5.5, I'm totally cool with that. I know you've been pretty busy lately, so I didn't want to burden you with more work.

[drakenclimber]

I should have time to help review/test the v2.5.5 release if you want a second set of eyes.

[pcmoore]

Actually, wait a minute ... looking at the syscall table changes between Linux v5.17 (what we shipped in the libseccomp v2.5.4 release) and Linux v6.3 I only see one change: memfd_secret() is defined for riscv64. Given the limitations of memfd_secret() I'm beginning to wonder if a new release is really worth it ... ?

@shaba what problems are you seeing with libseccomp v2.5.4 that you need a new release with updated kernel support?

[pcmoore]

Related PR to update the release-2.5 branch with the Linux v6.3 syscall information.:

• https://github.com/seccomp/libseccomp/pull/407

[shaba]

I didn't knew there was no significant syscall changes either. It's good to know release is not needed. We just wanted to have updated libseccomp for actual kernels.

For longarch support i can wait next major release.

[drakenclimber]

This summer I'll work on paring down the open issues for 2.6.0. We have a lot of cool features there that I would love to get released.

[pcmoore]

This summer I'll work on paring down the open issues for 2.6.0. We have a lot of cool features there that I would love to get released.

Yeah, I've been trying to carve out one day a week to work on libseccomp lately ... although most weeks I've been failing miserably at that :/

[pcmoore]

@shaba I'm going to go ahead and close this out as I think we've resolved your concern, but if I'm mistaken please feel free to re-open.

[drakenclimber]

Yeah, I've been trying to carve out one day a week to work on libseccomp lately ... although most weeks I've been failing miserably at that :/

Sounds all too familiar :)

[vt-alt]

There are three new syscalls since than already on v6.6-rc1 (cachestat (since 6.5), fchmodat2, and map_shadow_stack) can you add them with a minor release?

[pcmoore]

We are working on a minor release, although there is not set date yet so please don't ask ;)

[vt-alt]

Because it's impossible to add exact syscall that is present in kernel but not present in libseccomp (such as fchmodat2) it's impossible to create workarounds for adding syscalls (for example just ENOSYS them altogether) that are not yet supported by libseccomp.

Please make libseccomp synchronized with the current kernel version? Or allow adding unsupported syscalls?

[pcmoore]

Please make libseccomp synchronized with the current kernel version?

https://github.com/seccomp/libseccomp/issues/406#issuecomment-1723453655

Or allow adding unsupported syscalls?

See seccomp_add_rule_exact(), it should allow arbitrary syscall numbers; we use it all the time in the bundled regression tests.

[vt-alt]

See seccomp_add_rule_exact(), it should allow arbitrary syscall numbers; we use it all the time in the bundled regression tests.

Ah thanks. We misinterpreted -EFAULT when adding a rule (with seccomp_add_rule_exact) for non-native arch (for SCMP_ARCH_X86 on SCMP_ARCH_X86_64). For native arch it works good.

[keszybz]

glibc starting using fchmodat2 to implement fchmod with flags [1], so the lack of support for fchmodat2 in libseccomp is causing problems with programs sandboxed by systemd. In particular, tar now fails with the default SystemCallFilter="@system-service" sandbox [2]. We'd appreciate a quick release to support fchmodat2.

[1] https://github.com/bminor/glibc/commit/65341f7bbea824d2ff9d37db15d8be162df42bd3 [2] https://github.com/systemd/systemd/issues/30250

[pcmoore]

@drakenclimber see above. I'll send you an email this morning.

[keszybz]

https://github.com/systemd/systemd/pull/30291 makes systemd handle unknown (to itself or libseccomp) syscalls gracefully by returning ENOSYS. So the ask here is less urgent: things should work as before, but we need an updated libseccomp to allow users to specify fchmodat2 in filters and/or to use it from sandboxed services.

[drakenclimber]

Thanks, @keszybz. That looks like a good addition to systemd.

I'm going to start working on the 2.5.5 release right now. It's been long overdue.

[drakenclimber]

For those watching this issue - I have just released libseccomp v2.5.5. Thanks for all the help :+1: