https://android.googlesource.com/platform/system/bt/+/1d788d...
https://android.googlesource.com/platform/system/bt/+/c20f24...
https://android.googlesource.com/platform/system/bt/+/abc302...
Keeping code simple and without unnecessary abstraction is a far more valuable skill than $safe-language-trend-of-the-day.
How many people must use it? 1k? 10k? 100k?
It’s pointless to argue with someone who throws Rust into that category at this point because it means nothing. It’s a slight to allow them to feel ok, that eventually this language too will pass, and so it will be ignored.
Judging by the number of memory vulnerabilities found each year in mainstream operating systems (which are developed by some of the best programmers around), there aren't any people on the market with this skill. This is very likely because all programmers are human beings.
Manually managing memory isn't difficult, it has been proven to be practically impossible. I wouldn't care if it were Linus claiming otherwise, it's ignoring incredible amounts of evidence to the contrary and is much like flat-earther.
Learning Rust and with its concepts improved my C code. Even if Rust would vanish over night I wouldn't regret learning it.
That's a pretty silly thing to say.
Writing code that doesn't crash isn't the hardest thing about writing low-level code. Sure, it's a problem, even an important problem, but there's a ton of other knowledge that no JS developer would have. Unless by "write" you mean write 2 lines per day with lots of searching in-between that has to be thrown away in the end.
Good programmers are expensive. The notion that better tools are going to change that is naive.
Rust is good. Use it for things. But the idea that it can let people who don't know what they're doing write secure code is dangerous. For example, what does Rust do about Spectre? Does your junior-level JavaScript programmer know how to address that? What about other timing attacks, or knowing which crypto to use in which context?
People still have to know what they're doing.
I've used Rust for a while, and this isn't really true. At the lowest level you still have to build good abstractions with judicious use of `unsafe`. It also comes across as incredibly hostile, you're not doing Rust any favors with this.
Can't see how that can be. Only a small minority of programmers can code low level systems. Only those that truly enjoy it, go through the pains necessary to have adequate grasp of it.
LOL, I wish. I've been told I was going to be replaced every 5 years for the last 20 years of my career. I fucking wish they did so I could finally retire but I keep being given money and cool problems so I stay waiting for this fangled replacement who will come and take my job.
I guess you are talking about the first commit I linked. The problem here seems to be that some events of the kind HCI_READ_RMT_EXT_FEATURES_COMP_EVT can be shorter than the assumed 13 bytes. The code contains no check for that and if the events are shorter, it would read data from after the allocation. It would use that data to index inside arrays, etc.
Now, if you just allocate a buffer of 256 entries but don't do anything else, it wouldn't read data from outside the allocation, yes, but it would still read uninitialized data, as nothing would be written after the end of the valid data. That uninitialized data could e.g. come from previous freed allocations. This would hardly be an improvement. You'd have to allocate and zero-initialize it, and then you'd still have the problem whether zero is invalid data or part of the allocation... Even if code would figure that out, it would be extremely smelly code and I'd never merge it in any projects I maintain.
The approach done by the patch to just check the length is much much better. The length is sent as part of the event.
> Keeping code simple and without unnecessary abstraction is a far more valuable skill than $safe-language-trend-of-the-day.
This code almost directly maps to the bluetooth host controller interface which is part of the published Bluetooth standard. So you can't change the core concepts of it. There are a few abstraction layers which copy the data for some reason from a new/delete managed hidl_vec to a malloc/free managed array (check hciEventReceived function in hci/src/hci_layer_android.cc). Yes, I'd say that some of those layers are indeed unnecessary. But those abstraction layers are not where the vulnerability occurs. It occurs in the code that parses the message, and the bug is that the code does not check the length of the input data. This is a classic bug that can occur in C/C++ codebases.
Safe Rust prevents OOB writes/reads by performing bounds checks when you index into a slice.
The issue with languages like C is that verifying that code is safe is extremely hard, even harder than writing it in the first place. This codebase seems to have not been written by Google but by Broadcom, so Google would have to verify whether what Broadcom wrote is actually safe. With Rust, such verification is easy. If your code makes little use of unsafe, and most code doesn't actually have to, it's easy to verify its safety (at least for the classes of bugs that Rust eliminates). Due to the strong typing, other types of bugs are made harder to write as well.
That said, regarding:
> safe-language-trend-of-the-day.
I agree that rust advocacy can sometimes be a bit misguided and over-enthusiastic - however how often is an out of bounds write not a bug (or a too clever by far hack)?
We've had pretty efficient ways to deal with this in c like languages for a long time (eg Pascal, Ada).
(c-like in the sense of being relatively low-overhead, close to the hardware wrt memory layout etc).
This will take a couple of decades, but it's a worthwhile effort.
My point is, of course Rust is a memory safe language, and of course it would theoretically prevent overflow exploits, but throwing in "you should've used Rust" when this news is announced isn't helping anything. I am certain that Android devs are at least aware of Rust and it's benefits.
There is still not a single Android ROM component that's written in Rust. Cuttlefish uses crosvm which is Rust based, but it's a VM for Android testing rather than a ROM component. So they aren't even ready yet to experiment with shipping small components in Rust. Same goes for Chrome btw, it currently has a "no Rust allowed" policy, which is IMO very sad.
So yeah I think it's worthwhile to talk about why AOSP doesn't have Rust components yet, especially as patching is sadly not available (yet) for most deployed devices. Large fleets of devices will have the bug for eternity. Therefore, prevention of vulnerabilities becomes even more important, which Rust helps doing. Your program won't be free of them, but as I pointed out above, these bluetooth vulns fall into the class that safe Rust eliminates.
But I think this vulnerability serves as an important lesson about which language to choose for new projects in the embedded area. Thus I'm very glad that Google uses Rust for its new OpenSK security key firmware. I hope that future versions of Android will adopt Rust, at least in newly written components. Some Google developed Android related projects are already using Rust, like Cuttlefish which uses crosvm.
Yes, that's not wrong, but a sane (ptr, len) "slice"/"buffer" type would have prevented this in any language, not just rust. These things happen not because C and C++ lack sophisticated ownership semantics, but because without such a type, passing a pointer and hoping the buffer is always big enough is just easier than doing the right thing.
If this was something funky like a cross-thread race-condition dangling-pointer double-free, you'd have a great point. Only Rust's unique safety model can prevent that. But with things like this, as much as I love Rust and it's community, I sometimes feel like many rust fans are much more interested in being smug than making real-world progress towards safer software today.
We've spent decades pushing the limits of security improvements we can get through asking people to please try harder and do better with C, but we still see a high rate of high-impact errors like this.
Rust's safety model isn't the only valuable thing about Rust. Another big valuable part of Rust is that instead of giving the programmer a box of unsafe tools and a post-it reminding them to be careful, Rust provides sane, safe default tools that have been built based on what we've learned from the past several decades.
The argument isn't "Only Rust can save you", but that Rust is a good choice that both meets the same performance requirements, and avoids these problems by default.
If you've got a better solution to persuade C and C++ developers to consistently and reliably always wrap their use of pointers from other APIs into (ptr,len) buffer types, I'd love to hear it!
With comments like this, I sometimes feel like many developers are much more interested in smugly dismissing a group that's made significant real-world progress in making it easy to do the right thing than they are in actually helping real developers to reliably make safer software today.