67 ms·

Memory Safe Languages in Android 13

• luvs2code 4y ago
  So 80% of new native code is C/C++. Not surprising and of course Rust advocates will try to defend this as a win.
• cjg 4y ago
  Nice: "it’s likely that using Rust has already prevented hundreds of vulnerabilities from reaching production"
  • heather45879 4y ago
    The problem with Rust is the language syntax is ugly. It has a ton of visual noise. I think folks who write languages should have a typographer on their team because something like this: use std::collections::HashMap Is a typographic nightmare. While I understand “form follows function”, it’s tough to be excited to program in something like this.
    • Manishearth 4y ago
      I always say that if the strongest complaint people have about your language is syntax; you've already succeeded.
      • warkdarrior 4y ago
        You have an extra semicolon in your comment.
        • estebank 4y ago
          It's two statements, comments start with // :o)
          • IIsi50MHz 4y ago
            It's "clearly" wrapped in hidden delimiters so that the server regards it as a comment, though. (-;
      • blub 4y ago
        Syntax is one of the most important characteristics of language. It’s the difference that makes the difference between Rust-like and C++-like gibberish and poetry.
    • nequo 4y ago
      It seems unlikely that it's the double colons and the angle brackets that hold people back from migrating from C and C++ to Rust.
      • est31 4y ago
        Yeah Rust's syntax was inspired to be similar to C++.
      • kasabali 4y ago
        Where are the double colons and angle brackets in C?
        • lolinder 4y ago
          I think the point is more that both syntaxes are verbose. No one who is used to dealing with C type signatures is going to shrink at Rust's syntax.
    • lawn 4y ago
      I do agree that Rust sometimes has a lot of visual noise. But that use statement is not a good example of it, and if that's the biggest criticism then Rust is faring fantastically well.
      • IshKebab 4y ago
        Yeah I agree. Rust is a mildly ugly language, but not because of `use`! It's all the lifetime annotations, turbofish, and macros that make it ugly.
    • pcwalton 4y ago
      I was responsible for that decision, and I'm also a typographer (worked for years on vector rendering of fonts). :)
      • metaltyphoon 4y ago
        What reason were used to not use what C# has? It’s infinitely less noisy than Rust’s ::
        • pcwalton 4y ago
          Using a separate character for namespace resolution and field indexing allows you to have a module with the same name as a value.
          • metaltyphoon 4y ago
            Wouldn’t this be trivially solved by having namespaces follow the same PascalCase semantics as types? I.e use Std.String; …. let string = String(…);
            • dagenix 4y ago
              That's a different trade off. It's not a solution.
        • munificent 4y ago
          Technically, it is only 75% less noisy.
      • blub 4y ago
        Parent’s suggestion about typography is nonsense, the Rust project desperately needed somebody with skills in user experience and usability engineering. Now it’s too late.
      • arein3 4y ago
        Looks ugly imo Dot is way better
    • Mesopropithecus 4y ago
      As somebody who appreciates Lisp, I feel your pain. As somebody who also appreciates Rust, I'm curious, what is your baseline?
      • satvikpendem 4y ago
        Brainfuck, clearly /s
      • heather45879 4y ago
        Good design theory. https://www.doverbooks.co.uk/point-and-line-to-plane https://www.doverbooks.co.uk/point-and-line-to-plane Consider h::i::j::k versus h.i.j.k Two :’s is an extremely loud combination of visual elements compared to the subtle point. :: drags the eye away from the content and says “look at me oscillate” In addition, humans group similar visual elements together so a combination of anything::doesnt::matter::what::between::clumps it is impossible to escape the common pattern and the eye jumps between the ::’s. Therefore it takes double the cognitive load to read. What’s worse, the eye gets trapped within each :: because it’s a combination of four dots, which naturally creates an implied circular pattern which draws the viewer in further. Compare to something like: use HashMap from std.collections Or… more obviously the python import statements.
        • thaumasiotes 4y ago
          > Consider h::i::j::k versus h.i.j.k > Two :’s is an extremely loud combination of visual elements compared to the subtle point. :: drags the eye away from the content and says “look at me oscillate” > In addition, humans group similar visual elements together so a combination of anything::doesnt::matter::what::between::clumps it is impossible to escape the common pattern and the eye jumps between the ::’s. Therefore it takes double the cognitive load to read. It is true that the colons take up more space and your example looks good on HN. But this problem will be immediately solved by syntax coloring. It's just never going to come up.
          • heather45879 4y ago
            Syntax coloring would make it worse because coloring the :: independently of the surrounding tokens will make them stand out even more as a group. Rust is safe but it’s at least as ugly as C++.
