Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming Android Google

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."
This discussion has been archived. No new comments can be posted.

Two Android Engineers Explain How They Extended Rust In Android's Firmware

Comments Filter:
  • But it's worth it (Score:4, Interesting)

    by ArmoredDragon ( 3450605 ) on Sunday September 08, 2024 @01:20AM (#64771534)

    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.

    • easier than scheme?
      • ...or more expressive?
        • 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)

      by phantomfive ( 622387 ) on Sunday September 08, 2024 @02:47AM (#64771582) Journal
      In what way is it expressive?
      • 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

    • by Viol8 ( 599362 ) on Sunday September 08, 2024 @02:49AM (#64771588) Homepage

      " 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.

      • 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.

    • I thought AI was going to solve this. Why learn a new language when AI can fix your bugs?

  • Correction (Score:5, Insightful)

    by The Cat ( 19816 ) on Sunday September 08, 2024 @01:42AM (#64771548)

    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)

      by phantomfive ( 622387 )
      Actually if you use a different string library and a memory management library, most of the security problems go away automatically.
    • Re:Correction (Score:5, Insightful)

      by Viol8 ( 599362 ) on Sunday September 08, 2024 @02:52AM (#64771592) Homepage

      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.

      • by gavron ( 1300111 )

        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

      • Sadly, those who need the hand-holding will never admit it. So just like the idiots holding a smoking gun and missing a foot will blame the gun manufacturer or the state for not protecting them from themselves, so too will the Rust shills blame the language for their mistakes that it executes very carefully.
      • by DrXym ( 126579 )

        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

      • > 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

    • It's more complicated than that, of course. Everyone writes wrong code. If your tests pass the first time, you're in the wrong client. (If you don't have tests, you are foolish.) Compile time errors are more useful than runtime errors. This is well known and widely accepted. What is termed "memory safety" is really just a trick for catching another class of runtime error at compile time.
    • Re: (Score:2, Interesting)

      by thegarbz ( 1787294 )

      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

    • by Anonymous Coward

      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

  • by Vlad_the_Inhaler ( 32958 ) on Sunday September 08, 2024 @04:08AM (#64771626)

    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).

    • by DrXym ( 126579 )

      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.

    • Looks like it is just tier-3 support now. Not dropped entirely.

    • 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

    • 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.

  • 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

  • Replacing the lower layers with Rust is fine, but if you are keeping the user-facing C API, that's still a problem.
  • by ClueHammer ( 6261830 ) on Sunday September 08, 2024 @07:34AM (#64771738)
    insidious, destructive and undesirable.
    • Re: (Score:2, Interesting)

      by thegarbz ( 1787294 )

      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

      • The point of view of an industrial chemist is not the same as joe average. As you well know.
        • 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.

  • by Pinky's Brain ( 1158667 ) on Sunday September 08, 2024 @08:59AM (#64771844)

    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.

  • Memory safe (Score:3, Interesting)

    by gavron ( 1300111 ) on Sunday September 08, 2024 @10:25AM (#64771976)

    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.

  • by Fly Swatter ( 30498 ) on Sunday September 08, 2024 @12:21PM (#64772136) Homepage
    are expected to manage your rusty shims. Wasn't there just an article about this for the Linux kernel?

"It's like deja vu all over again." -- Yogi Berra

Working...