darling
darling copied to clipboard
darlinghq
Syscall User Dispatch - Linux 5.11
With the version 5.11 of the linux kernel came a feature called Syscall User Dispatch.
Syscall User Dispatch brings the filtering of the syscall dispatcher address back to userspace. The application is in control of a flip switch, indicating the current personality of the process. A multiple-personality application can then flip the switch without invoking the kernel, when crossing the compatibility layer API boundaries, to enable/disable the syscall redirection and execute syscalls directly (disabled) or send them to be emulated in userspace through a SIGSYS. The goal of this design is to provide very quick compatibility layer boundary crosses, which is achieved by not executing a syscall to change personality every time the compatibility layer executes. Instead, a userspace memory region exposed to the kernel indicates the current personality, and the application simply modifies that variable to configure the mechanism.
If I understand correctly, this allows a more efficient redirection of syscalls (E.g. windows syscalls to wine).
Is it planned to use this in darling, potentially improving performance?
As demonstrated here by a somewhat similar project.
https://github.com/meme/limbo
Well, this wouldn't really be a performance enhancement, but more of a compatibility enhancement, allowing (insane) applications that don't use libSystem to do kernel calls to work under Darling. Right now, the only syscall handling we do is through libSystem. If an app tries to perform direct syscalls, they end up calling into the Linux kernel. See #193.
Does launchd recursively wipe /run via libSystem or via direct system calls? I am still thinking about the incidents of darling wiping my external hard disks under /run/media/MyName/diskname on Linux
https://github.com/darlinghq/darling/issues/848 , and two different drives. :(
All the software Darling ships (including launchd) uses libSystem, not direct syscalls.
So I looked into this, and there are two blockers that prevent us from adopting Syscall User Dispatch for Darling:
- No ARM64 support (we might able to use
SECCOMP_RET_TRAPfor arm64, but it will be slower). - WSL1 doesn't support Syscall User Dispatch (I'm hoping that @trungnt2910 is able to implement Syscall User Dispatch support through lxmonika)
What's the upstream source that says it doesn't support ARM64 yet? I just want to be able to follow along on that.
What's the upstream source that says it doesn't support ARM64 yet?
I don't know if there is any active work in the Linux kernel to support Syscall User Dispatch for ARM64... there was one attempt by Ryan Houdek (Sonicadvance1).
https://github.com/Sonicadvance1/linux/commits/aarch64_user_dispatch https://lwn.net/ml/linux-kernel/CAPpY1ukO64rg6Ov=3pA2c0eV3ULEXLF+RjiR_KY4XMfQgD2Mhw@mail.gmail.com/