• binkHN 4y ago
  From the bottom of the article: > As Android migrates away from C/C++ to Java/Kotlin/Rust, we expect the number of memory safety vulnerabilities to continue to fall. Here’s to a future where memory corruption bugs on Android are rare!
  • lzooz 4y ago
    How about speed from going from C/C++ to Java/Kotlin? Have they considered that even?
    • HideousKojima 4y ago
      I'm assuming that's why they have Rust in the mix there, for where performance is still critical.
    • insanitybit 4y ago
      See the section "Safety measures make memory-unsafe languages slow"
    • summerlight 4y ago
      It will most likely be C/C++ -> Rust for performance critical modules.
    • uluyol 4y ago
      Much of Android is written in Java/Kotlin. Transitions from the JVM to C/Rust and back are not going to be free due to extra wrappers and the inability to optimize across the boundary. So for some usecases Java will be faster. But anything CPU or memory intensive will probably be cheaper in Rust.
• thesuperbigfrog 4y ago
  "Migrating away from C/C++ is challenging, but we’re making progress. Rust use is growing in the Android platform, but that’s not the end of the story. To meet the goals of improving security, stability, and quality Android-wide, we need to be able to use Rust anywhere in the codebase that native code is required. We’re implementing userspace HALs in Rust. We’re adding support for Rust in Trusted Applications. We’ve migrated VM firmware in the Android Virtualization Framework to Rust. With support for Rust landing in Linux 6.1 we’re excited to bring memory-safety to the kernel, starting with kernel drivers." The push for Rust to replace C and C++ continues. This is confirmation of the NSA recommendation to discontinue using C and C++: https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI... If you do not know Rust, now is the time to learn: https://doc.rust-lang.org/book/ https://doc.rust-lang.org/book/ Here are some fun holiday-themed exercises to learn with: https://adventofcode.com/ https://adventofcode.com/ I plan on doing Advent of Code in Rust this year.
  • wiseowise 4y ago
    Actually now is the time to learn C++. Amount of leverage and money C++ developers will be able to utilize is enormous, given how much critical code is written in it.
    • thesuperbigfrog 4y ago
      >> Actually now is the time to learn C++. Amount of leverage and money C++ developers will be able to utilize is enormous, given how much critical code is written in it. The article states: "We continue to invest in tools to improve the safety of our C/C++. ... Vulnerabilities found using these tools contributed both to prevention of vulnerabilities in new code as well as vulnerabilities found in old code that are included in the above evaluation." "These are important tools, and critically important for our C/C++ code. However, these alone do not account for the large shift in vulnerabilities that we’re seeing, and other projects that have deployed these technologies have not seen a major shift in their vulnerability composition. We believe Android’s ongoing shift from memory-unsafe to memory-safe languages is a major factor." "our Rust code is proving to be significantly safer than pure C/C++ implementations." C++ is great if you do not have alternatives. If you can use Rust instead of C / C++, you should because of the greater safety it offers with similar performance characteristics.
• insanitybit 4y ago
  Glad to see robust work here. This strongly supports what should already be obvious, but sadly is not always understood; that memory safe languages are radically safer than memory unsafe languages. The impact is blatantly demonstrated here.
  • cyber_kinetist 4y ago
    Rust (despite the common understanding) is not a memory-safe language in its entirety. It is a language designed to have a strict division of safe/unsafe which makes it easier for developers to compartmentalize code to achieve memory-safety.
    • insanitybit 4y ago
      No language in use meets your definition of memory safe.
      • pclmulqdq 4y ago
        Ada seems to fit.
        • burntsushi 4y ago
          Ada has no "unsafe"? Ada has no ffi? Ada has no escape hatches or unchecked APIs whatsoever? Does it have any pragmas that can disable safe checking? Because if it does, it's not "entirely" memory safe.
          • thesuperbigfrog 4y ago
            Ada has "unchecked" operations: Unchecked Access (unsafe pointers): http://www.ada-auth.org/standards/22rm/html/RM-13-10.html#I5733 http://www.ada-auth.org/standards/22rm/html/RM-13-10.html#I5... Unchecked Deallocations ("free"): http://www.ada-auth.org/standards/22rm/html/RM-13-11-2.html#I5783 http://www.ada-auth.org/standards/22rm/html/RM-13-11-2.html#... Unchecked type conversions (unsafe casting): http://www.ada-auth.org/standards/22rm/html/RM-13-9.html#I5708 http://www.ada-auth.org/standards/22rm/html/RM-13-9.html#I57... Ada has FFI: C / C++: http://www.ada-auth.org/standards/22rm/html/RM-B-3.html http://www.ada-auth.org/standards/22rm/html/RM-B-3.html COBOL: http://www.ada-auth.org/standards/22rm/html/RM-B-4.html http://www.ada-auth.org/standards/22rm/html/RM-B-4.html Fortran: http://www.ada-auth.org/standards/22rm/html/RM-B-5.html http://www.ada-auth.org/standards/22rm/html/RM-B-5.html Ada has pragmas to both enable more security measures or relax security measures: http://www.ada-auth.org/standards/22rm/html/RM-L.html http://www.ada-auth.org/standards/22rm/html/RM-L.html Just like in unsafe Rust, sometimes in Ada you need to turn off some security features or tell the compiler "I know what I am doing for this part" when interfacing with some hardware or similar low-level stuff.
