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

431–440 of 606 posts

Re: Memory Safe Languages in Android 13

#431

Post by hardware2win »

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…

Languages encourage or prevent its users from doing things

Concepts like sugar syntax and syntax salt do exist

Approaches to problems may vary by languages because lang environment shapes its users in some ways

Re: Memory Safe Languages in Android 13

#432

Post by pkolaczk »

masklinn wrote: post #184
nneonneo wrote: post #111

Earlier quoted context omitted.

Also, there are several different ways to pass self: `self`, `mut self`, `&self`, `&mut self`, and they have very different semantics. Rust could have taken the C++ route here: `fn static foo()`, `fn foo()`, `fn mut foo()`, `fn &mut foo()`, etc. but I feel like the explicit `self` is very clear and easy to understand.

> Rust could have taken the C++ route here: `fn static foo()`, `fn foo()`, `fn mut foo()`, `fn &mut foo()`, etc. `fn Box foo()`? `fn Arc foo()`? It also requires more parser lookahead. The `mut` case is also very odd, as it's not part of the function API (it just configures the binding of the internal local). Plus if self was implicit it likely would need to be a keyword, so that wouldn't be a usecase at all anymore.

IMHO that would be a dead end. I prefer passing self explicitly and I still hope it will be possible to bind self partially in the future, e.g bind only one field. Currently if you call a function that e.g returns a reference to a field, the compiler borrows the whole self, not the field. So partial borrows are supported partially : they can't cross function boundaries.

Re: Memory Safe Languages in Android 13

#433

Post by jstimpfle »

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.

strncpy doesn't do what you want. Maybe you mean snprintf. Indeed use of sizeof, memcpy, and snprintf. Avoid strlen, it is rarely necessary.

Re: Memory Safe Languages in Android 13

#434

Post by tulio_ribeiro »

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…

Ah, yes, the age-old debate of memory safety vs. total bug count. It's like choosing between having a really bad headache or a really bad cold - either way, you're still feeling pretty lousy. But in all seriousness, I think Google's data shows that prioritizing memory safety can have a significant impact on the overall security of a product. I'm sure the C/C++ defenders will continue to argue their case, but at least now they have some hard numbers to contend with.

#RustForTheWin

Re: Memory Safe Languages in Android 13

#435

Post by tulio_ribeiro »

ghostwriter wrote: post #238
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…

> and argue that this means it's not worth the hassle of switching to a new language. Defenders of C++ argue that there's no reason to change the language, because new features around safety guarantees are being introduced into every C++ standard starting from C++11 at a remarkable pace, so remarkable that compilers implement them faster than the existing adoption rate. And the adoption rate speaks volumes about exis…

While new safety features in C++ may be impressive, Google's data shows that memory safety vulnerabilities are still a major issue. Switching to a memory-safe language like Rust can help reduce the risk of vulnerabilities and improve the overall security and reliability of a product. The potential benefits make it a worthwhile investment, even if it requires some effort to migrate from C++. #RustIsTheRealDeal

Re: Memory Safe Languages in Android 13

#436

Post by masklinn »

pkolaczk wrote: post #432
masklinn wrote: post #184

Earlier quoted context omitted.

> Rust could have taken the C++ route here: `fn static foo()`, `fn foo()`, `fn mut foo()`, `fn &mut foo()`, etc. `fn Box foo()`? `fn Arc foo()`? It also requires more parser lookahead. The `mut` case is also very odd, as it's not part of the function API (it just configures the binding of the internal local). Plus if self was implicit it likely would need to be a keyword, so that wouldn't be a usecase at all anymore.

IMHO that would be a dead end. I prefer passing self explicitly and I still hope it will be possible to bind self partially in the future, e.g bind only one field. Currently if you call a function that e.g returns a reference to a field, the compiler borrows the whole self, not the field. So partial borrows are supported partially : they can't cross function boundaries.

Yeah partial borrows are not part of the file system, which makes a lot of sense as it would severely leak implementation details.

I regularly get frustrated but I don’t really see an easy alternative, it’s be a lot of work having it work let alone contextually (e.g. from pub functions for pub fields but not for private types / fields), and how would you even express the borrows / holes?

Re: Memory Safe Languages in Android 13

#437

Post by vineyardmike »

p-e-w wrote: post #368
dralley wrote: post #365

