[HN Gopher] A Linux kernel syscall implementation tracker
___________________________________________________________________
A Linux kernel syscall implementation tracker
Author : halb
Score : 161 points
Date : 2024-07-20 17:34 UTC (5 hours ago)
(HTM) web link (syscalls.mebeim.net)
(TXT) w3m dump (syscalls.mebeim.net)
| Neywiny wrote:
| This is good. Usually I end up finding one I think Google made
| for Chromebooks. Or even worse, restoring to the man page.
| Retr0id wrote:
| Where can I find syscall numbers in the man pages?
| chad1n wrote:
| You can't since man pages present the libc implementation,
| that's more useful if you work with syscalls that use
| structures since it shows you what to search for in libc to
| copy it in other language.
| thayne wrote:
| > man pages present the libc implementation
|
| No, the section 3 man pages for "syscalls" are the libc
| wrapper functions. But section 2 is the syscalls
| themselves, and includes man pages for syscalls that don't
| have wrapper functions.
|
| I don't think those man pages include the numbers though,
| since those numbers are architecture dependent.
| mebeim wrote:
| Not really. Even though section 2 should be for
| "syscalls", it is really only for libc syscall wrappers.
| Very few pages in the section 2 document the _raw_
| syscalls, and those that do say it specifically at the
| beginning. OTOH, in section 3 you won 't find any syscall
| at all (wrapper or not).
| Neywiny wrote:
| Man syscall and man syscalls. I'm on Mobile and remoted into
| my wsl to find neither list the actual table at first blush,
| but I have seen it. It's probably in one of the related
| pages. This is why I like the site though. It's all just
| there.
| tanelpoder wrote:
| The question was about syscall _numbers_. The man pages don
| 't show the numbers.
|
| The internal syscall numbers are defined in syscall_64.tbl
| in kernel source and you can parse the (libc-used) syscall
| numbers from various /usr/include/asm/syscall.h files, but
| these files don't necessarily contain all the available
| syscalls in _your_ currently running kernel.
|
| You can read your kernel's/platform's currently available
| syscalls from the relevant /sys/kernel/debug/tracing
| tracepoint files (I posted a link to my script in another
| comment here). That way you'll see all currently available
| system calls and their arguments, but tracefs doesn't show
| the syscall internal numbers (syscall table slot numbers),
| but rather the new syscall ID.
|
| The internal syscall numbering can change when you
| switch/build a new kernel and syscalls have different
| numbers across platforms. Syscall 0 is "read" on x86_64,
| but is "io_setup" on aarch64, for example. The new syscall
| ID aims to provide stable numbering with no conflicts and
| overlaps across platforms and kernel versions, as I
| understand.
| mebeim wrote:
| Fun fact, some weird syscalls don't even appear under
| /sys/kernel/debug/tracing because they lack ftrace
| metadata. It was pretty fun (read: a nightmare) to deal
| with some of those in my tool. You can grep -R -F "NOT
| found in ftrace metadata" in the logs in my db
| (https://github.com/mebeim/linux-syscalls/tree/master/db)
| to see which ones.
|
| The most interesting one, which doesn't even appear in my
| logs because I had to hardcode it since its esoteric
| definition, is fast_endian_switch for PPC64 (https://elix
| ir.bootlin.com/linux/v6.10/source/arch/powerpc/k...).
| tanelpoder wrote:
| Good to know, I suspected that this might be the case,
| but never got to confirm this. I guess one could set up a
| test comparing the syscalls listed in syscall_64.tbl (or
| syscall table read from kernel memory) with the syscalls
| listed under /sys/kernel/debug/tracing/events/syscalls
| mebeim wrote:
| Nope, not even that, because believe it or not, sometimes
| not even the .tbl files have all of them :'). In fact,
| the only arch where IMHO syscalls make sense and are
| organized in a sane way is arm64 that doesn't even have a
| .tbl file. And not even the table in kernel memory is
| enough sometimes! Some are special handlers in syscall
| entry code (like the one I mentioned above). It's just a
| mess, hence why I sort of gave up at some point and for
| some "esoteric" syscall I just hardcode them.
| wg0 wrote:
| What API is the most common for x86-64bit?
| Retr0id wrote:
| The x86-64 ABI is the most common x86-64 ABI ;)
|
| (x32 is rare https://en.wikipedia.org/wiki/X32_ABI )
| mebeim wrote:
| 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).
| qbane wrote:
| I wish this site could have existed earlier when I was writing
| eBPF filters for my sandbox and had to check how specific
| syscalls were implemented in different archs here and there.
| Thanks for your great work.
| tanelpoder wrote:
| 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).
| netr0ute wrote:
| Missing RISC-V
| stevefolta wrote:
| Yeah, it seems odd that it has PowerPC but not RISC-V.
| mfranc42 wrote:
| I'm missing s390x.
| mebeim wrote:
| That's the next arch I want to add but it takes a bit of work,
| sooner or later I will add it though :')
| foresto wrote:
| That's handy.
|
| I wonder why it displays without javascript in chromium, but
| fails to do so in firefox. If the author is here, could that be
| fixed?
|
| Edit:
|
| Restarting chromium and trying again yields the same behavior as
| firefox. I wonder if the javascript somehow 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?
|
| Testing again several more times, that does seem likely. I can
| reproduce it intermittently by dragging the URL onto my chromium
| shortcut if chromium isn't already running.
|
| Edit 2: Sure enough:
|
| https://github.com/gorhill/uBlock/issues/1913
|
| https://github.com/gorhill/uBlock/issues/1327
| drtgh wrote:
| 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.
| mebeim wrote:
| I'm the author and I can confirm. The website will not work
| with JS disabled simply because it's a static HTML "skeleton"
| page loading JSON tables with JS and populating a <table>
| element. If it's working then it means you must have JS
| enabled. I don't plan to add support for browsers without JS,
| but the JSON tables have all the information you need anyway,
| and those are just static files (e.g.
| https://syscalls.mebeim.net/db/x86/64/x64/latest/table.json).
| o11c wrote:
| 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.
| rasz wrote:
| >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.
| saagarjha wrote:
| This is neat! Finally someone who added all the information I
| need :)
| jeffrallen wrote:
| From this I learned about Landlock, thanks!
| pastapoggers wrote:
| similarly, does a Windows syscall tracker exist?
| Retr0id wrote:
| https://github.com/j00ru/windows-syscalls
| MBCook wrote:
| Is there a reason syscall numbers don't match up between
| architectures?
|
| Or is it just a quirk of history?
| jmgao wrote:
| 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.
___________________________________________________________________
(page generated 2024-07-20 23:00 UTC)