• Kukumber 4y ago
  Another failure for Kotlin Native, what a sad shitshow.. They were warned many years ago about ownership/concurrency/compile speed, they didn't listen at all A vision alone doesn't matter, you need skilled engineers and a dedicated team who understand what "taste" for great things is What could have been the Swift for android will end up just being the "java" alternative, i suspect they'll get rid of the JVM, or whatever the tech is, altogether and focus on Rust for whatever they plan next (maybe Fuschia), maybe there is still hope for Swift, we'll see
  • saagarjha 4y ago
    Kotlin is generally recommended for application development on Android.
    • Kukumber 4y ago
      I talk about Kotlin Native, not Kotlin
      • saagarjha 4y ago
        It doesn't make sense to use here. You have a perfectly cromulent JVM if you want to run Kotlin code already.
• onei 4y ago
  Not being aware of how vulnerabilities are detected and despite being a big fan of Rust, I wonder if there are other variables that drive down the ability to find bugs in the short term. If a researcher is only familiar with C and C++, is it possible that they're just ill equipped to find similar bugs in Rust?
  • insanitybit 4y ago
    There's definitely a learning curve for looking for vulns in Rust vs C/C++, especially compared to C. Exploitation in particular will be the trickier part, imo, since it requires not just understanding the vuln but also the context and reachability. That said, there are a ton of ways that auditing for vulnerabilities is just as easy or way easier. In particular, most tooling for C/C++ can be applied to rust - fuzzers and sanitizers, for example. Additionally, one only has to "grep for unsafe" and work from there to find Rust vulns, which largely amounts to "what are the assertions for this unsafe block, are they complete, are they held?".
  • goodpoint 4y ago
    Not only that, they are also comparing new code with pretty old code.
    • Manishearth 4y ago
      They're also explicitly tracking new code by language, and talking about memory safety vulnerabilities per year, and they also link to [1] which talks about how most memory safety bugs they get are in new code. Most of the graphs here are about new code. [1]: https://security.googleblog.com/2021/04/rust-in-android-platform.html https://security.googleblog.com/2021/04/rust-in-android-plat...
      • estebank 4y ago
        It's also useful to look at the "rate of bugs per line of new code" because even stablished, long stable projects have code churn. Rare is the project that is unchancged, frozen in bakelite, and any mild refactor can introduce regressions or affect relied upon implicit invariants.
• stephc_int13 4y ago
• goodpoint 4y ago
  I'll be downvoted for pointing out that comparing C++ with Rust without further context can be made into a false dichotomy. Some people are posting the article around the Internet as evidence that Rust solved security. Instead, there are many other memory safe languages around and there has been thousands in the past. Additionally, many security issues are not due to memory safety. Please keep that in mind when making comparisons. EDIT: of course, 2 minutes and I'm downvoted down to -2
  • kangalioo 4y ago
    But I think other memory safe languages don't have C++-like performance, right?
    • goodpoint 4y ago
      There's been many, for example Ada/SPARK, D, Nim, Java, Kotlin, Swift.
      • kllrnohj 4y ago
        I can't speak to the others, but Java & Kotlin do not at all have C++-like performance, especially not in anything beyond a toy level benchmark. And even in those toy level benchmarks (like https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... ), there's a clear divide between C/C++/Rust & everything else.
        • goodpoint 4y ago
          The claim that performance are comparable only on "toy benchmarks" is false. Additionally, most of such simple benchmarks are not representative for real-life workload, and anyways the initial point was about safety. Anyhow the whole HN conversation is now a trainwreck where any dissenting opinion is downvoted so there's no point to continue.
          • 4y ago