Earlier quoted context omitted.

Well, not exactly. There have been plenty of advancements in bridge / highrise construction over the past 100 years, but in practice we don't go around tearing down old infrastructure that is still functional because it was built with outdated designs and technologies, even when it could theoretically save lives. Buildings get "grandfathered" into meeting code all of the time. Software is not terribly different from…

This isn't primarily about replacing existing software. There are plenty of engineers that argue for continuing to use memory-unsafe programming languages. New projects written in C are being started every day. This is the exact equivalent of physicians continuing to use unsafe medical procedures, and what's worse, many of those engineers defend their dangerous practices by claiming there is no real danger in the fir…

> This isn't primarily about replacing existing software. There are plenty of engineers that argue for continuing to use memory-unsafe programming languages.

> New projects written in C are being started every day.

But it is mostly about existing software, even if its not about replacing existing software. I write C++ code every day. I hate it, and I'd rather not. But I use C++ libraries written by my teammates, and reference implementations in prior C++ work in our past projects, and have a set-up C++ toolchain, and my company even has all sorts of written C++ docs and style guides and linters and macros and ... and ...

Even if we wanted to stop, there's so much extra stuff to consider. I get your point, > and I would want to stop using c++ but most software isn't one-and-done like a surgery. It is a continuous commitment and ongoing operation, it is the tools used, and the knowledge learned, and the libraries built.

> This is the exact equivalent of physicians continuing to use unsafe medical procedures

Plenty of platforms don't support rust. Just because you've improved knee surgery, doesn't mean it works on an elbow... yet. And sometimes you still gotta perform surgery on elbows.

> if the programmer is "smart enough".

Can't defend this, but tbh I've never heard it.

Re: Memory Safe Languages in Android 13

#438

Post by masklinn »

aliceryhl wrote: post #107
optymizer wrote: post #76

As an Android user ever since the T-Mobile G1, I'm a fan of not having my phone remotely exploited via WebView, or with an SMS, or the other million ways there are to interact with a device, so I absolutely celebrate this progress. As an Android developer though, I have to be the one bitter old man yelling at cloud. I was spoiled by Java and Kotlin to the point where I cannot look at Rust and think it's a nice modern…

> Rust is like a truck driver who tried to make a race car that doesn't blow up. Lamborghini originally made tractors.

Still do. Isn’t Clarkson’s stupid big tractor on diddly squat farm a Lamborghini?

Re: Memory Safe Languages in Android 13

#439

Post by jstimpfle »

p-e-w wrote: post #366
awesomeMilou wrote: post #361

Earlier quoted context omitted.

That seems to be a very limited view on the issue, since the stakes with ansthesia related issues are much higher (a human life).

Every human life is directly or indirectly impacted by software. Software controls transport, food and energy production, and all human communication. If all software suddenly stopped working, society would collapse instantly and hundreds of millions of people would die within a year. The attitude "it's just computers, nothing truly important like medicine" might have been viable 40 years ago, but it certainly isn't…

It's not like you make a bad git commit and suddenly the world stops working. There are checks and processes and redundancies that reduce the impact of human error dramatically.

The earth is still spinning, despite so many things not working everywhere. That's not just in software. In every system, there's relatively few single points of failure. As you zoom out, failure points disappear and new ones appear.

Sure, still sometimes someone notices a critical security flaw that's been in there for a while, and that had found its way into large parts of the infrastructure already. (The last one I heard of was not a memory vulnerability).

Re: Memory Safe Languages in Android 13

#440

Post by gnull »

Sirened wrote: post #374
saagarjha wrote: post #306

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. Nitpick, this is not quite true. Memory safe languages are what you should be using in contexts where security and reliability are critical. This is generally the case but there are some contexts where other concerns are genuinely more important. Of course when this is necessary…

writing exploits, for example, is an utter pain in today's safe languages :) C is unmatched in the sheer ease of manipulating raw bytes with some light structuring on top for convenience. I've tried writing exploits in Swift a handful of times but I always gave up after I found myself buried under a pile of UnsafeMutableRawBufferPointers.

You mean, manipulating strings of bytes? Bytes don't have to be memory, you can just use bytestrings in Python or whatever.

Raw memory access is something you normally need to create vulnerabilities, not to exploit them :)

Post reply on HN