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

411–420 of 606 posts

Re: Memory Safe Languages in Android 13

#411

Post by kaba0 »

cesarb wrote: post #161
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…

> It has unsafe escape hatches (via ffi, at the very least). Playing devil's advocate, I can think of at least one language which has no escape hatches: Javascript running within a web page.

It is very easy to create a safe language. Hell, most brainfuck interpreter is likely completely safe, you allocate a large enough array and just iterate over its basic instructions that only ever modify that array and print a character. A Turing machine in itself can do no harm.

The hard part comes at allowing it to do something useful, but only the parts I believe should be able to. E.g. plugging in file system access to our brainfuck interpreter will make it quite unsafe. Node for example does have C FFI.

Re: Memory Safe Languages in Android 13

#412

Post by rob74 »

kaba0 wrote: post #396
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.

Google’s C++ coding guide is (was?) not really up-to-date, so there is that. Modern C++ is indeed a huge upgrade on what came before and with a good amount of static and dynamic analysis the state of low-level programming is much better now, but there really is no reason for new programs to be written with these . Besides the bottom of the stack, managed languages are more than fast enough for nigh everything.

> Besides the bottom of the stack, managed languages are more than fast enough for nigh everything

And yet, there is a lot of enthusiasm (at least here on HN) for web development in Rust...

Re: Memory Safe Languages in Android 13

#413

Post by kaba0 »

civopsec wrote: post #29
cyber_kinetist wrote: post #18

Earlier quoted context omitted.

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.

Then even Java is not memory safe according to the implicit standard that you allude to here since one can use the `Unsafe` class.

Not for much longer, access has to be very explicitly specified at start time so that (deliberate) hole is getting smaller and smaller. But of course native functions is a thing (but very infrequent)

Re: Memory Safe Languages in Android 13

#414

Post by blub »

saagarjha wrote: post #325
blub wrote: post #292

Earlier quoted context omitted.

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.

And I want to hear the uncensored opinions of those dev teams.

This here was a blog for managers.

Re: Memory Safe Languages in Android 13

#415

Post by blub »

insanitybit wrote: post #336
blub wrote: post #248

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…

It's almost like us security professionals are just better developers too :O

You guys would have almost replaced almost developers by now, if you weren’t so rare and precious :-)

Re: Memory Safe Languages in Android 13

#416

Post by andrewjl »

logicchains wrote: post #352
Gigachad wrote: post #282

Earlier quoted context omitted.

C-nile developers have been making incorrect arguments for a while now. The reality is which almost everyone can see is that memory safe languages are pretty much always what you want to be using for new code. OS and security sensitive components are the prime targets for rewrites in more secure languages. Now Google has put this to the test and has the data to prove it. We should not allow the worlds technology secu…

>The reality is which almost everyone can see is that memory safe languages are pretty much always what you want to be using for new code. Not everybody is writing security-critical code. For some things productivity and time-to-market is more important and security is not enough of a concern to justify dealing with a language with horrible compile times and a self-righteous, dogmatic community.

> For some things productivity and time-to-market is more important

Who would choose C/C++ and not something like Go in that situation?

Re: Memory Safe Languages in Android 13

#417

Post by mk89 »

stouset wrote: post #333
mk89 wrote: post #284

Earlier quoted context omitted.

> You… almost literally did? I don't understand this comment, to be honest. What does it add to the conversation?

Why shouldn’t this kind of inconsistency be pointed out? I’m happy to believe GP didn’t say exactly what they intended to or simply misremembered what exactly they said previously. It’s certainly something I’ve done before in an online conversation. And when it’s happened to me I’ve appreciated having it pointed out explicitly so I could clarify what my thoughts actually were. Often it’s because I misstated my opinio…

You might be right, it's probably just easier to ask :)

So, when I wrote the message I was really physically and mentally tired, I wrote from the phone which unfortunately doesn't always help me write 100% consistent sentences.

Finally I just used wrong wording. As I mentioned in another comment, the improvement is clear and it's the new way forward. In my opinion it simply doesn't solve all memory safety issues, and while with c and c++ you know unfortunately what you get, with Rust or Swift you might get a false sense of 100% safety where there is not.

Re: Memory Safe Languages in Android 13

#418

Post by mk89 »

nickm12 wrote: post #367
mk89 wrote: post #283

Earlier quoted context omitted.

> It is - as long as you don't use unsafe. That's what I tried to show in the previous post: it's just not true, because if you rely even on an unsafe function from the standard library affected by a CVE, you're just fucked as if it was in C, C++ or other languages. The only difference is that you don't know what's happening under the hood and you feel "safe" because that's how they sold the language to you. Until yo…

"Memory safe to me means -> it just can't happen. That's it." I'd suggest rethinking this definition. You are always at the mercy of the lower-levels of your system, both in the runtime and the compiler. By this definition, nothing is memory-safe, since it is possible for your code in a "memory safe" language to encounter memory-safety issues in its runtime or the operating system. Memory-safe means the bug won't hap…

> By this definition, nothing is memory-safe, since it is possible for your code in a "memory safe" language to encounter memory-safety issues in its runtime

I am trying not to be extreme here, and of course I agree we objectively can't guarantee 100% safety, especially what's happening outside our code. However, importing a library happens within our code, it's in our executable, even if you don't write 90% of what's inside.

As far as I know, the JVM checks at runtime for overflows, dangling pointers, etc. So in theory there I only have to worry about using a good operating system that doesn't do funny things, because I know that the runtime has my back (at some cost, of course).

> Memory-safe means the bug won't happen in YOUR CODE.

So what happens when Rust replaces a major component in some important framework or library and your team chooses to use it because "it's written in Rust therefore it's safe to use", but actually it's vulnerable to some weird CVE because of some unsafe calls under the hood? The only way to find it is by using some sanitizer at runtime, or to exclude the dependency, but hey can you really rewrite that major library in a safe[r] manner?

Re: Memory Safe Languages in Android 13

#419

Post by kasabali »

nequo wrote: post #27
heather45879 wrote: post #24

Earlier quoted context omitted.

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.

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.

Where are the double colons and angle brackets in C?
Post reply on HN