• codedokode 4y ago
  Rust doesn't check for overflow in arithmetic operations in release mode so there are lot of opportunities to create vulnerabilities in Rust.
  • maeln 4y ago
    This is how I discovered that one of my code was "bugged". I had to implement a driver for an obscure chinese-made machine with a documentation google translated. In the protocol, there was a check byte and the explanation says that it was the 100 modulo of the sum of all previous byte. They didn't mention overflow. I tested it using a release build and it was working. Later on, while changing a few thing, I notice that the debug build was not working. I quickly find that this was because of the overflow behavior.
  • burntsushi 4y ago
    There is some important context missing from your comment here. At least two points anyway: In Rust, overflow is not undefined behavior (neither signed nor unsigned). Today, arithmetic wraps in release mode (panics in debug mode), but it may panic in release mode in the future. The other point is that, since overflow wraps, that may indeed result in logic bugs. And in theory that logic bug could be used to lead to exploit, such as a buffer overrun. But Rust uses bounds checking by default everywhere, so the worst case you'll usually end up with here is a panic or a DoS vulnerability. Not great, but probably preferable to other types of vulns that grant access to sensitive data. So I think two things would need to happen, at minimum, to get a non-DoS vulnerability here. You'd need to find a bug that caused arithmetic to overflow where it otherwise shouldn't, and you need to find some way to connect that to an explicitly `unsafe` unchecked access into memory.
    • estebank 4y ago
      Beyond the above, IIRC Android ships with integer overflow enabled (but can't find where I read this).
      • est31 4y ago
• LAC-Tech 4y ago
  For me the biggest features of rust are: - great standard library, especially all the iter methods. having 'obscure' stuff like `try_for_each` just makes me so happy as a dev - unit tests built into the lang - tooling is great - docs are top notch The memory safety aspect is... sometimes helpful, sometimes irritating. I prefer zig solution (BYO allocator, special one for testing that reports errors) over rusts, which simplifies a lot of stuff and lets you make cyclical data structures without a lot of hoop jumping.
  • pornel 4y ago
    Rust does require structuring programs in a "Rust way" to avoid fighting with things it can't prove to be safe. However, I appreciate that Rust tries to achieve safety through improving program correctness, not merely crashing sooner. Of course Rust has run-time panics (hasn't solved the halting problem yet), but it also has many patterns catching problems at compile-time. For example, a hardened allocator can detect use-after-free bugs when they happen, but borrow checking can prevent them from existing in the code in the first place.
    • Mesopropithecus 4y ago
      > Rust does require structuring programs in a "Rust way" to avoid fighting with things it can't prove to be safe. That was my concern that I had when I started learning the language. I think it is true, but I was surprised how quickly I managed to get used to the Rust way.
      • LAC-Tech 4y ago
        I'm surprised at how slowly I'm getting used to it! I mean I've improved but I still have a lot of "wtf" moments. End up doing a lot of deep copying and heap allocations just to shut the compiler up, which makes me question just how "zero cost" the safety is.
        • maccam94 4y ago
          Are you able to store that data in reference-counted RC/ARC types? Those can help you avoid dealing with lifetime issues, though you'll still have to think about mutability and concurrency.
• lspears 4y ago
  Why no Go?
  • ear7h 4y ago
    I'm guessing if you don't need something low-level/c-compatible in Android you'd reach for Java/Kotlin since it's already engrained in the ecosystem.
  • maeln 4y ago
    The GC I guess ? Rust is mostly replacing the C & C++ code that is pretty low-level in the OS where a GC is not desirable or even usable.
  • wiseowise 4y ago
    They already have managed language, why would you add another one?
  • masklinn 4y ago
    Does not play well with anything else, and the primary langage is Java/Kotlin, even making two “managed” languages interact properly is difficult when both have well behaved ffi. It would require rearchitecting everything to work with separate processes and IPC, and that’s got some overhead(s). It also has memory safety issues around concurrency, and its limited allowance for abstractions makes papering over those complicated.
• cryptonector 4y ago
  > Safety measures make memory-unsafe languages slow > > Mobile devices have limited resources and we’re always trying to make better use of them to provide users with a better experience (for example, by optimizing performance, improving battery life, and reducing lag). Using memory unsafe code often means that we have to make tradeoffs between security and performance, such as adding additional sandboxing, sanitizers, runtime mitigations, and hardware protections. Unfortunately, these all negatively impact code size, memory, and performance. Even more evidence that the negative performance impact of bounds checking is minimal, nay, it can even be positive.
  • kllrnohj 4y ago
    No it isn't. It's just evidence that it's a trade-off you might want to make in order to achieve some other goal, specifically security. But if "security" isn't remotely a concern for a given project (like almost anything graphics / gaming related), this is not at all evidence for changing anything. It could be that Rust's optimizer eliminates the bounds checking so regularly as to be a moot point, but this isn't saying anything of the sort. It's saying that the cost, whatever it was, was judged to be worth paying for the improved security for these projects
    • bluGill 4y ago
      I take it the opposite: C programmers out of abundance of caution of putting in bounds checks for code that will never be called with out of bound data. As such rust is eliminating code that is being manually written. If you don't write the bounds check in C, and rust for the equivalent determines that the bounds check isn't needed the code should be the same (to the assembly level). However if you write a bounds check in C the optimizer might not eliminate it.
      • kllrnohj 4y ago
        Can you point to any such bounds check in C that an optimizer cannot eliminate but it can eliminate the equivalent one in Rust? I'm sure it's possible to construct such a thing, but I cannot imagine it ever being common enough to show up on any sort of head to head comparison.
• WoodenChair 4y ago
  The more interesting part of this article for me is that in 2022, Java is still the number 1 language that new pieces of Android are made out of. It probably has to be this way for compatibility, and I personally have no problem with Java. But the hype train would not have you believe this.
  • zeroc8 4y ago
    Yup, was quite surprised by this too, I was kind of expecting that most of Java's lunch would have been eaten by Kotlin by now.
    • pkolaczk 4y ago
      Scala hasn't eaten Java's lunch, so how Kotlin could?
      • zeroc8 4y ago
        Well, only talking about Android here. And Scala is a totally different beast anyway.
