Two Android Engineers Explain How They Extended Rust In Android's Firmware (theregister.com) 62
The Register reports that Google "recently rewrote the firmware for protected virtual machines in its Android Virtualization Framework using the Rust programming language." And they add that Google "wants you to do the same, assuming you deal with firmware."
A post on Google's security blog by Android engineers Ivan Lozano and Dominik Maier promises to show "how to gradually introduce Rust into your existing firmware," adding "You'll see how easy it is to boost security with drop-in Rust replacements, and we'll even demonstrate how the Rust toolchain can handle specialized bare-metal targets."
This prompts the Register to quip that easy "is not a term commonly heard with regard to a programming language known for its steep learning curve." Citing the lack of high-level security mechanisms in firmware, which is often written in memory-unsafe languages such as C or C++, Lozano and Maier argue that Rust provides a way to avoid the memory safety bugs like buffer overflows and use-after-free that account for the majority of significant vulnerabilities in large codebases. "Rust provides a memory-safe alternative to C and C++ with comparable performance and code size," they note. "Additionally it supports interoperability with C with no overhead."
At one point the blog post explains that "You can replace existing C functionality by writing a thin Rust shim that translates between an existing Rust API and the C API the codebase expects." But their ultimate motivation is greater security. "Android's use of safe-by-design principles drives our adoption of memory-safe languages like Rust, making exploitation of the OS increasingly difficult with every release."
And the Register also got this quote from Lars Bergstrom, Google's director of engineering for Android Programming Languages (and chair of the Rust Foundation's board of directors). "At Google, we're increasing Rust's use across Android, Chromium, and more to reduce memory safety vulnerabilities. We're dedicated to collaborating with the Rust ecosystem to drive its adoption and provide developers with the resources and training they need to succeed.
"This work on bringing Rust to embedded and firmware addresses another critical part of the stack."
A post on Google's security blog by Android engineers Ivan Lozano and Dominik Maier promises to show "how to gradually introduce Rust into your existing firmware," adding "You'll see how easy it is to boost security with drop-in Rust replacements, and we'll even demonstrate how the Rust toolchain can handle specialized bare-metal targets."
This prompts the Register to quip that easy "is not a term commonly heard with regard to a programming language known for its steep learning curve." Citing the lack of high-level security mechanisms in firmware, which is often written in memory-unsafe languages such as C or C++, Lozano and Maier argue that Rust provides a way to avoid the memory safety bugs like buffer overflows and use-after-free that account for the majority of significant vulnerabilities in large codebases. "Rust provides a memory-safe alternative to C and C++ with comparable performance and code size," they note. "Additionally it supports interoperability with C with no overhead."
At one point the blog post explains that "You can replace existing C functionality by writing a thin Rust shim that translates between an existing Rust API and the C API the codebase expects." But their ultimate motivation is greater security. "Android's use of safe-by-design principles drives our adoption of memory-safe languages like Rust, making exploitation of the OS increasingly difficult with every release."
And the Register also got this quote from Lars Bergstrom, Google's director of engineering for Android Programming Languages (and chair of the Rust Foundation's board of directors). "At Google, we're increasing Rust's use across Android, Chromium, and more to reduce memory safety vulnerabilities. We're dedicated to collaborating with the Rust ecosystem to drive its adoption and provide developers with the resources and training they need to succeed.
"This work on bringing Rust to embedded and firmware addresses another critical part of the stack."
But it's worth it (Score:4, Interesting)
This prompts the Register to quip that easy "is not a term commonly heard with regard to a programming language known for its steep learning curve."
Once you pass the learning curve, it may well be the easiest and most expressive language you'll ever use. And that's coming from somebody who used to do everything in dynamic scripting languages.
Re: (Score:2)
Re: (Score:2)
Political and Social more than tech (Score:1)
Speculating here that hiring people to work on large deep legacy C and C++ code bases is near impossible for most companies with few if any cheaper to pay, early career developers willing to take on a technology which would appear 'dead-end' on a resume.
Resume reviewer: Graduated 4 years ago, did C/C++ for 4 years, ..... let's skip this resume....
Alternate question for late-career developers: How much would they have to pay you per hour to work on 25 million lines of 20 year old C code? And how many months
Re:But it's worth it (Score:4, Interesting)
Re: (Score:3)
In what way is it expressive?
That's not easy to answer because expressiveness is always relative.
First and foremost, generally expressiveness refers to the way a language allows you to concisely model whatever it is you're trying to solve. Between the proc macros and rust's enums, it's actually a bit difficult to switch from rust to a supposedly easier language like golang. One of the biggest problems in my mind is not only does rust offer what are perhaps the most powerful enums and pattern matching of any language, but golang doesn't
Re:But it's worth it (Score:4, Insightful)
" And that's coming from somebody who used to do everything in dynamic scripting languages."
IOW you've no experience in developing in C or C++ which Rust is supposed to be an alternative for. Got it. I might as well say how wonderful Ford cars after driving one after having only ever ridden scooters all my life.
Re: (Score:1)
IOW you've no experience in developing in C or C++
This is inaccurate. I've done a bit of C and C++. C is a bit brittle and has basically no guardrails, but it's overall not bad at what it tries to be. It's hard to call C++ one single language. More like several generations of similar languages in one, and nobody can read anybody else's code. If you want a succinct description of C++, see:
https://drewdevault.com/2019/0... [drewdevault.com]
which Rust is supposed to be an alternative for.
Not supposed to be, just is.
Re: (Score:3)
" I've done a bit of C and C++"
A true expert then.
"Not supposed to be, just is."
Maybe for C, for C++ no chance with Rusts half arsed object model.
Re: But it's worth it (Score:1)
C++ can keep its fragile base classes all to itself.
Re: But it's worth it (Score:1)
I thought AI was going to solve this. Why learn a new language when AI can fix your bugs?
Correction (Score:5, Insightful)
C and C++ are not "memory unsafe."
Your code is memory unsafe. Not the language.
C is a portable assembler. It is no more or less "unsafe" than machine language. It is neither defective nor is it inadequate. It is simply a tool. It is up to the developer to make it safe.
Re: (Score:2, Insightful)
Re:Correction (Score:5, Insightful)
Yes, this tedious meme usually comes either from Rust shills or people who've only ever written in hand holding scripting languages. C/C++ intentionally gives you full control over memory access so blaming them for your program having memory bugs is like blaming the gun when you pointed it at your foot and pulled the trigger.
Re:Correction (Score:5, Insightful)
The gun allows you to shoot wherever you like just like C allows you to do whatever you like with memory. If you're not capable then don't use it. I'm tired of the whinging about C/C++ by 2nd rate devs who need a hand holding language to save them from their own mistakes.
Re: (Score:2, Troll)
The gun allows you to shoot wherever you like just like C allows you to do whatever you like with memory. If you're not capable then don't use it. I'm tired of the whinging about C/C++ by 2nd rate devs who need a hand holding language to save them from their own mistakes.
If you're directly comparing memory management of C and C++ to anything else, then you really aren't in a position to understand why Rust gives you the same level of control.
In C, if you want to allocate anything on the heap dynamically, you need to expressly malloc it, and when you're done, expressly free it.
In C++, this is all done implicitly. If you create a vec, it mallocs for you, resizes it for you when needed, etc, and when it goes out of scope, it often (but not always) free's it for you. But it doe
Re: (Score:2, Insightful)
" In Rust, unless it's Copy (which is reserved for things that are trivial to copy,) then it's a move with no allocations."
Thats a really cretinous design decision for reasons you probably wouldn't understand.
Also congrats on not understanding low level programming. Probably best you stick to using Rust.
Re: Correction (Score:2)
Thats a really cretinous design decision for reasons you probably wouldn't understand.
You'd think, because C++ moves are very cretinous indeed. Fortunately, a move in rust is not the same as a move in C++. A move in rust means at a high level that it's actually moved, and therefore no longer in scope. C++ is more the "let's copy and then pretend it's no longer in scope so that later you can do invalid operations with it" type of junk that C++ developers know and love. Rust moves are also not always a deep copy and destruct either, rather the compiler can optimize it as a stack pointer, or yo
Re: (Score:2)
"The gun allows you to shoot wherever you like just like C allows you to do whatever you like with memory. If you're not capable then don't use it."
The ability of the gun to shoot where ever you like is at best useless if you have no need to shoot anywhere. If you don't need the dangerous facility don't use the tool that is noted for providing the dangerous facility.
"I'm tired of the whinging about C/C++ by 2nd rate devs who need a hand holding language to save them from their own mistakes."
I'm tired of the
Re: Correction (Score:1)
I'm tired of the whinging about selecting the right tool by people who think it's reasonable to pound nails with a gun.
C++ developers tend to view themselves as being the only gun that doesn't need a safety and never misses. Then they wonder why nobody wants C++ in their kernel.
Re:Correction (Score:4, Insightful)
One is designed to be whatever you can imagine, the other is designed to keep you in a bubble.
Re: (Score:2)
Absolutely right, which is why on a typical Slasdot Weekend you'll get downvoted.
That gun analogy is great. You don't want that gun going off accidentally and shooting yourself in the foot!!!
So... the gun must make sure you really really really want to fire that gun. WHO KNOWS if that foot is a real foot, your foot, a foot that an alien monster has invaded (or you took heroin) and must be shot. It must verify your intentions. Before it can shoot.
And one day you're sleeping and a burglar comes a prowling
Re: (Score:3)
Re: (Score:2)
No, it's more like blaming the gun when you chose to pull the trigger in a crowd of people who never asked for you to be aiming the gun at them in the first place. The point of the analogy obviously being that you're not necessarily the person that suffers the consequences of your programming decisions.
And to be clear Rust doesn't stop you doing anything you like with memory, but it is safe by default and provides safe programming constructs. If you have a reason to do something with memory access you can d
So codier than thou (Score:2)
> Rust shills or people who've only ever written in hand holding scripting languages.
Those are two completely different parts of the coding spectrum IMO:
* Rust forces structure, typing, a lot of compilation checks
* Scripting languages generally do duck typing and just let you do what you want - though obviously internals are abstracted away.
I personally like to dabble in Swift which has very strict typing, mutatability, etc - which achieve the following:
* Great code completion
* Effecient compile time opt
Re: Correction (Score:2)
Re: (Score:2, Interesting)
Your code is memory unsafe. Not the language.
That's absurdly one dimensional thinking. The reality is there are multiple places in a chain where safety can come in. The code is one, the language is the other. It's like saying "cars aren't unsafe, your driving is unsafe" while ignoring the massive difference between say a car from the 1960s getting into a collision vs a car from 2020.
The concept of memory safety specifically refers to the language, not the programmer or the code, regardless of how you want to ignore the definition. There absolutely is
no objection to claim made (Score:1)
I'm perfectly willing to accept that Rust is memory safe and even a better language to write kernels and drivers in. I'm willing to accept that Rust is a better language than to write drivers in. Good that Google is finding success, we're all better off if phones are better secured.
The problem is, Rust programmers are drama queens. Have you seen the kerfuffle that happened recently in the Linux kernel? Basically, one of the main Rust programmers stormed off in a hissy fit because he was tired of dealing wit
Rust is frequently not upward compatible (Score:4, Informative)
Rust 1.74 dropped support for macOS 10.11
Rust 1.78 dropped support for Windows 7 and 8.1, along with Server 2012 R2 which is still supported (with ESU patches).
The Windows 7, 8.1 and Server 2012 support can be realised another way but that is pretty much unsupported and untested.
People do write new software releases for old OS levels and that is coming to mean they can't use Rust (or have to stay on older levels, the preferred solution).
Re: (Score:3)
You're complaining about legacy platforms from two of the most evil multinational corporations to come out of the west coast of the United States?
In the really real world, sometimes programmers have to write code even for bad, wrong, and evil operating systems.
Re: (Score:2)
They can use the older Rust versions to do that then. I would be unshocked if I took /bin/ls from a today release and found it didn't run on 1990's slackware.
Re: (Score:2)
They can use the older Rust versions to do that then.
They can, but they probably won't. They shouldn't have to, either. There are other solutions that won't require them to, and they will more likely favor those other solutions instead, and that makes more sense for most people.
Re: (Score:3)
Every open source project has a finite capacity to support platforms. I expect Rust would be delighted for volunteers stepped forward to support obsolete platforms, or emerging ones. But in the absence of volunteers, what do you expect them to do?
I might add that some of these support issues might be the result of capacity / volunteer issues in LLVM or dependency changes, e.g. Microsoft C runtime support end of lifing out of older operating systems.
Re: (Score:2)
Looks like it is just tier-3 support now. Not dropped entirely.
Re: (Score:2)
It's not really true, though. All they did was move windows 7 and 8 into a different target from the standard "win" targets, so that they can give lower guarantees to windows 7 and 8.
The tier 1 support requires that they they run, compile on and test on that platform; it is going to get harder and harder to find a continuous integration system for operating systems like WIndows 7 and 8 which are not supported by MIcrosoft any longer. People who are using those OSes are either very specialist users or totall
Re: (Score:2)
Unsupported OS platforms are unsupported? No fucking way!
Here's a hint: If you are developing software actively enough for it to be a concern to target old systems, then you can help your customers upgrade to a supported OS rather than supporting their bad security and business practices. And if you're not able to do so, then no one cares if Rust doesn't support the OS since you're not supporting your customer.
The learning curve is worse from C / C++ (Score:1, Flamebait)
Rust is mostly a pretty straightforward language. But preconceptions can make it feel hard.
C/C++ programmers have to unlearn bad habits that they got away with in those languages and start doing things the Rust way. They'll be banging their heads on the walls about the fact that borrowing is stricter than pointers/references (for good reason), that thread safety is enforced and non negotiable, that NULL/nullptr is not a thing in normal programming, etc. The compiler will kick their asses umpteen different w
Re: (Score:3)
Software is never done, the bugs keep coming up long after the programmer has walked away.
Re: (Score:2)
Who says you have to rewrite everything? If you have something in those languages that works, why change it? But if you're writing something new, you should consider Rust. That is assuming you don't like bugs caused by the language itself. Half of CVEs in C projects are things like null pointers, double frees, buffer under/overflows caused by the language or traps in it.
I also consider it laughable, condescending and arrogant to say these "rank amateurs" shouldn't be using C/C++. Here on planet Earth, softw
Errr what? (Score:2)
Re: (Score:2)
rust is just like its name sake (Score:3)
Re: (Score:2, Interesting)
Your analogy is a good one. It demonstrates how some common ignorant thinking can't comprehend something they don't see the obvious applications for.
Rust is not insidious - it is often a forced desired chemical reaction.
Rust is not destructive - it is just a chemical reaction, used in many applications some quite critical to your way of life.
Rust is not undesirable - in fact there enough of a desire for it that there are companies out there who manufacture rust for you, it's used for water treatment, pigmen
Re: (Score:2)
False. Rust is frequently created on purpose rather than protected against. In fact rust is nothing more than an oxidation. The process of oxidation for many materials forms a protective layer.
Re: (Score:2)
Re: (Score:2)
The point of view of an industrial chemist is not the same as joe average. As you well know.
Welcome to my point. The point of view of some random programmer is not the same as that of someone using the rust programming language for a specific intended purpose.
The average joe thinks all rust is bad. Clearly the average programmer does too. Yet both actual rust (iron oxide) and the programming language have some very specific and desirable purposes.
Apple is the last big hold out (Score:3)
Apple is the last big hold out for now, but they just need to get their invented here language ready. Swift needs to get a little more Rust-like before it's truly useful as memory safe system programming language, but it's getting there.
Soon C/C++ will be deprecated for system programming, it will be for legacy and games.
Re:Apple is the last big hold out (Score:4, Insightful)
Memory safe (Score:3, Interesting)
There are many ways to make memory-safe code. In simple terms instead of
pointer = system_call(allocate memory, size requested)
you add in some things like keeping track...of those things... that you originally figured the system would keep track of... like
array[allocations] add element (pointer, size, status)
pointer= system_call(allocate memory, size requested)
array[allocations] update pointer, size, and set status "allocated"
If you're using Rust it can do it all by itself, more like a
used to be malloc() but now we have vec!. Six of one, half dozen of the other, but now two systems are doing the work, and we've abstracted it so the coder doesn't care, and the reader who comes along later doesn't care, and IN TIME this code will be 50% inefficient and nobody will remember, know, or care.
Rust is free. The cost of using it is not.
Want to sell a new "language" (tool to create code)? Make the tool create BETTER code that is MORE EFFICIENT. Anyone can write a 20 line routine to make one system call "safer" and hide it in pseudocode, macros, and pretending vectors are magically better than slabs. Whatevz.
Can't drop it in if the maintainers (Score:3)