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

511–520 of 606 posts

Re: Memory Safe Languages in Android 13

#511

Post by UncleMeat »

Xorlev wrote: post #362
logicchains wrote: post #355

Earlier quoted context omitted.

>If they’re saying that C++ can’t be saved, maybe they’re worth listening to. Google's one of the worst C++ shops because their code standard basically forbids using modern C++, and their C++ is more like 90s Java than modern C++. It's no wonder they want to get away from it.

I...what? I write C++ at Google, and it encourages use of modern C++ features, and many things you see adopted in std have roots in our libraries. I'm curious what you think Google prevents us from using and why you think our C++ is like 90s Java. https://abseil.io/tips has a lot of our philosophies and abseil is chunks of our internal libraries published externally.

I've weirdly heard people say this in the past too and I am equally baffled.

I think it stems from the fact that Google was slow at making C++11 available internally so there was a period of time where the rest of the world was using smart pointers and we couldn't. That may have just solidified a "Google uses old C++" meme out in the wild despite it being wildly out of date.

Re: Memory Safe Languages in Android 13

#512

Post by UncleMeat »

clnq wrote: post #348
raggi wrote: post #343

Earlier quoted context omitted.

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 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, and general code review has all but banned raw "new" for years and years. You can find plenty of CVEs where the root cause is a UAF on a managed object.

Re: Memory Safe Languages in Android 13

#513

Post by bluGill »

mk89 wrote: post #159
bluGill wrote: post #149

Earlier quoted context omitted.

Rust would have prevented about half of the CVEs in C code (I've seen a few different studies with somewhat different results, half is close enough for discussion). The other half is on you to write good code. Note that the half Rust would prevent tends to be less impactful, still a CVE, but the exploit is less impactful to end users.

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), and it is on me to bounds check. Then the users of my interface don't use unsafe because I did all the nasty parts and their code is easy to write well.

Re: Memory Safe Languages in Android 13

#514

Post by bluGill »

saagarjha wrote: post #313
bluGill wrote: post #146

Earlier quoted context omitted.

> Is there any practical programming language that is memory safe in its "entirety"? This isn't possible. Eventually you are sitting at a block of memory and need to write the allocator. Maybe (like python) your allocator is written in C and you hide it, but there is always something that isn't memory safe sitting under your language. You could write a language for an actual Turing machine which since it has infinite…

Sure, but the language doesn’t have to expose it to you. There’s a bunch of other processes running on your system too aside from your program, but the OS prevents you from scribbling all over their address space.

Rust is a system programming language. If I have a new idea for an allocator they want me to write the experimental version in rust. If you never write an allocator and other such tricks you don't need unsafe - you could use one of the other languages. Java doesn't have unsafe, but you cannot write a custom allocator in java (well you can, but it will by a manual process to use it - you have to drop back to C if you want java to use your custom allocator by default)

Re: Memory Safe Languages in Android 13

#515

Post by UncleMeat »

ncr100 wrote: post #337
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…

Members of the C++ community are working on fixing that. The Herb Sutter CPP2 idea: https://www.youtube.com/watch?v=ELeZAKCN4tY

cpp2 is more about freeing c++ from its syntax nightmare rather than making it a safe language to work with.

Re: Memory Safe Languages in Android 13

#516

Post by raxxorraxor »

Gigachad wrote: post #282
gnull wrote: post #207

Earlier quoted context omitted.

> 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 This says more about those C++ defenders.

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…

Meh, bad argument. How about you write better code in Rust to replace existing stuff. There is so much more to consider and I think one of Rusts most repellent features is the preaching about its advantages. I definitely has some that are hard to deny. Still... how about just doing it, nobody is held hostage here.

Re: Memory Safe Languages in Android 13

#517

Post by raxxorraxor »

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.

> 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 reimplement everything in JavaScript. It is memory safe too. Wait, where is the enthusiasm now?

Re: Memory Safe Languages in Android 13

#518

Post by steveklabnik »

kaba0 wrote: post #493
steveklabnik wrote: post #485

Earlier quoted context omitted.

Rust absolutely gives you control over alignment, padding, and ordering. It’s just not the default. Ask for those things and you shall be given it.

Could you point me to some resources on that? I only know about #[repr] options, but that isn’t absolute control (e.g. for having structs usable from rust and internal asm)

What is “internal assembly”? I’m not familiar with that term.

Is there anything else that the various repr options don’t give you? My team at work does OS dev in Rust, and haven’t ever run into cases where Rust can’t do what we need it to do in these cases.

Re: Memory Safe Languages in Android 13

#519

Post by raxxorraxor »

tialaramex wrote: post #346
afdbcreid wrote: post #267

Earlier quoted context omitted.

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

> It was easier in the CLR not to do that

This has also advantages in that you don't need to allocate the struct in a coherent memory block. Edge case of course, but there are domains where this is relevant.

There was an allocation bug once because unsafe code needs to be allocated consecutively but most memory checks that only returned available memory failed to account for fragmented memory.

Post reply on HN