• modshatereality 4y ago
  is this a good way to spend developer time? How about *removing* all of the middle-man bloatware instead of wasting how many dev-years rewriting it (edit: and effectively making it even LESS maintainable now that it's in some new niche language with a vastly smaller dev pool). just give me the direct linux experience we all deserve instead of this garbo spamflinger middlewear that google leverages to keep you dependent on their build methodology and discourage cooperation with other competitive linux-based system. edit2: wow mods hard at work, already removed one dissenting post.
  • bmicraft 4y ago
    > and effectively making it even LESS maintainable now that it's in some new niche language with a vastly smaller dev pool How is any language supposed to grow if you're only allowed to use it once everybody does? Somebody has to be first (and google isn't, not by a long shot)
    • modshatereality 4y ago
      You should at least wait until there is more than one working/usable compiler for the language if you're going to start making systemic changes to your multi-billion-dollar code base responsible for the commerce of multiple billions of people on the planet. It's a weird move at this point for google to be making(edit: considering go is already supported on multiple compilers).
      • insanitybit 4y ago
        "It should have two compilers" is a pretty arbitrary benchmark for production readiness. I'd suggest the benchmark be based on, idk, something with any fucking meaning.
        • modshatereality 4y ago
          >something with any fucking meaning So you claim to have a better metric, feel free to share it? site broken and wont let me reply any more: "shipped into production" is meaningless, compilers are directly related to language community and complexity.
• Decabytes 4y ago
  Good to see some concrete evidence comparing memory unsafe languages to memory safe languages in an existing product. I just watched the Lex Fridman Guido Van Rossum episode and Rust vs C/C++ appears to be mirroring the trajectory Perl vs Python took in the ML/Bioinformatics space. Only time will tell whether Rust will reach the critical mass necessary to displace C/C++ in most new low level projects, but it appears clear to me that Memory Safe Languages which ever they may be are the future. I don't need to program in an environment where a systems programming language is required, so for me a languages debugability and introspective capabilities are the most important. So far I think Pharo hits the sweet spot for me, but it still has a long way to go documentation wise before I think it will see any sort of adoption. I'm rooting for it though.
  • est31 4y ago
    > Only time will tell whether Rust will reach the critical mass necessary to displace C/C++ in most new low level projects As someone who has been in the Rust community since a couple of months after 1.0, I only see growth, year after year. At the start the community was small. Nowadays even the OSS part of it, which is a subset of the total community, is so big you can't have an overview of it any more. Even for the Rust project itself it's hard to have an overview over everything that's happening (but it's still possible to some degree).
    • pornel 4y ago
      https://lib.rs/stats https://lib.rs/stats crates.io downloads keep growing exponentially, although recently growth rate dipped from 2× to 1.9× (not sure if that's a trend or noise). Ratio of weekday to weekend downloads keeps going up, so presumably professional adoption of Rust keeps growing.
• optymizer 4y ago
  As an Android user ever since the T-Mobile G1, I'm a fan of not having my phone remotely exploited via WebView, or with an SMS, or the other million ways there are to interact with a device, so I absolutely celebrate this progress. As an Android developer though, I have to be the one bitter old man yelling at cloud. I was spoiled by Java and Kotlin to the point where I cannot look at Rust and think it's a nice modern language. Yes, I will start a language war today. Rust is like a truck driver who tried to make a race car that doesn't blow up. It's safe but it does not look refined. I wish you knew how weird Rust looks to me. I tried to learn it 3 times and had to give up after all the WTFs. I said it in the past, and I'll say it again: * What the hell kind of language choice is to force everyone to type "#[derive(Debug)]" for annotations? I'd rather write past the end of an array and have someone steal my Bitcoin wallet than press "shift 3 bracket shift 9 shift 0 bracket" at the top of my structs. What's wrong with @? Nothing. @derive(debug). 2java4u? Ok, [derive debug] then. * What's with the ' everywhere? Not the quote, the piece of dirt on your display. Why are our displays so dirty? * Going for super short keywords "let", "fn", "mod", but then, "let mut" could have been "var". When is typing speed the bottleneck in writing software where you can't take the time to type out "module" or even 'function'? Come on now. * print! now! fast! it's! a! macro! why! are! we! yelling! * Passing "self" as the first argument was bullshit in Python, and it's bullshit in Rust too. Don't look at me like that - the compiler can inject it as the first parameter without requiring you to type it in. * What does "::" do that "." can't? That's right. Nothing. All hail D. D got language design right. Syntax better than Rust. CTFE better than Rust. Templates better than Rust. Marketing worse than Rust, though. I'll try to learn Rust a 4th time now to stay relevant in the Android world, because I have bills to pay, but I want you to know that I blame each and everyone of you weirdos for not holding language designers to a higher bar. Edit: if you downvote, reply with a link to the last compiler you wrote.
  • netr0ute 4y ago
    I had the same experience with Rust too. After trying and failing for hours to trudge through syntax BS, I'm (probably) not touching it again until something big changes. I can't even get user input without making a huge ugly one-liner or importing some dependency.
• GuB-42 4y ago
  I didn't realize there was so much C and C++ in Android, I thought most of it was Java. Maybe they are just talking about the core system (including the Linux kernel and Java runtime) and not all the builtin apps.
  • kllrnohj 4y ago
    Much of the graphics, camera, media, bluetooth, wifi, input handling, etc... stacks are native. There's a massive amount of native code in Android below the veneer of the Java API that apps are given. Many of the higher level constructs are then in Java/Kotlin, though, like the builtin apps, system ui, activity & window managers, etc...
• Octokiddie 4y ago
  > This matches the expectations published in our blog post 2 years ago about the age of memory safety vulnerabilities and why our focus should be on new code, not rewriting existing components. and > As we noted in the original announcement, our goal is not to convert existing C/C++ to Rust, but rather to shift development of new code to memory safe languages over time. For those working on C/C++ code bases, how does the incremental addition of Rust work in practice? What strategies and tools come in handy? Also, what are some good case studies where Rust was introduced to add new features, but still needed to work within a system mainly composed of C/C++? I've seen some of the first steps with Linux, but I'm thinking of a project where more substantial additions have been made.
  • cesarb 4y ago
    > but I'm thinking of a project where more substantial additions have been made. The most famous example of that is AFAIK Firefox. There's a (perhaps outdated) list at https://wiki.mozilla.org/Oxidation#Rust_Components https://wiki.mozilla.org/Oxidation#Rust_Components of places where Rust was used to replace some component in Firefox; the most famous of these are probably the CSS style calculation which came from the Servo project (https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/ https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-en...), and a renderer also from the Servo project (https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-fps-how-webrender-gets-rid-of-jank/ https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-f...).
  • halpmeh 4y ago
    I imagine it works just like FFI works in other languages. Compile a c-archive and link against it.
  • bluGill 4y ago
    I've only started scratching the surface, but that rust really wants you to use Cargo, while we have our own homegrown package manager, and cmake creates a lot of friction. I can tell you that bad programmers can write bad code in Rust.
    • 4y ago
• mk89 4y ago
  I am not a Rust or C++ fanboy, and I am happy that we are moving towards a future where there are less memory bugs, but… are we really? - https://www.infoq.com/news/2021/11/rudra-rust-safety/ https://www.infoq.com/news/2021/11/rudra-rust-safety/ - https://cve.report/vendor/rust-lang https://cve.report/vendor/rust-lang And you can find online similar links and research on the topic. All it takes is that you use that specific piece of code at the wrong time, and that’s it: your system which you once believed to be safe is not anymore safe. And you know what? You don’t even know what a sanitizer is, because they told you that Rust is a memory safe language and you don’t need anything else than the rust compiler - this is how I find 99% of today’s articles about Rust. Sure, today being Rust less used than C/C++ will clearly show less CVEs. The question is … once it’s in the wild (and by this I mean “major” libs or serious shit done in Rust) how can you prevent such bugs without a runtime sanitizer? Beware that such CVEs can affect Rust Standard library as well, not just an unknown library. Again, there is no way of escaping bad programming and bad practices, no matter which language you use. Someone might argue that in Python or Java you can still do bad stuff, however, the likelihood is way lower, especially because most of your Java libraries will very likely be written in Java - unless you know it’s using JNI under the hood etc.
  • joshuamorton 4y ago
    Yes. They found 250 bugs after analyzing the entirety of rust and all of it's packages. There are probably more memory safety bugs in the python standard library and top 50k packages.
    • masklinn 4y ago
      The rust project itself also has an extremely aggressive CVE policy (which many find too aggressive): if unsoundness is found in an API it gets a CVE, no matter how convoluted, and how unlikely it is to get into that situation, with absolutely no guarantee of any code in the wild coming even close to the unsoundness. Essentially, the Rust standard is that more or less every line of the C++ standard is a CVE. Hell, the Rust project releases CVE for things other languages literally just shrug about e.g. https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html The C++ people just go "lol nothing in std::filesystem is safe we don't give a shit". The spec pretty much says it's UB to have other programs interact with the filesystem: http://eel.is/c++draft/fs.race.behavior#1.sentence-2 http://eel.is/c++draft/fs.race.behavior#1.sentence-2
• lolinder 4y ago
  Their notes about vulnerability severity are particularly interesting. Defenders of C/C++ frequently note that memory safety bugs aren't a significant percentage of the total bug count, and argue that this means it's not worth the hassle of switching to a new language. Google's data suggests that while this is true, almost all severe vulnerabilities are related to memory safety. Their switch to memory-safe languages has led to a dramatic decrease in critical-severity and remotely-exploitable vulnerabilities even as the total number of vulnerabilities has remained steady.
  • deleted 4y ago
    [deleted]
  • yosefk 4y ago
    It's even worse. The majority, not of all bugs, but all vulnerabilities (of all severities) do come from memory safety bugs. TFA: "For more than a decade, memory safety vulnerabilities have consistently represented more than 65% of vulnerabilities across products, and across the industry." On top of that, memory safety vulnerabilities are disproportionately high severity: "Memory safety vulnerabilities disproportionately represent our most severe vulnerabilities. In 2022, despite only representing 36% of vulnerabilities in the security bulletin (NOTE: down to 36% from 65% because of moving from C++ to Rust and other memory safe languages), memory-safety vulnerabilities accounted for 86% of our critical severity security vulnerabilities, our highest rating, and 89% of our remotely exploitable vulnerabilities. Over the past few years, memory safety vulnerabilities have accounted for 78% of confirmed exploited “in-the-wild” vulnerabilities on Android devices."
    • p-e-w 4y ago
      > NOTE: down to 36% from 65% because of moving from C++ to Rust and other memory safe languages Imagine if in any other field, a process or technology were developed that cuts the number of high-severity issues in half. For example, a modification to the standard anesthesia protocols that demonstrably reduces anesthesia-related fatalities by 50% in clinical practice. And now imagine, in reaction to this revolutionary development, thousands of anesthesiologists publicly said things like "what matters is not the technique but the skill of the physician", "good anesthesiologists don't make mistakes like that in the first place", "but this new technique takes 1%-3% longer than the previous one" or similar. Utterly unthinkable, isn't it? Yet in software engineering, this is exactly what has been happening every day for more than a decade.
• jfengel 4y ago
  I'm surprised that Kotlin is such a small fraction. I thought Google was trying to make Kotlin preferred over Java for Android development. (Not that it's easy to tell from the pie chart, which colors one orange and the other red, in similar shades. Do better, guys.)
  • dragonwriter 4y ago
    Development of Android and development for Android are different domains.
