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

531–540 of 606 posts

Re: Memory Safe Languages in Android 13

#531

Post by steveklabnik »

bluGill wrote: post #513
mk89 wrote: post #159

Earlier quoted context omitted.

If we leave it to the programmer, what are we improving? We did a big improvement, but why can’t we disable “unsafe”? That would leave absolutely no margin for such errors.

There is a time when you need unsafe. Hopefully those are rare, but most rust projects will need it. (remember Rust is aiming for systems programming, some domains never need unsafe, but others will need it). I'm a c++ guy interested in Rust, my understanding is Unsafe lets me design custom high performance interfaces that do weird pointer tricks (which is needed to interface to the C and C++98 interfaces I work with…

> most rust projects will need it.

If you mean "writing unsafe in your codebase yourself," this isn't borne out by the numbers.

If you mean "depending on unsafe somewhere in your dependencies" then 100% of Rust code needs unsafe, just like any other language. Interacting with hardware, many operating systems' APIs, these aren't created in a way to guarantee it, and you need to interact with them to do anything.

Re: Memory Safe Languages in Android 13

#532

Post by athrowaway12 »

pjmlp wrote: post #522
athrowaway12 wrote: post #521

Earlier quoted context omitted.

> enforcement of security vulnerability should be by law I think whether there "should" be a law making you liable could depend on the details of the exploit. If you get exploited via rowhammer, I don't think anyone would blame you. It would be unreasonable if every small business running a website could be sued if they didn't defend against electromagnetic interference within the RAM. However, if you're Apple and sa…

Yes it definetly should. Computing is the only industry, where people accept to live with tainted goods instead of forcing whoever sold them to pay back, cover for their damage or whatever. We already have high integrity computing, digital stores with returns, consulting with warranty clauses, and some countries are finally waking up that computing shouldn't be a special snowflake. https://www.twobirds.com/en/insight…

Just pointing that all software is exploitable. And punishing the application developer might not be right if the vulnerability is caused by a lower level dependency. For example, log4j.

I agree if there's a high social cost to a breach then the government should punish those involved. Also, the security of your software depends on your threat model and which threats are in scope and you're willing to invest in protecting against. The tradeoff is ease of development and velocity. So maybe such laws will incentive this process differently, and maybe it's a worthwhile change.

I look at computing as a big experiment. Personally, I am very careful to use trustworthy services and don't depend on software for anything critical (besides banking, but luckily FDIC). Most people don't take the same precautions and rely very heavily. It's obviously critical infrastructure at this point. Maybe it's time to stop thinking of it as an experiment, and maybe these laws make sense.

I don't like the concept for emotional reasons; to me it's sad and signals another step towards the end of the golden age of the internet.

Re: Memory Safe Languages in Android 13

#533

Post by humanrebar »

UncleMeat wrote: post #506
humanrebar wrote: post #502

Earlier quoted context omitted.

Google is great at engineering projects that look great in promotion packets. Just because they're big and funded doesn't mean they're good at this. It seems plausible that splashy projects in new languages are better for careers than grinding through "stable" codebases using "boring" engineering practices. I also gather that Google has a challenge, possibly for similar reasons, keeping their third party dependencies…

//third_party is indeed a challenge, but it is definitely not the case that vulns are only coming from //third_party. I mean, the linked article is about the Android codebase (not attached to //third_party) and the Chrome codebase publishes a ton of vuln data (again, not attached to //third_party).

I was saying Google might be pessimistic about C and C++ for some reasons specific to Google culture, like inability to get engineers to care about "boring" work. I wasn't making the point you're addressing.

Re: Memory Safe Languages in Android 13

#534

Post by humanrebar »

lolinder wrote: post #530
humanrebar wrote: post #500

Earlier quoted context omitted.

How much of the benefit comes from the rewrite itself? A more precise comparison would be rewriting that C or C++ in the same language but with memory safety in mind and see how things turned out. The same question comes up when an existing system is rewritten from language A to language B and big performance gains are seen. The language could be the big cause, but so could the extra engineering effort itself -- upda…

Google isn't rewriting more now than they were before, they're just discussing the use of C/C++ for new code. Presumably, if rewriting chunks of code were enough in its own right, they would never have had so many critical security flaws.

