7 ms·

Searchable Linux Syscall Table for x86 and x86_64

88 points by ingve 4y ago

MuffinFlavored 4y ago
what would it take to implement user mode linux (where syscalls are... stubbed from what I can tell? no... that's not right. where hardware is virtualized/mocked? i don't know the right terminology) for something like Mac OS X (arm64/aarch64) so that Mac users could benefit from "containerization" in a hipster way
- pcwalton 4y ago
  The Linux kernel API is so complex, and so ill-specified, that the only practical way that would maintain userspace compatibility would be to run the Linux kernel itself under macOS. (Microsoft tried to implement the Linux API in NT with WSL 1 and they abandoned that approach in WSL 2 because, among other reasons, it was just too much work to achieve Linux compatibility.) Running the Linux kernel under macOS can be done with Apple's hypervisor framework.
  - twoodfin 4y ago
    Isn't this what the Illumos folks did (tried to do?) with LX-branded zones?
  - MuffinFlavored 4y ago
    > would be to run the Linux kernel itself under macOS. is that not "user mode linux"?
    - simcop2387 4y ago
      Not quite, UML is the linux kernel ported to be an executable that runs under Linux. It's design kind of requires the system calls from Linux to be able to run properly. Making a translation layer for that isn't impossible but it would add more overhead to running things that way. Running a VM in a hypervisor, you're instead creating a whole virtual computer and its IO interfaces instead of at the system call level. Because there's hardware support for doing that virtualization (basically the CPU can help isolate the new process so that it can't see real hardware and the hypervisor gets notified/pulled in when needed to emulate the IO) it can end up nearly native speed if setup correctly.
      - MuffinFlavored 4y ago
        > Not quite, UML is the linux kernel ported to be an executable that runs under Linux. It's design kind of requires the system calls from Linux to be able to run properly. How large of an effort would it be to make it work on Mac? Monstrous? Not that bad? 100 hours? 1000 hours? For what payoff?
        saagarjha 4y ago
        Several dozen to several hundred hours?
  - simcop2387 4y ago
    I believe this is actually one of the ways that Docker actually implements things for their MacOS support, so it's already done for containerization type stuff. Though I don't believe that docker gives you any real access to the "host" that is sets up for doing this. https://docs.docker.com/desktop/faqs/macfaqs/ https://docs.docker.com/desktop/faqs/macfaqs/
  - mirashii 4y ago
    > they abandoned that approach in WSL 2 because, among other reasons, it was just too much work to achieve Linux compatibility Any particular citation for this claim? I tried to do some searching and couldn't find anything definitive, but my memory from contemporaneous conversations and articles suggests that the primary reason was really performance, since the differences in how filesystem access in particular work between Windows/Linux were such that some of the I/O bottlenecks were deemed too difficult to impossible to address. Certainly WSL2 has higher compatibility, but I'm not sure that compatibility and not performance was the primary driver, and would love a source if you have one. Relatedly, it's worth noting that a number of other platforms have developed and shipped syscall translation layers for Linux binaries, including FreeBSD and SmartOS/illumos.
    - FatalException 4y ago
      The WSL2 architecture video lists two motivators from WSL1 based on number of Github issues. One of them being file performance and the other syscall compatibility with some specific examples being the ptrace syscall and Docker compatibilty. https://youtu.be/lwhMThePdIo?t=755 https://youtu.be/lwhMThePdIo?t=755 The HN submission for the youtube video also has discussion about the same topics. https://news.ycombinator.com/item?id=19868282 https://news.ycombinator.com/item?id=19868282
    - NGRhodes 4y ago
      https://devblogs.microsoft.com/commandline/announcing-wsl-2/ https://devblogs.microsoft.com/commandline/announcing-wsl-2/ > Our top requests from the WSL community have been to increase the file system performance, and make more apps work inside of WSL (i.e: introduce better system call compatibility). We have heard your feedback, and are glad to announce that WSL 2 helps solve these issues. > In WSL 1 we created a translation layer that interprets many of these system calls and allows them to work on the Windows NT kernel. However, it’s challenging to implement all of these system calls, resulting in some apps being unable to run in WSL 1. Now that WSL 2 includes its own Linux kernel it has full system call compatibility.
  - circuit10 4y ago
    The iSH app on iOS does this I think and it mostly works
  - yencabulator 4y ago
    > that the only practical way that would maintain userspace compatibility would be to run the Linux kernel itself Meanwhile, Google Container Engine uses gVisor, where the syscalls are implemented by some Go libraries with a very narrow seccomp interface to the actual host.
- matheusmoreira 4y ago
  QEMU has this feature. It can run Linux programs by translating their system calls. https://www.qemu.org/docs/master/user/main.html https://www.qemu.org/docs/master/user/main.html
  - MuffinFlavored 4y ago
    How is performance?
- simcop2387 4y ago
  You probably want to take a look at gVisor[1], there's some desire for it to work on other systems like macos[2]. It doesn't have a working solution there yet but it's probably the easiest way to make something like Microsoft's WSL1 which handled things that way. You'll get a lot of the boiler plate out of the way that you'd need to pretend to be a Linux system, and just have to implement the translations to MacOS calls through some kind of library. From the looks of the github thread it seems the main issue to doing it is cgroup support since there isn't anything similar to it on the other side. [1] https://en.wikipedia.org/wiki/GVisor https://en.wikipedia.org/wiki/GVisor [2] https://github.com/google/gvisor/issues/1270 https://github.com/google/gvisor/issues/1270
- jcranmer 4y ago
  FreeBSD has a syscall compatibility layer for Linux: https://wiki.freebsd.org/Linuxulator https://wiki.freebsd.org/Linuxulator. As noted by other people, Windows used to have such a compatibility layer as well, but they've moved away from it newer versions.
- saagarjha 4y ago
  https://github.com/ish-app/ish/blob/master/kernel/calls.c https://github.com/ish-app/ish/blob/master/kernel/calls.c
- dundarious 4y ago
  I've never used it, but https://github.com/jart/blink https://github.com/jart/blink is pretty much that. It's tiny and: > We regularly test that Blink is able run x86-64-linux binaries on the following platforms: > Linux (x86, ARM, RISC-V, MIPS, PowerPC, s390x) > macOS (x86, ARM) > FreeBSD > OpenBSD > Cygwin From what I gather, it's in the "excellent but incomplete" stage. It's new enough.
matheusmoreira 4y ago
I've used this list many times, thanks. The header file with the definitions that get exported to user space is here: https://github.com/torvalds/linux/blob/master/include/uapi/asm-generic/unistd.h https://github.com/torvalds/linux/blob/master/include/uapi/a...
- sickall 4y ago
  That depends on your architecture, on x86_64 it's generated from this file: https://github.com/torvalds/linux/blob/master/arch/x86/entry/syscalls/syscall_64.tbl https://github.com/torvalds/linux/blob/master/arch/x86/entry...
- rep_lodsb 4y ago
  Despite what the comment at the start of that file says, these aren't the right syscall numbers for x86-64 (nor x86-32!) 64 bit: read = 0, write = 1, open = 2 ... 32 bit: restart_syscall = 0, exit = 1, fork = 2 ... It's like they shuffle these around on purpose and don't bother to properly document it anywhere.
  - matheusmoreira 4y ago
    You're right, there seems to be some special mechanisms for x86, x86_64 and x86_32. The asm include for x86 is here: https://github.com/torvalds/linux/blob/master/arch/x86/include/uapi/asm/unistd.h https://github.com/torvalds/linux/blob/master/arch/x86/inclu... It includes either unistd_32.h or unistd_64.h. Those headers don't seem to be in the repository anymore. It seems they are generated from the system call tables as sickall mentioned and exported to user space as C header files. https://github.com/torvalds/linux/blob/master/arch/x86/entry/syscalls/syscall_32.tbl https://github.com/torvalds/linux/blob/master/arch/x86/entry... https://github.com/torvalds/linux/blob/master/arch/x86/entry/syscalls/syscall_64.tbl https://github.com/torvalds/linux/blob/master/arch/x86/entry... The following commit introduced this auto-generation mechanism: https://github.com/torvalds/linux/commit/303395ac3bf3e2cb488435537d416bc840438fcb https://github.com/torvalds/linux/commit/303395ac3bf3e2cb488... Other architectures just define some macros which modify the behavior of the asm-generic unistd.h header. For example, the arm64 unistd.h defines macros and then just includes it: https://github.com/torvalds/linux/blob/master/arch/arm64/include/uapi/asm/unistd.h https://github.com/torvalds/linux/blob/master/arch/arm64/inc... #define __ARCH_WANT_RENAMEAT #define __ARCH_WANT_NEW_STAT #define __ARCH_WANT_SET_GET_RLIMIT #define __ARCH_WANT_TIME32_SYSCALLS #define __ARCH_WANT_SYS_CLONE3 #define __ARCH_WANT_MEMFD_SECRET #include <asm-generic/unistd.h> I suppose x86 is too old or too different to fit this paradigm.
jcranmer 4y ago
It seems that the newest syscall it has listed (finit_module) is from Linux 3.8, and the oldest syscall that is not listed (sched_setattr) is from Linux 3.14, which makes this a surprisingly old list.
slabity 4y ago
Does anyone know if there are any similar lists for the huge number of `ioctls` that are available across different devices? I would absolutely love to have a table of those, including the device types and the structures that get passed along with it. It would make creating interfaces for different languages far easier.
- sickall 4y ago
  There's a pretty decent set of autogenerated lists present in the strace source, see e.g. https://github.com/strace/strace/blob/master/src/linux/64/ioctls_inc.h https://github.com/strace/strace/blob/master/src/linux/64/io...
sickall 4y ago
This is way out of date, by nearly a decade - it's missing everything from at least v3.14 onwards, possibly earlier. And some of the source files it references have been moved around and refactored too.
hmry 4y ago
I've been using this website for years (since it's one of the top results on Google) and it has always said "32-bit coming soon". I have given up on it actually ever coming. Not sure why it even includes x86 in the title besides SEO manipulation at this point
nandkeypull 4y ago
For my syscall lookup needs, I prefer https://x64.syscall.sh/ https://x64.syscall.sh/. It's more up to date and also supports x86, arm, and aarch64. pwn constgrep also works in a pinch: https://docs.pwntools.com/en/stable/commandline.html#pwn-constgrep https://docs.pwntools.com/en/stable/commandline.html#pwn-con...
dundarious 4y ago
I typically use https://chromium.googlesource.com/chromiumos/docs/+/HEAD/constants/syscalls.md https://chromium.googlesource.com/chromiumos/docs/+/HEAD/con... which includes many architectures and is likely relied upon for actual use.
- yencabulator 4y ago
  This seemed promising, but this is also kinda scary: > Compiled from Linux 4.14.0 headers. We're in the 6.x's now!
  - dundarious 4y ago
    That's a noteworthy limitation, but the OP's link is even more out-of-date. It's not a significant concern for me -- I primarily use "old" syscalls anyway, and I assume that is common. So it's good that you bring it up, but being up-to-date wasn't one of the benefits I listed.