• faitswulff 4y ago
  No mention of Carbon among the new memory safe languages. I wonder what inside baseball is at play with language selection.
  • UncleMeat 4y ago
    Carbon is not production ready yet. It doesn't even have a publicly available compiler (just an interpreter). Carbon is more about answering "what do we do with the billions of lines of C++ code we've got" than "what is the best way to add new code to a system."
  • saagarjha 4y ago
    Carbon is not memory safe, not production grade, and also designed somewhat away from the Android team at the moment.
    • faitswulff 4y ago
      Ah yes, I'd forgotten about it not being memory safe. Thanks!
• hknmtt 4y ago
  programming language developers always made compilers to just do that - compile the code. without actually checking the code for problems and allowed programmers to write faulty code. and now we have accepted these memory leaks and shooting oneself into one's foot as normal. so instead of investing time to make compilers output safe programs we had to wait for rust to come by and its "first time in history" compiler while it limits the programmers tremendously to do that along with the ugliest syntax ever invented. when a programmer looks at faulty code, the bug can be seen. sometimes easily, other time not as easy but it can be identified nevertheless. that means we, humans, can detect them. so why can't programs do the same while having way more computing power at their disposal for that particular task, along with language definition and type system? everyone keeps writing new languages and trying to reinvent the wheel in blue, red, purple color instead of solving the actual problem.
  • the_myth 4y ago
    I mean, rust devs are couple of nobodies and I don't think they just let nobodies in on the C++ committee.
