Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory Safe Languages in Android 13

security.googleblog.com

Post reply on HN
Print view View original

341–350 of 606 posts

Re: Memory Safe Languages in Android 13

#341

Post by heather45879 »

thaumasiotes wrote: post #305
heather45879 wrote: post #251

Earlier quoted context omitted.

Good design theory. 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 esca…

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

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

Re: Memory Safe Languages in Android 13

#342

Post by aswanson »

raggi wrote: post #338
clnq wrote: post #294

Earlier quoted context omitted.

Programming languages are tools for a job. As the saying goes, a bad workman blames his tools. It's not worth taking anyone who blames defects on a programming language too seriously, whether it's Google or not. Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them. Of course, there are languages that abstract memory safety to the point that they elim…

> We should not bury C++ prematurely before answering the question - "what else is as fast and efficient as to replace it for OOP?" We have an answer: Rust. It's no longer premature, bury it.

Amen.

Re: Memory Safe Languages in Android 13

#343

Post by raggi »

clnq wrote: post #330
tptacek wrote: post #303

Earlier quoted context omitted.

Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them. This recapitulates an argument at least as old as C89. You can probably find Usenet posts deploying it to argue against the adoption of strncpy, because if people don't know how to use sizeof and strlen, then bad for them.

Yes, my argument sounds similar. But it's in support of modernity rather than primitivism. C++ nowadays can be used in a very memory-safe way without much effort. In my professional experience, memory leaks and corruptions are sporadic in modern C++ code and common in old-style pre-C++ 11 code. That's why I'm a bit skeptical of this article from Google. It seems reasonable that Android has quite a lot of pre-C++ 11 c…

You can do some basic analysis about your assumption: go pick out a bunch of the CVEs and look at the age and style of the source code.

Another approximation is to look at the Android source tree to see what proportion of it is as old as you assume in your argument. There are 431 results for a search `"Copyright 200" filepath:.\.cpp`. There are 7465 results for `"Copyright 201" filepath:.\.cpp`. 4152 results for `"Copyright 202" filepath:.\.cpp`. 220 for 2012, 354 for 2011. If you exclude tests the ratio is even less favorable for your theory.

In case you're wondering the project policy is to add a copyright header at the time the file is created, they do not update years in headers arbitrarily. As a spot check the first file matching "Copyright 200" that wasn't just essentially C code wrapped in extern "C" was: external/angle/src/libANGLE/Config.cpp. This file contains the use of std::make_pair.

You can perform these searches yourself here: https://cs.android.com/search?q=%22Copyright%20200%22%20file...

Re: Memory Safe Languages in Android 13

#344

Post by saagarjha »

Kukumber wrote: post #339
saagarjha wrote: post #324

Earlier quoted context omitted.

Kotlin is generally recommended for application development on Android.

I talk about Kotlin Native, not Kotlin

It doesn't make sense to use here. You have a perfectly cromulent JVM if you want to run Kotlin code already.

Re: Memory Safe Languages in Android 13

#345

Post by 100001_100011 »

_fullpint wrote: post #272
dist1ll wrote: post #69

Earlier quoted context omitted.

What I like about this language is the crazy amount of creative and insightful discussions about language features and stabilization. It's because Rust hits the spot for MANY different domains and people. System programmers, functional programmers, backend, db engineers, GUI, devs from the formal verification/mission critical camp, OS devs, graphics and even frontend with WASM. For me personally, the thing I miss in…

I write a lot of Rust these days and unfortunately really great FP stuff is pretty damn cumbersome to write.

I found this viewpoint about FP in Rust pretty interesting. Can you elaborate?

Re: Memory Safe Languages in Android 13

#346

Post by tialaramex »

afdbcreid wrote: post #267
burntsushi wrote: post #25

Earlier quoted context omitted.

Is there any practical programming language that is memory safe in its "entirety"? Python, for example, certainly is not. It has unsafe escape hatches (via ffi, at the very least). Yet, everyone I know of says and thinks of Python as a memory safe language. I do as well. > which makes it easier for developers to compartmentalize code to achieve memory-safety The problem here is that this is incomplete. Many many many…

Surely this is true, but I still have the feeling that libraries in Rust tend to have more unsafe code than Java, Python, C# or others, maybe even more unsafe code than needed. Perhaps this is related to the problem domain.

You would definitely need to control for domain.

A Rust library for some sort of mathematical modelling might well need no unsafe at all, while a Java library for controlling some hardware might soon turn into JNI talking to some C++ code and oops you're unsafe.

In C# you need to reach for unsafe to do some of the stuff Rust can just do safely anyway. Did you know a C# struct with an array of 8 ints in it, doesn't actually have the eight ints baked inside the struct? It was easier in the CLR not to do that, so they didn't. Which means C# structs which look like a compact single object that surely lives in a single cache line don't actually do that in safe C#. You need unsafe.