snvzz 4y ago
Too many.
1letterunixname 4y ago
If you need a searchable syscall table, then your kernel is a kitchen-sink dumping ground for code AND has a giant attack surface with unknown # of LCE 0d's. There needs to be improvements in eBPF-like DSL/VMs that run in isolated, in-kernel contexts to accomplish particular latency-sensitive and coordination tasks. These can potentially be JITed as well.
- Retr0id 4y ago
  > These can potentially be JITed as well. In-kernel JIT is a scary prospect. I'm sure it can be done securely (perhaps even provably so), but it's a whole can of security-flavoured worms in itself.
  - LargoLasskhyfv 4y ago
    https://man.netbsd.org/bpfjit.4 https://man.netbsd.org/bpfjit.4
    - Retr0id 4y ago
      Not the same BPF JIT, but, https://www.cvedetails.com/cve/CVE-2021-29154/ https://www.cvedetails.com/cve/CVE-2021-29154/
      - LargoLasskhyfv 4y ago
        I'm aware of that. But it's fun, the same way as Lua in the kernel. Which simplyfies picking parts out and moving them into https://en.wikipedia.org/wiki/Rump_kernel https://en.wikipedia.org/wiki/Rump_kernel , or FPGAs. I've been wary to use that on a system locked down with https://en.wikipedia.org/wiki/Veriexec https://en.wikipedia.org/wiki/Veriexec exposed to the net in the past, but not anymore. OTOH it's all moot, or are you using a browser with settings which BLOCK JS, WEB-RTC/GL/GPU and countless other stuff by default?