• deleted 4y ago
  [deleted]
• mark_l_watson 4y ago
  How does Swift compare to Rust in safety? I read that Swift is only memory safe in single threaded environments, which is not ideal. I was very enthusiastic about Rust about 4 years ago but decided to learn Swift instead as a new “cool non-Lisp language” to learn. Seeing an recent article on writing Python in Rust made me wish that I had chosen differently. I found this article made me feel better about security. I expect that increasing use of memory safe languages will lock down public infrastructure and software, making everyone safer.
  • tulio_ribeiro 4y ago
    Comparing the Memory Safety of Swift and Rust? When comparing the safety of Swift and Rust, it is important to note that both languages employ strict type systems and compile-time checks to prevent common memory-related bugs such as buffer overflows and access violations. However, the way they handle memory safety in multi-threaded environments differs. In Swift, memory is managed using automatic reference counting (ARC), which tracks and manages the lifetime of objects in order to prevent memory leaks. However, ARC is only effective in single-threaded environments. In a multi-threaded environment, multiple threads can access the same memory simultaneously, which can lead to race conditions and other memory-related issues. In order to avoid these problems in a multi-threaded Swift environment, developers must use synchronization techniques such as locks or atomic operations to ensure that memory is accessed in a safe and predictable way. Rust, on the other hand, uses a borrowing and ownership model to ensure memory safety in both single-threaded and multi-threaded environments. In this model, any value in Rust has a single owner, and the owner is responsible for managing the value's lifetime. When a value is borrowed, the borrower is given a temporary, read-only view of the value, and the original owner continues to be responsible for managing the value's lifetime. This ensures that memory is always accessed in a safe and predictable way, even in a multi-threaded environment. Overall, both Swift and Rust offer strong guarantees of memory safety, but Rust's borrowing and ownership model may provide better guarantees in a multi-threaded environment.
  • lalaithion 4y ago
    I haven't actually been able to find an example program where Swift violates memory safety in a multithreaded environment; I'd love to see an example.
