I, for one, would love to have the Linux port, at least, changed to do raw syscalls instead of going through (g)libc.
Is there another motivation for avoiding the system call wrappers from libc?
When you are building a system where you have to security audit everything, including even the libc, it is nice if most of what libc does is in Rust so that you can take advantage of the safety features of Rust that made one choose it in the first place. glibc is probably OK, but that doesn’t help at all on a platform that uses musl libc. And, when we build on a Linux variant where libc isn’t glibc, we have to worry about what glibc-specific decisions have been made in the Rust standard library.
Maybe you think the above is overkill, but it is basically what one has to do to use seccomp-bpf most effectively.
Longer term, I am also interested in operating systems in Rust. IMO, the way to get a viable set of Rust operating systems is to code both from the bottom up (kernel and drivers first) and from the top down (userspace libraries and applications first) and have them meet in the middle. I am approaching this from the top-down angle, as it seems there are many others approaching it from the bottom-up angle.
Note that almost all people I’ve asked “Go or Rust for server-side development” have answered “Go”. There are lots of reasons for this, but one is particularly relevant here: They don’t have to worry about DLL hell when compiling a Go program and then deploying it on their systems because Go executables are (usually) self-contained. IMO, this is evidence of problems with how these people are doing deployment in the first place, but it was an issue that has been brought up by several people.
Regarding the size issue: IMO, the size tradeoff can be managed by making the Rust standard library available as either a statically-linked or dynamically-linked thing, just like libc is.
Note that there is a good chunk of functionality that is purely from libc that Rust would still use: all the threading and concurrency stuff is built on top of pthread, std::net does hostname resolution, std::env::home_dir uses NSS, std::dynamic_lib wouldn’t work at all, backtracing uses dladdr, etc. If you wanted to have a completely freestanding libstd that only makes raw syscalls, you’d need pure-Rust reimplementations of these things. Certainly doable with work, but I’m not sure what the use case would be.
I certainly think all of those things should be done in Rust. But, it is a matter of prioritization and resources. I expect that the core Rust team wouldn’t have time to replace libpthread with Rust code. But, would they accept a Rust-coded replacement for libpthread–not one that is just transliterated from C to Rust, but actually optimized for safety using Rust’s language and library? Or, is the Rust team committed to the libc approach?
There’s also one notable downside to switching to native syscall wrappers: you can no longer easily LD_PRELOAD a Rust application and hook system calls.
There are many ways to do that without LD_PRELOAD.
Anyway, I think it would be helpful for the Rust team to indicate whether they are categorically opposed to the bypass-libc approach–i.e. whether they would accept patches that build a framework for doing that switch and/or otherwise make incremental progress towards that goal.
