mirror of
https://github.com/FEX-Emu/FEX.git
synced 2026-10-23 20:00:18 +02:00
Ryan Houdek
ac32876e4e
Seccomp is a relatively complex feature that was added to Linux back in
2005, and was further extended in 2013 to support BPF based protections.
Once seccomp is enabled, you can no longer disable seccomp but
additional protections can be placed on top of existing seccomp filters.
Additionally seccomp filters are inherited in child processes, which
ensures the process tree can't escape from the secure computing
environment through child processes.
The basis of this feature is a shim that lives between userspace and the
kernel at the syscall entrypoint.
In "strict" mode, seccomp only allows read, write, exit, exit_group, and {rt_,}sigreturn to function.
When in "filter" mode, a BPF filter is run on syscall entrypoint and
returns state about if the syscall should be allowed or not. Multiple
filters can be installed in this mode, all of which get executed. The
result that is the most restricted is the action that occurs at the end.
There are some significant limitations in filter mode that must be
adhered to which makes executing this code inside of kernel space a
non-issue and effectively limits how much cpu time is spent in the filters.
Although these filters are free to do basically anything with the
provided data, just can't do any loops.
FEX needs to implement seccomp because there are multiple applications
using the feature, the primary one being Chromium which some games embed
without disabling the sandbox. WINE also uses seccomp for capturing
games that do raw Windows system calls. Apparently Red Dead Redemption
is one of the games that requires this.
While FEX implements seccomp, it is not yet all encompassing, which is
one of the reasons why it isn't enabled by default and requires a config
option.
**seccomp_unotify is not implemented**
This is a relatively new feature for seccomp which lets the seccomp
filter signal an FD for multiple things. Luckily Chromium and WINE don't
use this. This will be tricky to implement under FEX since it
requires ioctl trapping and some other behaviour
**ptrace isn't supported**
One feature of seccomp is that it can raise ptrace events. Since FEX
doesn't support ptrace at all, this isn't handled. Again Chromium and
WINE don't use this.
**kill-thread not quite correct**
This isn't directly related to seccomp but more about how we do thread
shutdown in FEX. This will require some more changes around thread state
tracking before fully supporting this. Chromium and WINE don't use this.
kill-process also falls under this
Features that are supported:
- Strict mode and seccomp-bpf mode supported
- All BFP instructions that seccomp-bpf understands
- Inheriting seccomp through execve
- This means we serialize and deserialize the calling thread's
seccomp filters
- An execve that escapes FEX will also escape seccomp. Not much we
can do about it
- TSync - Allowing post-mortem seccomp insertion which allows threads to
synchronize seccomp filters after the fact
Features that are not supported:
- Different arch qualifiers depending on syscall entrypoint
- Just like our syscall handler, we are hardcoded to the arch that the
application starts with
- user_notif
- ptrace
- Runtime code cache invalidation when seccomp is installed
- Currently we must ensure all syscalls go through the frontend
syscall handler
- Runtime invalidation of code cache with inline syscalls will get
fixed in the future.
This currently isn't enabled by default because of the minor feature
problems that haven't been resolved. Currently the Linux Kernel's test
application works for the features that FEX supports, and WINE's usage
can be handled by FEX. Chromium's sandbox doesn't yet work with this PR,
but it only fails due to features unrelated to seccomp.
Having this open for merging now so we can work to resolve the remaining
issues without this bitrotting.
FEXCore - Fast x86 Core emulation library
This is the core emulation library that is used for the FEX emulator project. This project aims to provide a fast and functional x86-64 emulation library that can meet and surpass other x86-64 emulation libraries.
Goals
- Be as fast as possible, beating and exceeding current options for x86-64 emulation
- 25% - 50% lower performance than native code would be desired target
- Use an IR to efficiently translate x86-64 to our host architecture
- Support a tiered recompiler to allow for fast runtime performance
- Support offline compilation and offline tooling for inspection and performance analysis
- Support threaded emulation. Including emulating x86-64's strong memory model on weak memory model architectures
- Support a significant portion of the x86-64 instruction space.
- Including MMX, SSE, SSE2, SSE3, SSSE3, and SSE4*
- Support fallback routines for uncommonly used x86-64 instructions
- Including x87 and 3DNow!
- Only support userspace emulation.
- All x86-64 instructions run as if they are under CPL-3(userland) security layer
- Minimal Linux Syscall emulation for testing purposes
- Portable library implementation in order to support easy integration in to applications
Target Host Architecture
The target host architecture for this library is AArch64. Specifically the ARMv8.1 version or newer. The CPU IR is designed with AArch64 in mind but should allow for other architectures as well. x86-64 host support is available for ease of development, but is not a priority.
Not desired
- Kernel space emulation
- CPL0-2 emulation
- Real Mode, Protected Mode, Virtual-8086 Mode, System Management Mode
- IRQs
- SVM
- "Cycle Accurate" emulation