• blub 4y ago
  No such luck in having some technical discussion or at least a link to the sources. If the Rust community can be insufferable when trying to sell Rust at any and every opportunity, Lord have mercy when they see any kind of success because the preening and puffing will have no end. This blog post will live forever in the annals of Rust. On the other hand I’m not surprised to see that it’s written by the security team and not a development team. Same pattern as with Microsoft: security specialists tend to get obsessed by their subject matter (just like many Rust programmers), end up hating C and C++ and see them as the source of all problems (just like many Rust programmers). In reality, C and C++ were the saviors of Android and Google reluctantly had to conjure the NDK to make up for a severe lack of performance compared to the iPhone. Note how even in the current Android they mention improving the UI performance and having less “jank”. Without C++ Android would have been DoA, but it doesn’t look like there will be a blog post thanking C++ any time soon :-) I can’t take seriously reports about the benefits of a tool that don’t mention any of the downsides. When the devs post a blog cursing the troubles they had getting Java and C++ and Rust to work together and pitying themselves for having to read both C++ and Rust, then we’ll be getting closer to the truth.
  • Ar-Curunir 4y ago
    Yes, C++ was critical to Android in the past, when there was no memory-safe low level systems language that could provide an alternative. Now there is, so they’re using it, and finding benefits, and writing about those benefits. What should they do instead, write an eulogy to C++?
    • blub 4y ago
      C++ is still essential for Android, but you won’t hear that from the security team bubble. They should have the dev teams write about the good, the bad and the ugly of using Rust instead of having the security team write a sanitized rainbows and sunshine story.
      • saagarjha 4y ago
        The decision to use Rust was made by a team of developers, not the security team.
• latenightcoding 4y ago
  I wonder if their efforts to leverage modern chip capabilities to address memory safety (e.g: ARM memory tagging) contributed to that drop of memory safety vulnerabilities
  • Avamander 4y ago
    Those aren't or haven't been available long enough to have a significant effect, I suspect.
  • Gigachad 4y ago
    Looked this up as it's new to me. Seems interesting but not far enough, if you configure it to crash the system on an error for dev only, you aren't going to spot the hard to reach cases which are usually the target of these attacks, and having it set to crash on the release build is likely going to be seen as unacceptable. Something like Rust which can ahead of time verify that these issues aren't present is a better solution imo. Maybe then we can use this as a last resort check that the usages of unsafe didn't cause issues.
    • saagarjha 4y ago
      These technologies are intended for production use. It’s most of the reason why you’d want them in the hardware itself, because it drives the performance impact down.
    • pjmlp 4y ago
      Solaris SPARC has been using them for a decade now. https://docs.oracle.com/cd/E88353_01/html/E37853/adi-7.html https://docs.oracle.com/cd/E88353_01/html/E37853/adi-7.html
  • saagarjha 4y ago
    It helps along with the other (software) tooling that exists to improve the safety story for existing C and C++ code. However, it does not eliminate these issues.
    • 4y ago
• amelius 4y ago
  Who cares about memory safety when the entire platform is already an advertising shitshow full of spyware?
  • saagarjha 4y ago
    Plenty of people make Android distributions ostensibly without any spyware. Presumably they’d like those to be secure!
• userbinator 4y ago
  They're just making it harder for you to root and own the general-purpose computer you paid for. Until "the nukes are on our side", I don't think this should be celebrated or praised.
• andridk 4y ago
  Notably absent from said list of languages: Google's Go
  • masklinn 4y ago
    Hardly notable. Go is an application langage and managed runtime. Android already has that.
• keithalewis 4y ago
  Who remembers Jean-Yves Girard? His linear logic was the foundation of Rust. We live in a world where people who got participation awards in school need training wheels now. Wake me up when sqlite is rewritten in Rust.
  • insanitybit 4y ago
    borderline incoherent
• nigrioid 4y ago
  Rust apologists believe they are going to save the world. In order for them to do so, they have to uproot, destroy (deem it unsafe and insecure), and rewrite a lot of things they don't yet have influence over. A lot of people who are pushing back against Rust are doing so because they can sense this coercion, not because the language is ugly or "memory safety" issues aren't as significant as they are made out to be, or whatever other arguments the stupid "c-niles" always use.
  • insanitybit 4y ago
    it's true, we are coming after you and we will not be stopped until all c-niles are out of work
• eBombzor 4y ago
  No language can fix maliciously poor design. cough Pixel unlock cough. Maybe separate your views with a layer of security...
  • insanitybit 4y ago
    wow yeah i wonder why they even bothered writing this whole article, good point
• greysphere 4y ago
  Anecdotal, but our apps that used to have 0 ANRs for years, have all had them start sprinkling in despite node code changes from us. Maybe ANR reporting got more strict, or maybe it's something else...
• tulio_ribeiro 4y ago
  Well, it looks like Google has finally figured out the solution to all of their security woes: just switch to Rust and watch the vulnerabilities vanish! I'm sure that every other company facing similar issues will be rushing to follow suit. #RustToTheRescue Memory safety, oh so sweet Reducing vulnerabilities, a feat Google switches to Rust Security improved, a must Memory corruption, a thing of the past Safe coding, a task at last
• Alifatisk 4y ago
  Just curious, why wasn’t Dart mentioned?
  • lolinder 4y ago
    They don't use it in Android-the-OS. It would fill the same place as Java and Kotlin, and adding a third managed language wouldn't add much benefit.