GNU/Systemd is pretty hilarious

This is a thing of beauty. I used to make spreadsheets like this ages ago when I was working across Linux and Solaris, but they were nowhere near as thorough as this.

I am curious what the difference is supposed to be between "XNU's Not UNIX!" and "MacOS (Arm64)".

<3

Do you mean arguments and the internal syscall number used for a syscall on your given platform?

I recently had enough of parsing the various syscall.h files on different architectures and wrote a debugfs syscall info reader instead. That way you can see all tracepoint-instrumented syscalls and arguments available exactly on your currently running kernel on your platform:

https://tanelpoder.com/posts/list-linux-system-call-argument...

Edit: changed "all" to "all tracepoint-instrumented" based on a comment below - some added syscalls don't (immediately) get instrumented with a tracepoint so tracefs wouldn't show them (until someone instruments them in a later kernel version as seems to be the case). The tracefs approach has been good enough for me, but the only 100% guaranteed way to see all currently available syscalls would be to read the syscall table from kernel memory and see which syscall handler kernel functions they call (as the syscall name itself is meaningless inside the kernel).

Thank you very much :). I am using static analysis of kernel images (vmlinux ELF) that are built with debug information. Each table you see was extracted from a kernel built by my tool, Systrack, that can configure and build kernels that have all the syscalls available. The code is heavily commented and available on GitHub if you are interested: https://github.com/mebeim/systrack

I realized soon in the process that simply looking at kernel sources was not enough to extract everything accurately, specially definition locations. I also wanted this to be a tool to extract syscalls actually implemented from a given kernel image, so that's what it does.

Your approach should be fine, that is what any other language does basically: rely on uapi headers provided by the kernel (just beware that some may be generated at build time inside e.g. include/asm/generated/xxx). You should rely on the headers that are exported when you do `make headers_install`. Also, make sure to have a generic syscall() function that takes an arbitrary syscall number and an arbitrary amount of args to make raw syscalls for the weird ones you don't easily find in uapi headers and you should be good. After all, even in the C library headers some of the "weird" syscalls aren't present sometimes.

Where can I find syscall numbers in the man pages?

I'm pretty sure it is because when Linus ported Linux from x86 to the DEC Alpha in the early 90s, he used the DEC OSF/1 syscall numbers (and error numbers) so that he could bootstrap the Linux kernel from an OSF/1 userland. He probably should have had a flag day & normalized the syscall numbers to be arch independent like they are on *BSD, but he never did.

Coming from BSD, I find this very confusing and tend to grumble when I'm tracing something and have to go groveling from the right errno.h. Eg:

% find ~/linux/ -name 'errno*' | wc -l

      22

% find ~/freebsd/sys -name 'errno*' | wc -l

       1

They were renumbered in x86_64 so that the syscalls that are frequently used together have their function pointers live in the same cacheline in the lookup table: https://lkml.iu.edu/hypermail/linux/kernel/0104.0/0547.html

I vaguely remember reading somewhere that the MIPS ones are weird to support compatibility with the existing unix syscall numbering, but I can't find any evidence for that anywhere, so maybe it was aspirational or I'm hallucinating.

That's the next arch I want to add but it takes a bit of work, sooner or later I will add it though :')

I'm missing s390x.

Yeah, it seems odd that it has PowerPC but not RISC-V.

It's 462

That is just a simple `grep -R EXPORT_SYMBOL` or `grep -R EXPORT_SYMBOL_GPL`, isn't it? A table for that wouldn't have much value.

Why would you care about that?

The x86-64 ABI is the most common x86-64 ABI ;)

(x32 is rare https://en.wikipedia.org/wiki/X32_ABI )

The homepage loads exactly the most common x86-64 ABI, which is x64 (according to kernel naming). It's the one for 64-bit syscalls made by 64-bit code. On x86-64 you also have IA32 (32-bit syscalls made by 32-bit code) and x32 (64-bit syscalls made by 64-bit code specifically built to only use 32-bit pointers).

The linked source seems to be checking (len_in && !len).

len_in being the passed argument and len being the page aligned len.

I'm not the author.

The html sourcecode shows the content of the table is not served within the page, but is added on page load through javascript by formatting a json requested file. I changed the browser's user-agent to chrome and the same page was served (though the link to git shows it's an static page). My guess is may be chromium is not disabling javascript.

PS: I'm a Firefox user too, I always browse with Javascript disabled by uMatrix (in addition to uBlockOrigin), I only enable it when the web deserves it and leaving disabled third domains js loads almost always.

>slipped past umatrix & ublock origin on my first try. Given that I launched chromium by dragging the link onto its icon the first time, perhaps the script-blocking extensions weren't fully loaded?

Yes. Chrome will actually pause extensions loading to deliver you that first rendered picture fraction(arguable, probably slower in the end considering extensions load from disk) of a second faster. I think it was direct uBO sabotage.

TLDR: First website loaded by starting browser with a link or from last session has almost 100% chance of bypassing uBlockOrigin. Chrome and Chromium based browsers are not User Agents, they are Google Agents.

Chrome breaks security addons by design, in the name of "performance". It's purely a coincidence that Chrome is made by a major ad company.