Keeping code simple and without unnecessary abstraction is a far more valuable skill than $safe-language-trend-of-the-day.
Learning Rust and with its concepts improved my C code. Even if Rust would vanish over night I wouldn't regret learning it.
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.
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.
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).
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.