List of projects which system calls table helped

[hrw]

I know that my system calls table helped some projects. Know few names but would love to see is it still in use (no worry, will maintain it).

So if table helped you in some project then please comment with it's name.

[keszybz]

systemd: I use this table regularly when updating https://github.com/systemd/systemd/blob/master/src/basic/missing_syscall.h.

[hrw]

@keszybz do you use tables/syscalls-* files directly or other way?

[keszybz]

I copied stuff by hand from the html page. But this might change. We are discussing importing a table of syscall numbers into our sources (see https://github.com/systemd/systemd/pull/16739#issuecomment-674872528). I wonder what the best way to do this would be... I think pulling in the tables/* files from here once per release would be a good way. We do something similar with other sources, like pciids, and it works out nicely.

[hrw]

One solution is grabbing data from my project, other (probably more sane long term) would be using in-kernel files.

Kernel moved to keep syscall numbers in parseable files few releases ago. I use them to check for new system call names.

[spoutn1k]

The project helped expanding architecture support for the python-ptrace module. Thanks for your work !

[0ffffffffh]

I use this table to supply syscall nums to my fuzzer project (it's heavly under the development at this time, I will edit here when I release it). For example i used it mmap syscall for i386, amd64, arm and aarch64 to reserve some memory on the target process by injecting native system call gadget. Thanks for this cool job.

[willfindlay]

I created a simple Rust library to wrap your tables/syscalls-* files. The source is available here: https://github.com/willfindlay/sysnames-rs

[hrw]

My "system-calls" Python module uses same data.

More about it in my blog post: Python package for system calls information

[Maylo99]

Hello, I am working on my seminar work to school, its great table very helpfull... It is a pity that it is not possible to go back to the old versions like v3.19.8, that would help me

[hrw]

@Maylo99 grab code, checkout old kernel version and run against it.

The part collecting system call names would fail but the one checking for presence should work.

If it does not then ping me.

[Maylo99]

@hrw unfortunately i have no idea how to do this... If that didn't take a long time, would you please send me a table from version 3.19.8? I would be very grateful to you

[hrw]

1. git clone this repo
2. cd syscalls-table
3. unpack Linux source
4. make KERNELSRC=PATH-TO-LINUX-SOURCE

And then you get system call tables for used Linux version.

Some syscall names may be missing as code for searching for them can go wrong and architectures already removed from kernel appear again and can be done wrong.

[Maylo99]

Thank you it works, I will definitely mention you and your program in my seminar work...

[Maylo99]

@hrw one more question when a system call has a big number in that table such as 9437324, is it generating error or how is it represented there? And other numbers are system call ID number?

[hrw]

Table shows proper values for each architecture.

Please open new issues for such questions next time.

[FedeDP]

Hi! We, in the falcosecurity org, are using this repo to automatically bump supported syscalls monthly, through a simple go script. We directly use tables/syscalls-$arch from this repo.

Thank you very much for this repo and for your effort! :pray:

[eliminmax]

I'm a college student studying computer networking and cybersecurity, and I'm working on a project in which I create minimal executables for different architectures that simply call the write and exit syscalls, and print the escape sequence ␛[H␛[J␛[3J, to clear the terminal and scrollback buffer. This is part of a larger exploration of the ELF file format's structure. This project and its associated python program have been incredibly helpful in both making the ARM executables and in writing the documentation.

I've uploaded the binaries to a personal download site, as well as the GitHub repository eliminmax/tiny-clear-elf. I use the same name for the architectures as the Debian project, and aim to make such executables for every architecture officially supported by Debian Bullseye. So far, I've made amd64 (161 bytes), i386 (125 bytes), armel/armhf (130 bytes), and arm64 (166 bytes).

I anticipate that this will continue to be immensely helpful as I move on to mipsel, mips64el, ppc64el, and s390x.

Thank you so much for making this - I know my use case is niche, but it's still incredibly helpful not to need to go hunting for the right header file for the right architecture constantly while working on it.

[hrw]

@eliminmax #include <asm/unistd.h> and use __NR_write and __NR_exit - this way you do not need to check for values.

[eliminmax]

Thanks for the feedback on my project. While could work if I was working in C, I'm creating the binary directly, byte by byte, in a minimalistic hex editor, partly for the esoteric challenge of it, and partly to learn about the basics of different CPU architectures and the ELF file format.

[hrw]

OK, I thought that you use assembly ;D