[HN Gopher] Searchable Linux Syscall Table for x86 and x86_64
___________________________________________________________________
Searchable Linux Syscall Table for x86 and x86_64
Author : ingve
Score : 26 points
Date : 2023-04-14 20:23 UTC (2 hours ago)
(HTM) web link (filippo.io)
(TXT) w3m dump (filippo.io)
| matheusmoreira wrote:
| 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/a...
| sickall wrote:
| That depends on your architecture, on x86_64 it's generated
| from this file:
| https://github.com/torvalds/linux/blob/master/arch/x86/entry...
| sickall wrote:
| 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 wrote:
| 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
| MuffinFlavored wrote:
| 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 wrote:
| 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.
| MuffinFlavored wrote:
| > would be to run the Linux kernel itself under macOS.
|
| is that not "user mode linux"?
| simcop2387 wrote:
| 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 wrote:
| > 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?
| simcop2387 wrote:
| 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/
| mirashii wrote:
| > 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.
| twoodfin wrote:
| Isn't this what the Illumos folks did (tried to do?) with LX-
| branded zones?
| matheusmoreira wrote:
| QEMU has this feature. It can run Linux programs by translating
| their system calls.
|
| https://www.qemu.org/docs/master/user/main.html
| simcop2387 wrote:
| 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 [2]
| https://github.com/google/gvisor/issues/1270
| jcranmer wrote:
| FreeBSD has a syscall compatibility layer for Linux:
| 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.
| jcranmer wrote:
| 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 wrote:
| 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 wrote:
| 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/io...
| nandkeypull wrote:
| For my syscall lookup needs, I prefer 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-con...
___________________________________________________________________
(page generated 2023-04-14 23:00 UTC)