I also agree that it's a presumption. I don't know that I agree with it is all. It seems like more engineering attention and excitement is actually good for project quality, and maybe that's a confounding factor here. More data would help, though all this might never be definitively conclusive.

Re: Memory Safe Languages in Android 13

#536

Post by UncleMeat »

humanrebar wrote: post #533
UncleMeat wrote: post #506

Earlier quoted context omitted.

//third_party is indeed a challenge, but it is definitely not the case that vulns are only coming from //third_party. I mean, the linked article is about the Android codebase (not attached to //third_party) and the Chrome codebase publishes a ton of vuln data (again, not attached to //third_party).

I was saying Google might be pessimistic about C and C++ for some reasons specific to Google culture, like inability to get engineers to care about "boring" work. I wasn't making the point you're addressing.

I assure you that "fix vulns caused by memory safety issues through some means other than a total language shift" is not boring work, but the sort of problem that will happily get people promoted to L8. It is just hard as hell.

One of the people most involved in the systems described in the blog post that are used to harden the C++ side of things is a L9 here.

Re: Memory Safe Languages in Android 13

#537

Post by fiedzia »

cjg wrote: post #447
jstimpfle wrote: post #426

Earlier quoted context omitted.

I'm one of those people who still write in C, and I like the experience. I've had a lot of fun, and haven't been burned by it, although statistically it's likely that I will be at some point. I've tried a lot of languages in the past, and am currently not willing to dive into a whole new ecosystem, re-learn all the best practices, and unlearn what's worked very well for me with sometimes no good replacement. Best pra…

Implementing a linked list in Rust is somewhat challenging because of the safety issues that arise. Luckily you don't have to, there's one in the standard library: https://doc.rust-lang.org/std/collections/struct.LinkedList.... The equivalent of a generic memcpy is probably something like a .clone() call on a generic type that implements Clone.

> Implementing a linked list in Rust is somewhat challenging because of the safety issues that arise

Implementing linked list in any language that is not memory-safe is challenging because of safety issues. Rust just points it out.

Re: Memory Safe Languages in Android 13

#538

Post by clnq »

UncleMeat wrote: post #512
clnq wrote: post #348

Earlier quoted context omitted.

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

"std::make_" isn't a great comparison (IMO) because Google has a widespread culture of noexcept so it wasn't critical to adopt this style for constructing smart pointers. std::unique_ptr (new Foo()) was a thing for a while there. There is also an alternative absl::MakeUnique that was available before we had std::make_unique available internally so you'll need to search for that too. The style guide, C++ readability,…

Yes, there are more examples of smart pointer initialization than just std::make_. I couldn't find instances of "absl::Make" in Android Code Search. But your point still stands, and I should add that not all new-delete pairs are evil. With that said, what I've seen still has too many raw pointers.

Thanks for the context about UAF. I am curious about this. Much of my C++ experience comes from working with in-house reimplementations of std/stl, so my question might be a bit stupid, but how is use after freed of an obj managed by smart pointers so prevalent? Should the smart pointer not be nulled after the object is destroyed? Maybe you have a good example CVE? Are these cases of using the raw pointer in the smart pointer without checking it first?

Re: Memory Safe Languages in Android 13

#539

Post by lolinder »

kasabali wrote: post #419
nequo wrote: post #27

Earlier quoted context omitted.

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?

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.

Re: Memory Safe Languages in Android 13

#540

Post by fiedzia »

raxxorraxor wrote: post #517
logicchains wrote: post #352

Earlier quoted context omitted.

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

> self-righteous, dogmatic community. Worst Rust feature by far. I understand how Rust solves some problems and these are indeed very important ones. But it still is a constraint that has to prove itself. C is horrible, out of the question. Really dated too without thousands of band aids. C++ has millions of those. But why not start re-implementing stuff in Rust if that is so close to your heart? We can also reimplem…

> We can also reimplement everything in JavaScript

Look at js package stats - that's exactly what's happening. Many of apps and packages created today in js would be created in C/C++ few years ago. People who learn programming today don't know what C/C++ is. If they need something low-level, it's Rust.

Post reply on HN