> We have implemented (fully or partially) 48 POSIX Functions from above. ...[however] These 24 POSIX Functions will Halt when TCC WebAssembly calls them…
I was just wondering this evening: I have seen WASM described as an environment for selectively subsetting interfaces, in part for security. Is the following sometimes done?: Compile and link to a "glibc" which implements only a subset of calls, again for runtime security?
That's basically what WASI is about (or now the specific derivation called WASIX). Essentially a POSIX runtime for WASM, but typically using musl instead of glibc.
A few months ago Wasmer tried add WASIX support to Zig so anything on Zig ecosystem could target the browser easily, which is quite relatable of what the TCC compiler is trying to achieve. I'm sure at some moment the community will pick it up.
I'll drop a link to WASIX in case is useful for the reader!
Is it memory safe enough and if it helps mitigating other kinds of errors without being in the way. It will find its place in the programming world.
I think what zig really needs is something like the rust Axum ecosystem for web backend development. I would never be able to make a zig case at work without those sort of frameworks. People would say why zig without web related packages when you also have GOlang.
In order to be useful, a sandboxed program needs to communicate with the environment (the equivalent of system calls). If you can corrupt internal state, you can control the arguments to those calls, which may have security implications.
For example, if you corrupt a program that's allowed to use web sockets, you'll be able to port scan the user's local network.
If that actually works in a browser wasm environment then it's also possible from Javascript, which is a memory safe language (eg either the sandbox works or it doesn't, that also includes the external APIs).
You can still have memory safety bugs in WASM. The difference is that they can only do memory unsafe things within the sandbox. That's better than nothing but still not as good as actual memory safety.
From a security pov it doesn't make a difference though, the sandbox needs to be able to safely contain untrusted code, no matter if the code is riddled with memory bugs or not.
How do you figure? Imagine a server component that runs in wasm (pretty common). Memory safety bugs could easily lead to information leaks and privilege bypass entirely within the wasm sandbox.
The important part is within the wasm sandbox. Don't run multiple components in the same WASM instance because they can't be properly isolated from each other.
That's why traditional operating systems have processes that can't access each others memory. WASM instances don't have this sort of "internal isolation", anything running in the same instance can access all memory in that instance, memory safe language or not.
Again, language-level safety doesn't matter here. It makes a lot of sense to write the sandbox itself in Rust, but it must not matter whether code running inside the sandbox is written in Rust. If that would be required, the sandbox has already failed.
For example, let's assume you have a graphics editor running in the browser that stores files in the cloud. If it uses a vulnerable C library to decode image data, an attacker might be able to play havoc with your files despite the sandbox never technically having been breached.
This can be mitigated by either using a safe language, or having the decoder run in an isolated wasm instance. Either way, you have to design your application with these considerations in mind and can't just take arbitrary, potentially vulnerable applications, compile them to wasm and be done with it.
The worst that can happen is that the image tool saves back a corrupted image. But that's also possible with a buggy (but memory safe) Rust image loader/saver, memory safety doesn't automatically fix all classes of bugs.
Apart from that it would be quite a feat to use internal memory corruption for anything useful in WASM, because both the code and callstack live outside the sandbox and are not accessible from within (e.g. tricks like return-oriented programming are not possible in WASM.
Thanks for the link, very interesting! But TBF: the 'host program' has to be written in a very specific way to allow that rogue Javascript execution, it's very similar to allowing an SQL injection to happen.
I also wonder why stack canaries wouldn't work on WASM, since the compiler creates stack frames on the data-only stack just the same (but maybe Clang's `-fstack-protector` doesn't work for some reason in WASM, I'll actually need to check that).
I'd say for the vast majority of use cases, it is.
Pluggable allocators + good test coverage make it trivial to catch a lot of the more common memory issues and exhaustive switches are quite robust (though it can be tricky when the branches vary according to the target platform).
Also, it is far easier to code in an exploratory, iterative fashion in Zig than it is in Rust.
Overall, I think with Zig and Go you can cover a lot of programming use cases. In fact, I find Go to be pretty damn fast out-of-the-box and in a lot of real world scenarios can match Zig/Rust (production builds). All three have room for fine tuning (at the expense of readability), though of course the ceiling is much higher in Zig and Rust.
Not to mention, Rust won't protect you from logic issues, you can definitely do the wrong thing correctly.
Why use a custom compiler for one specific target when you could have a single compiler that support any target you want? It doesn’t look like emscripten has an integrated build system either?
I think that’s the genius of Zig.. one of the main goals is to build a better and faster C compiler. It might end up being the only C compiler with really solid hot-swapping support. And then if you’re already using the compiler you might as well start using the language too.
The Zig compiler bundles the SDKs of supported targets while Clang does not, so you can cross compile out of the box without any extra steps. It also defines targets for various GLIBC versions which AFAICT Clang does not.
Did you actually try it? Across Windows, Linux and macOS? Setting up a vanilla Clang toolchain for cross-compilation is by far not as trivial as you make it sound.
There is a heck of a lot to be said for making it a painless process. Yes, you can cross compile C and C++. No, it is not at all simple to set up. I've used rust for projects for similar reasons: if I want to cross compile from windows to linux it is ridiculously less painful to compile pure rust than C or C++ (especially if I want to set up a new machine for it).
One reason is that the Zig toolchain has fewer "moving parts" than the Emscripten toolchain (e.g. Emscripten depends on Node.js, Python, the Google Closure compiler with an embedded Java runtime, and various WABT tools), and while all these tools are installed automatically by the Emscripten SDK installer, it's still a lot of individual parts that can break.
OTH the Clang compiler doesn't come with the necessary cross-compilation C library and headers.
From that pov, the Zig toolchain is indeed the best option to compile a WASM blob that's not WASI (in that case, there's also the WASI SDK, which is a similar self-contained toolchain as the Zig toolchain) - PS: Zig can also compile to WASI out of the box though.
Just one toolchain to install in order to compile to the native CPU, using any glibc version, to other architectures, and, for WebAssembly, to any variant (emscripten, freestanding, WASI). Zig a very common way to compile C/C++ code to WASI and the only one that can optimize it for a given runtime.
Same, consistent tools and versions everywhere. No need to have 10 different LLVM copies on your system.
Plus, the toolchain already includes a build system, a package manager, a cache, a way to run tests, etc.
50 comments
[ 4.1 ms ] story [ 54.2 ms ] thread> We have implemented (fully or partially) 48 POSIX Functions from above. ...[however] These 24 POSIX Functions will Halt when TCC WebAssembly calls them…
I was just wondering this evening: I have seen WASM described as an environment for selectively subsetting interfaces, in part for security. Is the following sometimes done?: Compile and link to a "glibc" which implements only a subset of calls, again for runtime security?
I'll drop a link to WASIX in case is useful for the reader!
https://wasix.org
[1] https://llvm.org/docs/ExceptionHandling.html#sjlj-intrinsics
[1] https://github.com/Mati365/ts-c-compiler
Also as remark, Zig is going to be the new Modula-2, with revamped syntax for C minded folks, and compile time support.
Assuming it takes off post 1.0, still a long to go in the adoption chasm graph.
I think what zig really needs is something like the rust Axum ecosystem for web backend development. I would never be able to make a zig case at work without those sort of frameworks. People would say why zig without web related packages when you also have GOlang.
WebAssembly sandboxes apparently are going to sort out all security issues in modern computing.
For example, if you corrupt a program that's allowed to use web sockets, you'll be able to port scan the user's local network.
That's why traditional operating systems have processes that can't access each others memory. WASM instances don't have this sort of "internal isolation", anything running in the same instance can access all memory in that instance, memory safe language or not.
Again, language-level safety doesn't matter here. It makes a lot of sense to write the sandbox itself in Rust, but it must not matter whether code running inside the sandbox is written in Rust. If that would be required, the sandbox has already failed.
It very well can:
For example, let's assume you have a graphics editor running in the browser that stores files in the cloud. If it uses a vulnerable C library to decode image data, an attacker might be able to play havoc with your files despite the sandbox never technically having been breached.
This can be mitigated by either using a safe language, or having the decoder run in an isolated wasm instance. Either way, you have to design your application with these considerations in mind and can't just take arbitrary, potentially vulnerable applications, compile them to wasm and be done with it.
Apart from that it would be quite a feat to use internal memory corruption for anything useful in WASM, because both the code and callstack live outside the sandbox and are not accessible from within (e.g. tricks like return-oriented programming are not possible in WASM.
Instead of popping up an alert, you could have requested the deletion of all files in the cloud storage.
I also wonder why stack canaries wouldn't work on WASM, since the compiler creates stack frames on the data-only stack just the same (but maybe Clang's `-fstack-protector` doesn't work for some reason in WASM, I'll actually need to check that).
I'd say for the vast majority of use cases, it is.
Pluggable allocators + good test coverage make it trivial to catch a lot of the more common memory issues and exhaustive switches are quite robust (though it can be tricky when the branches vary according to the target platform).
Also, it is far easier to code in an exploratory, iterative fashion in Zig than it is in Rust.
Overall, I think with Zig and Go you can cover a lot of programming use cases. In fact, I find Go to be pretty damn fast out-of-the-box and in a lot of real world scenarios can match Zig/Rust (production builds). All three have room for fine tuning (at the expense of readability), though of course the ceiling is much higher in Zig and Rust.
Not to mention, Rust won't protect you from logic issues, you can definitely do the wrong thing correctly.
I think that’s the genius of Zig.. one of the main goals is to build a better and faster C compiler. It might end up being the only C compiler with really solid hot-swapping support. And then if you’re already using the compiler you might as well start using the language too.
Sometimes I wonder how much people nowadays actually bother to learn about compiled languages.
It is not a walk in the park, but it hardly a task only worthy of Hercules.
OTH the Clang compiler doesn't come with the necessary cross-compilation C library and headers.
From that pov, the Zig toolchain is indeed the best option to compile a WASM blob that's not WASI (in that case, there's also the WASI SDK, which is a similar self-contained toolchain as the Zig toolchain) - PS: Zig can also compile to WASI out of the box though.
Same, consistent tools and versions everywhere. No need to have 10 different LLVM copies on your system.
Plus, the toolchain already includes a build system, a package manager, a cache, a way to run tests, etc.