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

321–330 of 606 posts

Re: Memory Safe Languages in Android 13

#321

Post by saagarjha »

Gigachad wrote: post #297
latenightcoding wrote: post #250

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

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

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.

Re: Memory Safe Languages in Android 13

#322

Post by saagarjha »

latenightcoding wrote: post #250

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

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.

Re: Memory Safe Languages in Android 13

#324

Post by saagarjha »

Kukumber wrote: post #12

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

Kotlin is generally recommended for application development on Android.

Re: Memory Safe Languages in Android 13

#325

Post by saagarjha »

blub wrote: post #292
Ar-Curunir wrote: post #263

Earlier quoted context omitted.

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

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.

The decision to use Rust was made by a team of developers, not the security team.

Re: Memory Safe Languages in Android 13

#326

Post by saagarjha »

est31 wrote: post #103
estebank wrote: post #73

Earlier quoted context omitted.

Beyond the above, IIRC Android ships with integer overflow enabled (but can't find where I read this).

You can confirm it by looking into the source code: https://android.googlesource.com/platform/build/soong/+/refs... Not an expert, but a file named "global.go" makes me confident :).

Amusing to see that the compiler flags for Rust are stored in a Go file ;)

Re: Memory Safe Languages in Android 13

#327

Post by Tuna-Fish »

clnq wrote: post #294
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.

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 existing libraries. All the memory safety features of modern C++ are a tiny, almost vanishingly small step in the right direction.

> "what else is as fast and efficient as to replace it for OOP?" And if a project doesn't need fast and efficient code, then why is it using C or C++ in the first place?

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

Re: Memory Safe Languages in Android 13

#328

Post by aswanson »

saagarjha wrote: post #308
aswanson wrote: post #279

Earlier quoted context omitted.

C++ is needlessly complex and puts too much of a cognitive burden on the developer. I just wasted a day of my life traced to an errant semicolon in a legacy cpp base. I've used the language for 20 years. It can't be saved.

No offense, but I haven’t heard if people wasting days in semicolons outside of memes and really junior developers. What was the issue?

In real-time systems with millions of lines of code, no debugging capabilities outside of logs, and user misuse use cases, you'd be surprised what can lurk beneath.

Re: Memory Safe Languages in Android 13

#329

Post by tialaramex »

kllrnohj wrote: post #215
tialaramex wrote: post #194

Earlier quoted context omitted.

I would guess all the aliasing stuff will get you. In C it's very difficult for the compiler to know whether two pointers are aliased, if we change X maybe Y changes too (because actually X and Y were the same). In Rust if we can write to it then it isn't aliased, and if we can't write to it then nobody can change it, thus changing X definitely can't change Y and the emitted machine code is sometimes simpler as a res…

But the compiler doesn't need to care in that case because it's not bounds checking those pointers in the first place in C. So that's not going to give you slow C code from bounds checking that the optimizer failed to eliminate. Like yeah there's aliasing changes, but in "idiomatic" C/C++ how is that getting you bounds checking that's not being optimized away fairly consistently?

Wait, previously you were talking about bounds checks which can't be optimised out, now you seem to be saying in C you wouldn't bother writing any bounds checks, which is a quite different claim.

Re: Memory Safe Languages in Android 13

#330

Post by clnq »

tptacek wrote: post #303
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…

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 code. And the article seems to lump two very different approaches to memory safety in pre and post-C++ 11 style programming.

Post reply on HN