RFE: Update syscalls.csv to kernel version v7.0-rc7 by drakenclimber · Pull Request #485 · seccomp/libseccomp

drakenclimber · 2026-04-14T21:21:36Z

In this patchset:

Update syscalls.csv to the latest kernel version, v7.0-rc7
Document the process to update syscalls.csv
Various minor improvements to the tools to build syscalls.csv
Remove 32-bit s390 since it's no longer supported

For the libseccomp v2.6.x releases, I think we won't want to backport the s390-removal patch.

Here's a comparison of the HEAD syscalls.csv (with the s390 columns removed) and the proposed syscalls.csv.
https://www.textcompare.org/csv/?id=69dead128329b015e57a0320

Add enumerations for kernels 6.18, 6.19, and 7.0 Signed-off-by: Tom Hromatka (Oracle) <tom.hromatka@gmail.com>

A few minor improvements to the script that builds the kernel version tables: * Improve the copy logic from the syscalls-table tool so that the the syscall tables are copied directly to target directory and not to a child directory * Convert relative paths to absolute path. The syscalls-table tool does not support relative paths * Add the latest kernel version numbers to the built-in list. (This isn't strictly required as the tool can handle arbitrary input from the user, but it's an easy update while we're already modifying the script.) Signed-off-by: Tom Hromatka (Oracle) <tom.hromatka@gmail.com>

A few minor improvements to the script that updates the syscalls.csv file: * Remove file_getattr() and file_setattr() from the ignored syscalls list * Properly initialize a new row (when a syscall is added) with PNR,SCMP_KV_UNDEF,... rather than PNR,PNR,... * Add support for release candidate kernels * Convert relative paths to absolute paths Signed-off-by: Tom Hromatka (Oracle) <tom.hromatka@gmail.com>

drakenclimber · 2026-04-14T21:23:44Z

Fixes: #480

drakenclimber · 2026-04-15T14:14:37Z

~~Before we merge this patchset, we should probably also add this patch that sets the kernel versions for all existing syscalls.~~

~~031024a~~

~~I'll add it to this patchset.~~

Changed my mind. See the comment below

Signed-off-by: Tom Hromatka (Oracle) <tom.hromatka@gmail.com>

Add documentation on how to update syscalls.csv. NOTE - since we haven't fully converted syscalls.csv over to containing valid kernel version numbers, I have intentionally set all kernel version fields to SCMP_KV_UNDEF. We'll update the kernel versions in pull request seccomp#457. Here are the exact steps and results for updating syscalls.csv to kernels v6.14 through v7.0-rc7 $ apt install libc6-dev-x32 $ git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git $ git clone https://github.com/hrw/syscalls-table.git $ git clone git@github.com:<yourrepo>/libseccomp.git $ cd libseccomp $ vim include/seccomp-kvers.h --> add new syscall enumerations $ time ./src/arch-build-kver-tables.py -d ../syscalls-table -k ../linux -V 6.14,6.15,6.16,6.17,6.18,6.19,7.0-rc7 Building version table for kernel 6.14 Building version table for kernel 6.15 Building version table for kernel 6.16 Building version table for kernel 6.17 Building version table for kernel 6.18 Building version table for kernel 6.19 Building version table for kernel 7.0-rc7 real 2m47.672s user 1m22.094s sys 1m23.954s $ time ./src/arch-update-syscalls-csv.py -a -d ./ -k ../linux -c src/syscalls.csv -V 6.14,6.15,6.16,6.17,6.18,6.19,7.0-rc7 Updating src/syscalls.csv version table for kernel 6.14 Updating src/syscalls.csv version table for kernel 6.15 Updating src/syscalls.csv version table for kernel 6.16 Updating src/syscalls.csv version table for kernel 6.17 Updating src/syscalls.csv version table for kernel 6.18 Updating src/syscalls.csv version table for kernel 6.19 Updating src/syscalls.csv version table for kernel 7.0-rc7 real 0m30.112s user 0m20.716s sys 0m9.547s $ vim include-seccomp-syscalls.h --> add new syscall __SNR and __PNR entries as appropriate $ ./src/arch-syscall-check --> Make changes as recommended by this script --> Re-run this script until there are no more changes to be made $ cd src $ ./arch-syscall-validate -c syscalls-prev.csv ../../linux/ $ git diff HEAD syscalls.csv $ diff syscalls-prev.csv with syscalls.csv Signed-off-by: Tom Hromatka (Oracle) <tom.hromatka@gmail.com>

drakenclimber · 2026-04-16T21:10:00Z

v2 changes:

Removed the patch that removes s390. To minimize changes between the main and the release-2.6 branches, let's merge that patch after cutting release v2.6.1. I'll add the s390 patch to pull request RFE: Add support for maximum supported kernel version #457.
Because S390 remains in this patchset, I had to add a couple more __PNR definitions

pcmoore · 2026-04-17T22:18:21Z

 #define __PNR_riscv_hwprobe			-10250
 #define __PNR_uretprobe				-10251
+#define __PNR_uprobe				-10252
+#define __PNR_rseq_slice_yield			-10253


Based on the macros below it looks like __PNR_rseq_slice_yield isn't necessary as __NR_rseq_slice_yield is defined for all arches/ABIs?

32-bit s390 isn't getting updates, so it needs __PNR_rseq_slice_yield

pcmoore · 2026-04-17T22:19:27Z

 #define __PNR_uretprobe				-10251
+#define __PNR_uprobe				-10252
+#define __PNR_rseq_slice_yield			-10253
+#define __PNR_listns				-10254


Same here, it looks like __NR_listns is defined for all arches/ABIs? If not, we need to so the __SNR to __NR or __PNR macro dance down below.

Same comment as above. 32-bit s390 needs it.

This is one reason I was tempted to ditch s390 now.

The other reason is that syscalls table tool has generated some different syscall numbers from libseccomp's arch-syscall-validate for 32-bit s390. This made me nervous

pcmoore · 2026-04-17T22:45:35Z

+   apt install libc6-dev-x32
+   ```
+
+1. Download source packages


All of the list items are numbered "1." :)

This is intentional. Github's Markdown parser converts them into correct numbers when rendered.

https://github.com/drakenclimber/libseccomp/blob/v7.0-rc7/CONTRIBUTING.md#how-to-update-the-syscallscsv-table

With that said, if we think people are going to read the markdown file directly in vim/emacs/whatever, I can properly number the list.

pcmoore · 2026-04-17T22:47:28Z


+## How to Update the syscalls.csv Table
+
+*** NOTE - This currently can only be done on Ubuntu ***


Is this just because of the package dependencies in step 1? If so, perhaps we add unordered sub-list there for various distros, e.g. Fedora/RHEL, Arch, etc.

I had troubles generating the correct syscall numbers for x32 on non-Ubuntu distros. I tried installing various 32-bit packages, but I couldn't get it to work.

@hrw - can you successfully generate x32 syscalls on Red Hat, Fedora, Oracle Linux, etc.?

My AArch64 system runs Fedora 44. Regenerated x32 tables just fine.

Glad to hear that. Do you know what 32-bit package(s) you installed? I wasn't able to find the right ones, and as I pointed out, my x32 syscalls were wrong. Thanks!

$ rpm -qa|grep glibc glibc-2.43-3.fc44.aarch64 glibc-common-2.43-3.fc44.aarch64 glibc-gconv-extra-2.43-3.fc44.aarch64 glibc-all-langpacks-2.43-3.fc44.aarch64 glibc-devel-2.43-3.fc44.aarch64 glibc-static-2.43-3.fc44.aarch64

That's all I have installed.

Hmmm... My Fedora41 x86 box behaves quite a bit differently.

❯ cat /etc/fedora-release Fedora release 41 (Forty One) ❯ rpm -qa|grep glibc glibc-common-2.40-28.fc41.x86_64 glibc-all-langpacks-2.40-28.fc41.x86_64 glibc-gconv-extra-2.40-28.fc41.x86_64 glibc-2.40-28.fc41.x86_64 glibc-devel-2.40-28.fc41.x86_64 glibc-static-2.40-28.fc41.x86_64

When I run scripts/update-tables.sh ... on my Fedora box, a lot of the x32 syscalls get (erroneously?) populated with version numbers. For example, lstat64 becomes syscall 196.

Here's a comparison of building the tables on my Ubuntu24 vs my Fedora41 machine.

https://www.textcompare.org/csv/?id=69f0fe048329b015e57a1c02

I created a pull request in the syscalls-table repo. Let's hold off on merging this patchset until we get that question/issue resolved.

hrw/syscalls-table#138

Thanks for the quick review and merging my pull request, @hrw. This pull request is unblocked now.

pcmoore · 2026-04-17T22:51:45Z

v2 changes:

Removed the patch that removes s390. To minimize changes between the main and the release-2.6 branches, let's merge that patch after cutting release v2.6.1. I'll add the s390 patch to pull request RFE: Add support for maximum supported kernel version #457.

Because S390 remains in this patchset, I had to add a couple more __PNR definitions

I think we need to keep S390 around for a few more years since it was only just removed in Linux v6.19. I'll add a GH issue so we don't forget about it, but I suspect we may even want to keep it around for the v2.7.z stream too.

The good news is that from our perspective it's just a matter of PNR'ing any new syscall that comes along for S390.

drakenclimber added 3 commits April 13, 2026 07:59

syscalls: Add enumerations for kernels 6.18, 6.19, and 7.0

9e2dcd2

Add enumerations for kernels 6.18, 6.19, and 7.0 Signed-off-by: Tom Hromatka (Oracle) <tom.hromatka@gmail.com>

drakenclimber added this to the v2.7.0 milestone Apr 14, 2026

drakenclimber requested a review from pcmoore April 14, 2026 21:21

drakenclimber self-assigned this Apr 14, 2026

drakenclimber added the enhancement label Apr 14, 2026

drakenclimber mentioned this pull request Apr 14, 2026

BUG: guidance needed on how to update syscalls.csv #480

Open

drakenclimber added 2 commits April 16, 2026 15:05

syscalls: Update syscalls for kernels v6.14 through v7.0-rc7

a6b1840

Signed-off-by: Tom Hromatka (Oracle) <tom.hromatka@gmail.com>

drakenclimber force-pushed the v7.0-rc7 branch from 2ede8f2 to 3091542 Compare April 16, 2026 21:07

pcmoore reviewed Apr 17, 2026

View reviewed changes


		## How to Update the syscalls.csv Table

		* NOTE - This currently can only be done on Ubuntu *

Conversation

drakenclimber commented Apr 14, 2026

Uh oh!

drakenclimber commented Apr 14, 2026

Uh oh!

drakenclimber commented Apr 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

drakenclimber commented Apr 16, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

drakenclimber Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pcmoore commented Apr 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

drakenclimber commented Apr 15, 2026 •

edited

Loading

drakenclimber Apr 24, 2026 •

edited

Loading