Why though? Doesn't this mean that all non-C based languages are going to be treated somewhat as second class citizens, having to link the standard C library (eg. as Go is doing on some platforms) in order to call into the kernel?
While languages such as Go and Rust are aiming to replace/displace C due to it being designed in an age where security was considered less of an issue, it seems counter-intuitive to me that we should insist that they should link in the apparent attack surface of the standard C library. The syscall boundary seems an ideal place to make the delineation between the kernel and userland via an established API, and I would have expected that languages that want to displace C be able to use that interface directly in order to bypass the standard C library. That would seem to allow userlands to be built that include no C code whatsoever. But I'm very obviously no expert.
Ideally, IMO, there should be two libraries, a “Kernel interface library” and a “C library”, but for now, just think of it as two logical libraries in a single file.
This feature is yet another layer of defense against remote exploitation of a currently running program (for example, a web browser). It complements things such as ASLR, stack canaries, the NX bit, ...
Hint: having some security and mitigations makes it less likely for an attacker to start with such capabilities.
If someone can show this is done by configuring the local dynamic linker, so that the end user has full control of the mechanism, then I'm all ears.
It's trying to mitigate exploits, but if your attacker is already running arbitrary code, they don't need those exploits. They're way past that phase.
Thankfully Apple, Google, IBM and Unisys seem to be on the same boat.
> Current Status - llvm-libc development is still in the planning phase.
> If all programs need to go through libc, doesn't that mean they are all equal?
It means that all programs need to link libc into their binary, whether statically or dynamically. Part of the reason-de-etre for Rust seems to be as a replacement for C and C++ so it would seem peculiar to me that the C library would become a forced dependency for compiled languages like those. But as the other poster pointed out, you can disable it anyway, so no matter.
As for static libc: please don't do this. A static libc, from a compatibility POV, is just as bad as embedding random SYSENTER instructions in program text. It makes the system much more brittle than it would otherwise be. I understand the desire to package a whole program into a single blob that works on every system, but we should support this use case with strong compatibility guarantees for libc, not with making SYSENTER the permanent support boundary!
When I am god emperor of mankind, on my first day, I will outlaw both static linking of libc and non-PIE main executables.
Preaching to the converted here, I'm a big fan of dynamic linking. It seems that while Go binaries are generally statically linked (last time I checked, which was a while ago), that libc is generally dynamically linked for the reasons that you have stated, also also because some features like NSS require dynamic linking to work correctly.
Disclaimer: I mostly program in C and C++, not Rust or Go (yet).
$ annocheck -v /usr/bin/ls
[...]
Hardened: /usr/bin/ls: PASS: Compiled with -fcf-protection.