Retr0id 4y ago
Can we please edit the title to clarify that it's only x86_64? The 32-bit version has been "coming soon" for many years now (very relatable!), but this page still pollutes my search results when looking for 32-bit syscall tables (although thankfully the ChromiumOS docs page has recently supplanted it, linked elsewhere in this thread) To be clear I'm not mad at the author, it's a useful resource and I'm thankful for it's existence, but search engines still suck. See also: https://marcin.juszkiewicz.com.pl/download/tables/syscalls.html https://marcin.juszkiewicz.com.pl/download/tables/syscalls.h... https://chromium.googlesource.com/linux-syscall-support/ https://chromium.googlesource.com/linux-syscall-support/
t-3 4y ago
What is the use of this? Why not just grep sys/syscall.h?
woodruffw 4y ago
This is an old resource, but one that helped me out a lot when writing a fault injection tool for Linux[1]. [1]: https://github.com/trailofbits/krf https://github.com/trailofbits/krf
samsquire 4y ago
This is great, thank you for this. What I want is an x86 and ARM opcodes database.
cylinder714 4y ago
Plan 9 System Calls "All of 'em (excluding obsolete ones)." http://aiju.de/plan_9/plan9-syscalls http://aiju.de/plan_9/plan9-syscalls

88 points by ingve 4y ago

