Something else that comes to mind is libffi. It implements FFI via a JIT compiler generating trampolines, and they have hard-wired support for SELinux execmem where they work around support for dynamic code generating being disallowed in-memory by doing it via /tmp. Yet...
Conversation
... a proper policy will disallow doing it via the filesystem in any way too. Only something like a package manager generally actually needs to expose the attack surface of being able to create files which could be executed. They could definitely handle normal cases without JIT.
1
cgit.freedesktop.org/mesa/mesa/tree is not as bad since it just disables an optimization, which if I recall correctly is totally unnecessary. A lot of GPU drivers have a JIT simply as a way of removing one layer of function calls. It becomes more and more normal for everything to have a JIT.
1
Replying to
Here's the libffi one which I absolutely despise since it's very widespread:
github.com/libffi/libffi/
The library exists to provide dynamic FFI instead of needing wrapper libraries, which I've come to regard as a bad idea beyond the JIT compiler. People get the signatures wrong.
1
2
It means people are hard-wiring the signatures of C functions in other languages, often in a much less portable way. For example, by using `int` for a type that is only `int` on some platforms. There's no type checking, just the dynamically generated trampolines at runtime.
1
1
You can see how crazy it is from this little tutorial:
pgi-jcns.fz-juelich.de/portal/pages/u
It's hard-wired in Python so whatever complexity exists in the C headers for portability across platforms is easily missed. You get memory corruption at runtime from a mistake, with no sanity checks.
1
1
Replying to
Are you familiar with my claim that the only FFI into C, ever, should be via an embedded virtual machine for a simple ISA and an isolated ecosystem of C binaries built for this ISA that can be shipped as target-independent assets?
1
Replying to
Languages with ahead-of-time compilation can incorporate libclang into their toolchain to implement native calls into C with proper static checking and without boilerplate. A dynamic language could essentially do the same thing by requiring compilation to make use of C FFI.
2
Replying to
Even if the call-into is checkable, the code isn't internally checkable; it negates all memory-safety of the calling language. Embedding a virtual machine that can't see outside its own memory space doesn't.
1
Replying to
That's true. The virtual machine could also be provided by the OS as part of the sandbox. It's also an opportunity to implement a higher-level sandbox above the OS sandbox layer, so a malicious or compromised app needs to do more than just compromising the kernel from there.
libffi author here. I also created one of those simple ISAs (moxie) with VM implementations, with a full GNU toolchain - so I've got you covered either way... moxielogic.org/blog/ ,
1
1
3
(scanning up-thread)
Security was one of the key goals of moxiebox... The interpreter fits in one source file for ease of auditing. The sandbox pretends to be a kernel, giving complete machine & syscall control. No I/O or time, by default!
1
2