... 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.
Conversation
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
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
Replying to
It's going to have native support for threads, signals and exceptions / unwinding. There's a thread proposal deployed in Chromium as a disabled-by-default developer feature.
github.com/WebAssembly/de
Having a more structured architecture has advantages:
webassembly.org/docs/security/