what would it take to implement user mode linux (where syscalls are... stubbed from what I can tell? no... that's not right. where hardware is virtualized/mocked? i don't know the right terminology) for something like Mac OS X (arm64/aarch64) so that Mac users could benefit from "containerization" in a hipster way

pcwalton 4y ago
The Linux kernel API is so complex, and so ill-specified, that the only practical way that would maintain userspace compatibility would be to run the Linux kernel itself under macOS. (Microsoft tried to implement the Linux API in NT with WSL 1 and they abandoned that approach in WSL 2 because, among other reasons, it was just too much work to achieve Linux compatibility.) Running the Linux kernel under macOS can be done with Apple's hypervisor framework.
- twoodfin 4y ago
  Isn't this what the Illumos folks did (tried to do?) with LX-branded zones?
- MuffinFlavored 4y ago
  > would be to run the Linux kernel itself under macOS. is that not "user mode linux"?
  - simcop2387 4y ago
    Not quite, UML is the linux kernel ported to be an executable that runs under Linux. It's design kind of requires the system calls from Linux to be able to run properly. Making a translation layer for that isn't impossible but it would add more overhead to running things that way. Running a VM in a hypervisor, you're instead creating a whole virtual computer and its IO interfaces instead of at the system call level. Because there's hardware support for doing that virtualization (basically the CPU can help isolate the new process so that it can't see real hardware and the hypervisor gets notified/pulled in when needed to emulate the IO) it can end up nearly native speed if setup correctly.
    - MuffinFlavored 4y ago
      > Not quite, UML is the linux kernel ported to be an executable that runs under Linux. It's design kind of requires the system calls from Linux to be able to run properly. How large of an effort would it be to make it work on Mac? Monstrous? Not that bad? 100 hours? 1000 hours? For what payoff?
      - saagarjha 4y ago
        Several dozen to several hundred hours?
- simcop2387 4y ago
  I believe this is actually one of the ways that Docker actually implements things for their MacOS support, so it's already done for containerization type stuff. Though I don't believe that docker gives you any real access to the "host" that is sets up for doing this. https://docs.docker.com/desktop/faqs/macfaqs/ https://docs.docker.com/desktop/faqs/macfaqs/
- mirashii 4y ago
  > they abandoned that approach in WSL 2 because, among other reasons, it was just too much work to achieve Linux compatibility Any particular citation for this claim? I tried to do some searching and couldn't find anything definitive, but my memory from contemporaneous conversations and articles suggests that the primary reason was really performance, since the differences in how filesystem access in particular work between Windows/Linux were such that some of the I/O bottlenecks were deemed too difficult to impossible to address. Certainly WSL2 has higher compatibility, but I'm not sure that compatibility and not performance was the primary driver, and would love a source if you have one. Relatedly, it's worth noting that a number of other platforms have developed and shipped syscall translation layers for Linux binaries, including FreeBSD and SmartOS/illumos.
  - FatalException 4y ago
    The WSL2 architecture video lists two motivators from WSL1 based on number of Github issues. One of them being file performance and the other syscall compatibility with some specific examples being the ptrace syscall and Docker compatibilty. https://youtu.be/lwhMThePdIo?t=755 https://youtu.be/lwhMThePdIo?t=755 The HN submission for the youtube video also has discussion about the same topics. https://news.ycombinator.com/item?id=19868282 https://news.ycombinator.com/item?id=19868282
  - NGRhodes 4y ago
    https://devblogs.microsoft.com/commandline/announcing-wsl-2/ https://devblogs.microsoft.com/commandline/announcing-wsl-2/ > Our top requests from the WSL community have been to increase the file system performance, and make more apps work inside of WSL (i.e: introduce better system call compatibility). We have heard your feedback, and are glad to announce that WSL 2 helps solve these issues. > In WSL 1 we created a translation layer that interprets many of these system calls and allows them to work on the Windows NT kernel. However, it’s challenging to implement all of these system calls, resulting in some apps being unable to run in WSL 1. Now that WSL 2 includes its own Linux kernel it has full system call compatibility.
- circuit10 4y ago
  The iSH app on iOS does this I think and it mostly works
- yencabulator 4y ago
  > that the only practical way that would maintain userspace compatibility would be to run the Linux kernel itself Meanwhile, Google Container Engine uses gVisor, where the syscalls are implemented by some Go libraries with a very narrow seccomp interface to the actual host.
matheusmoreira 4y ago
QEMU has this feature. It can run Linux programs by translating their system calls. https://www.qemu.org/docs/master/user/main.html https://www.qemu.org/docs/master/user/main.html
- MuffinFlavored 4y ago
  How is performance?
simcop2387 4y ago
You probably want to take a look at gVisor[1], there's some desire for it to work on other systems like macos[2]. It doesn't have a working solution there yet but it's probably the easiest way to make something like Microsoft's WSL1 which handled things that way. You'll get a lot of the boiler plate out of the way that you'd need to pretend to be a Linux system, and just have to implement the translations to MacOS calls through some kind of library. From the looks of the github thread it seems the main issue to doing it is cgroup support since there isn't anything similar to it on the other side. [1] https://en.wikipedia.org/wiki/GVisor https://en.wikipedia.org/wiki/GVisor [2] https://github.com/google/gvisor/issues/1270 https://github.com/google/gvisor/issues/1270
jcranmer 4y ago
FreeBSD has a syscall compatibility layer for Linux: https://wiki.freebsd.org/Linuxulator https://wiki.freebsd.org/Linuxulator. As noted by other people, Windows used to have such a compatibility layer as well, but they've moved away from it newer versions.
saagarjha 4y ago
https://github.com/ish-app/ish/blob/master/kernel/calls.c https://github.com/ish-app/ish/blob/master/kernel/calls.c
dundarious 4y ago
I've never used it, but https://github.com/jart/blink https://github.com/jart/blink is pretty much that. It's tiny and: > We regularly test that Blink is able run x86-64-linux binaries on the following platforms: > Linux (x86, ARM, RISC-V, MIPS, PowerPC, s390x) > macOS (x86, ARM) > FreeBSD > OpenBSD > Cygwin From what I gather, it's in the "excellent but incomplete" stage. It's new enough.

matheusmoreira 4y ago

I've used this list many times, thanks. The header file with the definitions that get exported to user space is here: https://github.com/torvalds/linux/blob/master/include/uapi/asm-generic/unistd.h https://github.com/torvalds/linux/blob/master/include/uapi/a...

sickall 4y ago
That depends on your architecture, on x86_64 it's generated from this file: https://github.com/torvalds/linux/blob/master/arch/x86/entry/syscalls/syscall_64.tbl https://github.com/torvalds/linux/blob/master/arch/x86/entry...
rep_lodsb 4y ago
Despite what the comment at the start of that file says, these aren't the right syscall numbers for x86-64 (nor x86-32!) 64 bit: read = 0, write = 1, open = 2 ... 32 bit: restart_syscall = 0, exit = 1, fork = 2 ... It's like they shuffle these around on purpose and don't bother to properly document it anywhere.
- matheusmoreira 4y ago
  You're right, there seems to be some special mechanisms for x86, x86_64 and x86_32. The asm include for x86 is here: https://github.com/torvalds/linux/blob/master/arch/x86/include/uapi/asm/unistd.h https://github.com/torvalds/linux/blob/master/arch/x86/inclu... It includes either unistd_32.h or unistd_64.h. Those headers don't seem to be in the repository anymore. It seems they are generated from the system call tables as sickall mentioned and exported to user space as C header files. https://github.com/torvalds/linux/blob/master/arch/x86/entry/syscalls/syscall_32.tbl https://github.com/torvalds/linux/blob/master/arch/x86/entry... https://github.com/torvalds/linux/blob/master/arch/x86/entry/syscalls/syscall_64.tbl https://github.com/torvalds/linux/blob/master/arch/x86/entry... The following commit introduced this auto-generation mechanism: https://github.com/torvalds/linux/commit/303395ac3bf3e2cb488435537d416bc840438fcb https://github.com/torvalds/linux/commit/303395ac3bf3e2cb488... Other architectures just define some macros which modify the behavior of the asm-generic unistd.h header. For example, the arm64 unistd.h defines macros and then just includes it: https://github.com/torvalds/linux/blob/master/arch/arm64/include/uapi/asm/unistd.h https://github.com/torvalds/linux/blob/master/arch/arm64/inc... #define __ARCH_WANT_RENAMEAT #define __ARCH_WANT_NEW_STAT #define __ARCH_WANT_SET_GET_RLIMIT #define __ARCH_WANT_TIME32_SYSCALLS #define __ARCH_WANT_SYS_CLONE3 #define __ARCH_WANT_MEMFD_SECRET #include <asm-generic/unistd.h> I suppose x86 is too old or too different to fit this paradigm.

jcranmer 4y ago

It seems that the newest syscall it has listed (finit_module) is from Linux 3.8, and the oldest syscall that is not listed (sched_setattr) is from Linux 3.14, which makes this a surprisingly old list.

slabity 4y ago

Does anyone know if there are any similar lists for the huge number of `ioctls` that are available across different devices? I would absolutely love to have a table of those, including the device types and the structures that get passed along with it. It would make creating interfaces for different languages far easier.

sickall 4y ago
There's a pretty decent set of autogenerated lists present in the strace source, see e.g. https://github.com/strace/strace/blob/master/src/linux/64/ioctls_inc.h https://github.com/strace/strace/blob/master/src/linux/64/io...

sickall 4y ago

This is way out of date, by nearly a decade - it's missing everything from at least v3.14 onwards, possibly earlier. And some of the source files it references have been moved around and refactored too.

hmry 4y ago

I've been using this website for years (since it's one of the top results on Google) and it has always said "32-bit coming soon". I have given up on it actually ever coming. Not sure why it even includes x86 in the title besides SEO manipulation at this point

