Nice to see this.
Sadly the Android team, while taking this safety steps, it keeps using unsafe C userspace for NDK APIs.
Security is as good as the weakest link.
Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
51–60 of 393 posts
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#52Wait , so can rust generally be replace C++ code in most projects ? Has anyone here had success with a partial to Rust migration.
I think the answer is yes. Most C++ projects would be better served by Rust. However there are many caveats:
- I think that C++ devs are still more numerous than Rust devs.
- There are many excellent C++ libraries that don't yet have great Rust bindings. Furthermore it is unlikely that template-heavy libraries will ever be easy to use from Rust.
- C++ is supported on more platforms.
- C++ is more powerful. (Particularly templates). You rarely need more power than what is available in Rust but if for whatever reason your project would really benefit from heavy meta-programming C++ will be better. (I think this case is rare). Rust is also catching up, but the language development, especially around generics is fairly slow (which is probably a good thing)
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#53Fun fact: Google's from-scratch Bluetooth stack for Fuchsia has been written primarily written in Rust since it's conception for a few years now.
https://fuchsia.googlesource.com/fuchsia/+/master/src/connec...
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#54It seems like Rust is really catching on. To be honest, I didn't pay much attention to it for a while -- it felt like it might have simply been that day's "flavor of the day", destined to sink once then next flavor became popular. Now, there's a real problem to be solved. But I thought a simpler approach would be needed (e.g., Zig or something like it). I guess that may still happen, but seems more and more like Rust…
I suspect that Zig will still end up eclipsing Rust - not because it's a "more powerful" language, but because it's much easier to learn. Lower barriers of entry seem to matter more than mere "power" - see Common Lisp's multi-decade feature lead being ignored, and Python leapfrogging other more capable languages (Common Lisp) or equally capable ones that came first (Ruby) due to ease-of-use.
I think Zig could end up being much more popular for domains where Rust's safety and correctness features are less important. Something like a bluetooth stack is exactly where Rust is ideal though imho. Some for crypto libs.
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#55Earlier quoted context omitted.
> fighting Broadcom's old, god-awful bluetooth code Correction: god-awful host side bluetooth code. There is still the bluetooth firmware residing on the BCMxxx chip (or Qualcomm chip) - >1MB of god-awfulerer closed-source code, half of it is in ROM (with limited number of available patch slots), full of bugs. You can see it crash from time to time in the kernel debug logs (and auto-restart itself)
Do you have any more info about ROM patch slots? I have never heard of this before. I assume this is a small amount of r/w memory that is somehow overlaid over specific locations in the ROM?
Correct. It's a small table of:
address1, 4 bytes overlay data
address2, 4 bytes overlay data
etc
By the time the chip is 2-3 years in the market and still getting firmware updates, ~98% of them are used by existing firmware, so there are only 5-10 free entries by the time the chip is considered "obsolete".
Case in point: the Broadcom/Cypress BCM43455 chip on the raspberry pi is almost out of patch entries. Broadcom have switched to their usual tactic of stalling for years on known, reproducible bug reports.
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#56The Android IPC driver (binder) is also being re-written in rust. It takes advantage of the upcoming kernel driver rust support in Linux. It is an obvious choice for a memory safe re-write since all android processes (including sandboxed ones) have access to binder
Now we need safer NDK APIs, even C++ bindings would be better than nothing.
Additionally exposing some NDK only APIs to ART would also be welcomed from security point of view.
And since we are at it, support Rust on the NDK LLVM toolchain.
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#57Wow, this is great! Not just the memory safety aspect of it, but also that it's written with testability in mind.
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#58Is this because of memory bugs\vulnerabilities that target the stack or just because it was too old and junky?
Dunno what motivated them internally, but the bluetooth vulns that made news in Feb 2020 would have been prevented by safe Rust. See my comment from back then: https://news.ycombinator.com/item?id=22265572
According to dtolnay, there are only 4 lines of unsafe rust in the Rust component. It's a bit small though at the current moment in time, with 4 thousand lines. Most of the code is still C++. Note that it's "with Rust" in the headline, not "in Rust".
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#59Earlier quoted context omitted.
It is very hard to answer such a general question with a definitive answer, but Rust does want to be viable for the same sorts of things in which C++ is viable. As always, your mileage may vary.
So to clear I can't just plop a Rust class into a C++ project.
You can't. However there are options.
- Rust has strong support for C ABI much like C++. So you can communicate between Rust and C++ via a C ABI.
- There are projects like https://cxx.rs/ to provide higher-level bindings between the two languages.
However I suspect that template-heavy/generic-heavy code will never be well supported. This is usually not an issue for the types of things that we are trying to bind.
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#60Wait , so can rust generally be replace C++ code in most projects ? Has anyone here had success with a partial to Rust migration.
>Wait , so can rust generally be replace C++ code in most projects ?
In principle Rust could replace every line of C++ code in the world. The questions of how often it would be a good idea to do so, practical to do so, is harder to say. It is promising that this bluetooth stack only needed 4 lines of unsafe though!
Since the interop is zero overhead doing piecewise migrations is certainly possible, as has been going on with firefox, and curl and discussions of doing it in linux as well. You do complicate your build system and there is a non trivial amount of work to stitch the two languages together.