The latter kinda makes sense because the particular OS is so broken (vendor libs that call signal) but yes it's stupid that they're doing it to begin with.
Conversation
Replying to
The library they're talking about is a cross-platform GPU driver, and GPU drivers are in general full of insane code. They like setting up all kinds of trampolines and alternate stack shenanigans so they are full of hard-wired hacks just like Firefox, which often conflict.
2
1
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...
1
... 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.
Basically just generate an executable with the interpreted code included as data and link against the interpreter as a library for interpreting it. I wouldn't mind what you're proposing though. I think webassembly.org would be a lot more interesting outside of browsers.
1
Replying to
I'm skeptical of whether wasm is well-done at all for this; it looks unlikely that it can provide a full C environment with signals, alt stacks, threads, etc.; even longjmp may be difficult to do right. Just using an existing simple ISA (I'd be partial to SH :-) seems better.
1
Show replies
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.
1
Show replies