nandkeypull 4y ago

For my syscall lookup needs, I prefer https://x64.syscall.sh/ https://x64.syscall.sh/. It's more up to date and also supports x86, arm, and aarch64. pwn constgrep also works in a pinch: https://docs.pwntools.com/en/stable/commandline.html#pwn-constgrep https://docs.pwntools.com/en/stable/commandline.html#pwn-con...

dundarious 4y ago

I typically use https://chromium.googlesource.com/chromiumos/docs/+/HEAD/constants/syscalls.md https://chromium.googlesource.com/chromiumos/docs/+/HEAD/con... which includes many architectures and is likely relied upon for actual use.

yencabulator 4y ago
This seemed promising, but this is also kinda scary: > Compiled from Linux 4.14.0 headers. We're in the 6.x's now!
- dundarious 4y ago
  That's a noteworthy limitation, but the OP's link is even more out-of-date. It's not a significant concern for me -- I primarily use "old" syscalls anyway, and I assume that is common. So it's good that you bring it up, but being up-to-date wasn't one of the benefits I listed.

snvzz 4y ago

Too many.

1letterunixname 4y ago

If you need a searchable syscall table, then your kernel is a kitchen-sink dumping ground for code AND has a giant attack surface with unknown # of LCE 0d's. There needs to be improvements in eBPF-like DSL/VMs that run in isolated, in-kernel contexts to accomplish particular latency-sensitive and coordination tasks. These can potentially be JITed as well.

