If I understand correctly, the memory safety in Rust comes primarily from static analysis mandated by the standard (outside of explicitly specified "unsafe blocks"). So if there is a memory allocation bug in a runtime library, no amount of safety built into the language is going to help right? After all, in the end the compiled code is still just pointers and offsets (with all the usual lack of safety guarantees).
After reportedly dragging its feet, BlackBerry admits, yes, QNX in cars, equipment suffers from BadAlloc bug
BlackBerry this week issued a critical security advisory for past versions of its QNX Real Time Operating System (RTOS), used in more than 175m cars, medical equipment, and industrial systems. BlackBerry QNX Software Development Platform (SDP) version 6.5.0SP1 and earlier, QNX OS for Medical 1.1 and earlier, and QNX OS for …
COMMENTS
-
-
Thursday 19th August 2021 02:49 GMT diodesign
Rust
I just knew if I left the reference to Rust in, we'd get dinged on it. I've just decided to take that sentence out rather than argue at length over it. We wrote at the end, regarding the BadAlloc hole in QNX:
"Such bugs explain why the Rust programming language, capable of memory-safety and type-safety, has become popular in recent years at companies like AWS, Google, and Microsoft."
Would Rust have prevented this specific bug? Maybe, depending on how it was used. You could use Rust's checked math operations that catch overflows, if you remember to use them; debug mode has them on by default. If the overflow is in a separate C lib, you're out of luck.
Is it a good idea to use Rust to avoid similar memory bugs - like what Google, AWS, and others are doing - yes. We mentioned Rust in a general sense because at least some devs look at bugs like BadAlloc, think, 'there but for the grace of God, go I' and opt to use Rust to minimize similar, related flaws to improve the quality of their shipped code.
C.
-
Thursday 19th August 2021 03:25 GMT runt row raggy
Re: Rust
rust isn't a panacea.
in my recent professional experience, the code that has has the most catastrophic bugs leaving core dumps and deleted databases has been rust. sure, this is an anecdote but my point is pointing at one small class of bugs that rust does solve and blithely generalizing chanting web scale, er, i mean rust at any class of bugs you can think of isn't correct.
i think rust brings some great safety that other languages haven't brought before, but saying it's a (memory) "safe" language and implying that all rust is safe to run in the general sense is linguistic substitution.
-
-
-
Thursday 19th August 2021 10:33 GMT -tim
This bug is everywhere else too
QNX appear to use the same calloc as many GNU projects and the same bug has been in MS products since they learned to love C. calloc has always been odd when called with out small sizes that are nice powers of two since the function might just try to guess how things are aligned. A calloc(10,5) might assume that 10 items need to be 8 byte aligned (like large floating point numbers on a number of older architectures) and allocate 80 bytes compared to the 50 that many programmers would expect. It is another C function that was useful in its day and now shouldn't be used. Does calloc(3689348815, 5000000000) return a null on your system (assuming you can malloc 1.3g)?
-
Thursday 19th August 2021 11:03 GMT MacroRodent
Re: This bug is everywhere else too
A calloc that tries to make assumptions about alignment based on the inputs is just an invalid implementation. The C standard says "The calloc function allocates space for an array of nmemb objects, each of whose size is size. The space is initialized to all bits zero." It cannot assume the size is not really size, but something larger. Typically the second parameter is sizeof(something), and if "something" has alignment requirements in an array, sizeof already takes care of rounding up.
All implementations I have seen just multiply the numbers together and call malloc with them (or call the same internal function malloc calls). The only gotcha is if the implementer does not realize the multiplication can overflow and wrap to something less than either size parameter. Sadly, that is how many callocs are...
-
-
Thursday 19th August 2021 12:13 GMT Captain Scarlet
2012 and earlier
So they are never getting updated by the manufacturer, never was able to get Ford to check for firmware updates for my 13 plates Fiesta's system which likes to throw wobblies when the car is off and lose active settings even know USA could download firmware to a usb stick themselves.
-
Thursday 19th August 2021 13:12 GMT sitta_europea
I've worked with instrumentation, computers, computer-controlled machinery and networks - designing, building, using, maintaining, protecting and (lately) defending the bloomin' things - for more than forty years in all sorts of settings.
I know what they're good, and what (and where) they're not so good. I know what the risks are.
In my car (and worse - on my motorcycles, three of which can comfortably exceed twice the highest speed limit on our public roads, and one of which can on a good day exceed three times that limit) I am going to be in situations which, if something goes seriously wrong with the vehicle, will be at least very seriously embarrassing and, in the case of the faster motorcycles, quite likely fatal to the driver.
The car and the motorcycles are all around twenty years old.
I can live with the electronics, but I really do NOT want computers in them, thank you very much, and that is *why* they're all around twenty years old.
-
Thursday 19th August 2021 15:31 GMT sev.monster
Even 20 years ago, manufacturers were already using computers for fuel injection, timing, dual-clutch transmissions, lights, locks, and more. In fact ECMs were standard in most higher-end cars by the 70's and most cars in general by the 80's, at least here in the States. Of course, things like power locks and windows would not become more common until later since they were a "luxury feature" for a time.
Might want to check your manuals and confirm what ECUs your automobes actually contain, I'm sure you'd be surprised.
-
-
Thursday 26th August 2021 14:42 GMT sev.monster
Many of them likely didn't have microprocessors, or at least didn't utilize a complex instruction set, so that's likely :)
My point was just that OP should have quantified what kind of vehicle-bound computer he wasn't fond of. I assume I would get an agreement with the statement that infotainment, wireless connectivity, and other such gubbins have no place in a car, but that critical low-level stuff like timing control modules (and similar modules that handle and are only able to handle one specific task) are good.
-
-
-
-
-
Thursday 19th August 2021 18:57 GMT Paul Crawford
I normally use calloc() due to the zeroing of memory, so any use-before-initialisation has a repeatable fail.
However, to me it seems the issue really comes down to a lack of input sanitization if some external entity can fool you application in to a integer-fault situation.
If you did malloc(size*num) I guess you have the same problem unless 64-bit and you are happy for the system to grind to a halt as it allocates a brazillion bytes of memory and the swap kicks in...
-