It makes me wonder why Google wouldn’t put their efforts into using Rust, for example.
Of course, server power is cheap, but not for our planet.
Even if all new code was written in safe languages we would still need to do fuzzing until all legacy code was rewritten -- operating systems, SSL libraries, browsers, load balancers, etc.
It's getting there.
My C programmer friends like the dangerous features of the language and want to use them. Their programs are designed around the assumption that they can mutate anything in memory whenever they want to. They use mutable global variables. They would strongly dislike Rust's memory protections and ownership concept, and its other safety features.
Integrating a new language into a new codebase is a lot of work; it would be great if Chromium started using it, but I also understand why it may be a harder sell there. Engineering is all about tradeoffs.
Not to say there isn't work on replacement efforts, only that testing what is in use is a practical thing, even if the scale is surprising.
Well some newer projects in Chrome/Chromium are written in Rust so for what it's worth there is some effort.
I believe just yesterday the security team published a document which recommended avoiding unsafe languages for safety critical code: https://chromium.googlesource.com/chromium/src/+/master/docs...
But apologies perhaps I confused Chromium for Chromium OS: https://chromium.googlesource.com/chromiumos/docs/+/master/r...
Rust is listed a little higher in that link in the section about avoiding unsafe implementation languages. Given that they list it as a counterexample of things to avoid I would assume that means it is good, but that is no sure thing.
[0]: http://huonw.github.io/blog/2016/04/memory-leaks-are-memory-...
C++ static analysis is helpful, but it is not memory safe. Modern C++ doesn't really help. In fact, in my opinion, modern C++ tends to be less memory safe than "classic" C++, because it adds all sorts of new fun ways to get use-after-free.
That's usually because the "low-hanging fruit" is mostly gone due to protections like stack canaries, CFI checks, address randomization, and sandboxing, which makes things like buffer overflows or jumping to shellcode more difficult.
I think modern C++ is much safer than legacy C++, not by disallowing the USE after free, but by giving you the tools to make sure that the FREE happens at an appropriate time. A lot of this is not necessarily a feature of the language itself, but of idioms the community seems to agree to ie CppCoreGuidelines. I'm thinking of
- never use the delete operator manually, prefer std::unique_ptr
- prefer single ownership over shared ownership
- prefer immutable over mutable state
- ...
I agree with you that compared to Rust, this places a lot of burden on code reviewers and is in no way perfect, but I wouldn't say it's going in the wrong direction, making the language less safe.
Additionally, it's not really shared ownership that causes problems; it's the fact that references (and pointers) make it possible to violate ownership semantics. References are used all the time in C++, and you can't use any libraries without them. It doesn't matter if data has a single owner if that owner is deleted and you still hold references to the data. In fact, shared ownership via shared_ptr is safer than unique_ptr, from a UAF point of view.
Shared ownership makes it much harder to reason about lifetimes, increasing the chance of mistakes.
> shared ownership via shared_ptr is safer than unique_ptr, from a UAF point of view.
Only if the dereferencing code holds the shared_ptr. It's also common to pass non-owning pointers to objects held by shared_ptr.
> When people use the delete operator manually and mess up, do they usually delete objects too early or too late?
As you pointed out, problems arise if objects are deleted too early or twice. Double free is common in C and can be exploited as well...
Well if it isn't getting any safer than the time-disproven technique of relying on human behaviour and there are automatically safer alternatives, then it is less safe than those alternatives.
Modern C++ is safer, but only if you can ensure everyone on the team never reaches for C style tricks, nor the libraries that you link against.
[0]: https://labs.portcullis.co.uk/blog/exploiting-inherited-file...
Additionally, that example doesn't seem to be a resource leak in the sense of a memory leak. The exact same problem occurs if the file description is purposefully used after the 'system' call (that is, it isn't being leaked by not being used again). That's an issue more with 'system'/'fork' implicitly inheriting file descriptors than a resource being leaked.
Also note that Rust has contained a mitigation for that issue for a long time now: https://github.com/rust-lang/rust/pull/24034
> - during the GSubprocess discussion, I originally held the opposite opinion, but eventually became convinced (by Colin) to see the inherit-by-default behaviour of exec() as nothing more than a questionable implementation detail of the underlying OS. Consequently, at the high level, GSubprocess provides an API that gives the caller direct control over what is inherited and what is not, and that's just the way that it should be.
> - this behaviour is not limited to GSubprocess. Closing all fds before calling exec() is a common practice in modern libraries and runtimes, and for good reason.
[0]: https://mail.gnome.org/archives/gtk-devel-list/2015-March/ms...
That's silly. The standard library of new systems programming languages should do the safe thing, not inherit all the mistakes of the OS that the OS can't fix due to backwards compatibility. If Unix were being designed today, I am certain O_CLOEXEC would have been the default. Besides, Rust's behavior matches what happens on Windows, and cross-platform consistency in the standard library is desirable.
In any case, what glib does matches what the Rust standard library does. The latter uses posix_spawn() directly in order to make sure no file descriptors are passed between parent and child. There is an API available to request file descriptor sharing explicitly.