Retr0id 4y ago
> These can potentially be JITed as well. In-kernel JIT is a scary prospect. I'm sure it can be done securely (perhaps even provably so), but it's a whole can of security-flavoured worms in itself.
- LargoLasskhyfv 4y ago
  https://man.netbsd.org/bpfjit.4 https://man.netbsd.org/bpfjit.4
  - Retr0id 4y ago
    Not the same BPF JIT, but, https://www.cvedetails.com/cve/CVE-2021-29154/ https://www.cvedetails.com/cve/CVE-2021-29154/
    - LargoLasskhyfv 4y ago
      I'm aware of that. But it's fun, the same way as Lua in the kernel. Which simplyfies picking parts out and moving them into https://en.wikipedia.org/wiki/Rump_kernel https://en.wikipedia.org/wiki/Rump_kernel , or FPGAs. I've been wary to use that on a system locked down with https://en.wikipedia.org/wiki/Veriexec https://en.wikipedia.org/wiki/Veriexec exposed to the net in the past, but not anymore. OTOH it's all moot, or are you using a browser with settings which BLOCK JS, WEB-RTC/GL/GPU and countless other stuff by default?

Retr0id 4y ago

Can we please edit the title to clarify that it's only x86_64? The 32-bit version has been "coming soon" for many years now (very relatable!), but this page still pollutes my search results when looking for 32-bit syscall tables (although thankfully the ChromiumOS docs page has recently supplanted it, linked elsewhere in this thread) To be clear I'm not mad at the author, it's a useful resource and I'm thankful for it's existence, but search engines still suck. See also: https://marcin.juszkiewicz.com.pl/download/tables/syscalls.html https://marcin.juszkiewicz.com.pl/download/tables/syscalls.h... https://chromium.googlesource.com/linux-syscall-support/ https://chromium.googlesource.com/linux-syscall-support/

t-3 4y ago

What is the use of this? Why not just grep sys/syscall.h?

woodruffw 4y ago

This is an old resource, but one that helped me out a lot when writing a fault injection tool for Linux[1]. [1]: https://github.com/trailofbits/krf https://github.com/trailofbits/krf

samsquire 4y ago

This is great, thank you for this. What I want is an x86 and ARM opcodes database.

cylinder714 4y ago

Plan 9 System Calls "All of 'em (excluding obsolete ones)." http://aiju.de/plan_9/plan9-syscalls http://aiju.de/plan_9/plan9-syscalls