Re: Memory Safe Languages in Android 13

#347

Post by raggi »

blub wrote: post #293
Ar-Curunir wrote: post #255

Earlier quoted context omitted.

Google is one of the biggest C++ shops out there, and also authors and maintains many of the static analysis tools and safety features you mention. If they’re saying that C++ can’t be saved, maybe they’re worth listening to.

They’re not saying that C++ can or can’t be saved. And there’s no “they”, there are hundreds of teams with different expectations and policies. You’re merely reading what you want between the lines.

True, but what is said is:

  We continue to invest in tools to improve the safety of our C/C++. Over the past few releases we’ve introduced the Scudo hardened allocator, HWASAN, GWP-ASAN, and KFENCE on production Android devices. We’ve also increased our fuzzing coverage on our existing code base. 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.

Re: Memory Safe Languages in Android 13

#348

Post by clnq »

raggi wrote: post #343
clnq wrote: post #330

Earlier quoted context omitted.

Yes, my argument sounds similar. But it's in support of modernity rather than primitivism. C++ nowadays can be used in a very memory-safe way without much effort. In my professional experience, memory leaks and corruptions are sporadic in modern C++ code and common in old-style pre-C++ 11 code. That's why I'm a bit skeptical of this article from Google. It seems reasonable that Android has quite a lot of pre-C++ 11 c…

You can do some basic analysis about your assumption: go pick out a bunch of the CVEs and look at the age and style of the source code. Another approximation is to look at the Android source tree to see what proportion of it is as old as you assume in your argument. There are 431 results for a search `"Copyright 200" filepath:. \.cpp`. There are 7465 results for `"Copyright 201" filepath:. \.cpp`. 4152 results for `"…

Thanks, that was very insightful. Yes, as you say, the copyright year in a .cpp/.h doesn't necessarily say whether C++ 11 features are used.

I've looked at many "Copyright 201" and "Copyright 202" headers. I needed to see more use of C++ 11 or equivalent smart pointers or containers to say that this codebase uses modern C++ memory safety features. Other modern C++ features (like std::make_pair that you mention) are easier to spot.

I expect this codebase to have many memory safety issues. It may not pass code review in a company/team that expects their people to use modern C++ memory safety features. After seeing it, I'm more convinced that the reason Google has so many problems with C++ in Android really is because they don't insist their engineers use modern C++ (or equivalent in-house containers/pointers).

Here's another insightful pair of searches:

" std::make_" filepath:.*\.cpp

"delete " filepath:.*\.cpp

Re: Memory Safe Languages in Android 13

#349

Post by raggi »

harry8 wrote: post #225
lolinder wrote: post #116

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…

Seems like drawing too many conclusions from evidence while arguing against a straw man? Defenders of C might note that Android is java and IOS is not and compare the security of those two systems and say clearly memory-safe is focusing on the wrong thing. This is equally true but no more valid an argument. The one that really bothers me in all these language-booster discussions (that we should and need to have) is t…

WireGuard is a recent and prominent example of a system that has been formally verified (https://www.wireguard.com/formal-verification/). There are implementations in a variety of languages due to integration considerations.

You will find at the bottom of that page C implementations of curve25519 that are proofed and derived from F* and Coq. Curve25519 is a relatively simple implementation and only one part of any system that uses it. As you can see in both of these implementations the papers recognize a team of contributors each - this should provide some insight as to the cost of such work. That doesn't make it unimportant, it just makes it rare.

Re: Memory Safe Languages in Android 13

#350

Post by clnq »

Tuna-Fish wrote: post #327
clnq wrote: post #294

Earlier quoted context omitted.

Programming languages are tools for a job. As the saying goes, a bad workman blames his tools. It's not worth taking anyone who blames defects on a programming language too seriously, whether it's Google or not. Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them. Of course, there are languages that abstract memory safety to the point that they elim…

> As the saying goes, a bad workman blames his tools. It's not worth taking anyone who blames defects on a programming language too seriously Are you serious? A bad workman blames his tools, because workmen are reponsible for their tools . A large part of being a good workman is identifying what tools are good and using them. And C++ is a terrible tool for any task where you are not forced to use it because of existi…

> A bad workman blames his tools, because workmen are reponsible for their tools. A large part of being a good workman is identifying what tools are good and using them.

As I said in the comment to which you are responding, "selecting the correct tool for a job is more important than figuring out which tool is better in some abstract way."

> C++ is a terrible tool for any task where you are not forced to use it

Many game developers, OS developers, and massive hardware-software makers doing embedded programming who use C++ would disagree. What would you say to them?

> If you need fast and efficient code, why on earth would you be doing OOP?

For small projects, I could agree. What would your recommended alternative be for massive codebases in large tech companies that need fast and efficient code?

P.S. Please read https://news.ycombinator.com/newsguidelines.html about snarky comments. Thanks.

Post reply on HN