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

241–250 of 606 posts

Re: Memory Safe Languages in Android 13

#241

Post by estebank »

kllrnohj wrote: post #120
cryptonector wrote: post #38

> Safety measures make memory-unsafe languages slow > > Mobile devices have limited resources and we’re always trying to make better use of them to provide users with a better experience (for example, by optimizing performance, improving battery life, and reducing lag). Using memory unsafe code often means that we have to make tradeoffs between security and performance, such as adding additional sandboxing, sanitizer…

No it isn't. It's just evidence that it's a trade-off you might want to make in order to achieve some other goal, specifically security. But if "security" isn't remotely a concern for a given project (like almost anything graphics / gaming related), this is not at all evidence for changing anything. It could be that Rust's optimizer eliminates the bounds checking so regularly as to be a moot point, but this isn't say…

It's not just about bounds checks. I am way more agressive about borrowing fields of other types, particularly mutable borrows in ways that I wouldn't attempt in C to protect myself from future code from breaking invariants I'd have to rely on. This means I can write the hyper optimized version of an algorithm on any language, but I'm more likely to even attempt it in Rust.

Re: Memory Safe Languages in Android 13

#242

Post by fiedzia »

mk89 wrote: post #104

I am not a Rust or C++ fanboy, and I am happy that we are moving towards a future where there are less memory bugs, but… are we really? - https://www.infoq.com/news/2021/11/rudra-rust-safety/ - https://cve.report/vendor/rust-lang And you can find online similar links and research on the topic. All it takes is that you use that specific piece of code at the wrong time, and that’s it: your system which you once believe…

> they told you that Rust is a memory safe language and you don’t need anything else than the rust compiler - this is how I find 99% of today’s articles about Rust.

It is - as long as you don't use unsafe. Which is very rare, so we've made huge progress here already. Validation for cases where unsafe is necessary is needed and welcomed, but doesn't change the fact that 99% safe Rust is much better than 100% unsafe C/C++.

> Again, there is no way of escaping bad programming and bad practices, no matter which language you use.

Escape entirely maybe not. Eliminate most of it - definitely.

Re: Memory Safe Languages in Android 13

#243

Post by lolinder »

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…

> The new stacks also tend to have fewer custom static code quality analyzers from third-party vendors, and they are used a lot in mission-critical C++ codebases.

Are these static code quality analyzers detecting code quality problems that Rust and company are also vulnerable to? Or are they mostly looking out for the hundreds of legacy footguns that C++ still officially supports?

Re: Memory Safe Languages in Android 13

#244

Post by estebank »

berkut wrote: post #218
yosefk wrote: post #203

Earlier quoted context omitted.

Everybody who works with Maya, Flash (now Adobe Animate) etc. knows that they crash all the time, and often corrupt files so you back them up every hour or so. Carmack insists, in a gaming context, to run heavyweight, high-false-positive-rate static analyzers because users don't like crashes. When C++ dies (which in 20 years it will, and I wasn't that hopeful 20 years ago), people will look in the same bewilderment a…

At least in VFX, at the high-end Maya's only really used for modelling/UVing/layout now, other apps have taken over the rendering/lighting side of things... But anyway, in my experience a lot of the crashes are often due to quickly hacked together plugins for the various DCCs written for artists, that don't have good error checking or testing, and it's not completely clear to me how that situation's going to improve…

panics can be caught and the presence of those unwraps come with enough data that filing a bug report upstream is helpful enough to fix the bug.

Re: Memory Safe Languages in Android 13

#246

Post by hinkley »

gnull wrote: post #207
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…

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

You can judge a person by the company they keep.

Re: Memory Safe Languages in Android 13

#247

Post by mark_l_watson »

How does Swift compare to Rust in safety? I read that Swift is only memory safe in single threaded environments, which is not ideal.

I was very enthusiastic about Rust about 4 years ago but decided to learn Swift instead as a new “cool non-Lisp language” to learn. Seeing an recent article on writing Python in Rust made me wish that I had chosen differently.

I found this article made me feel better about security. I expect that increasing use of memory safe languages will lock down public infrastructure and software, making everyone safer.

Re: Memory Safe Languages in Android 13

#248

Post by blub »

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 and not a development team. Same pattern as with Microsoft: security specialists tend to get obsessed by their subject matter (just like many Rust programmers), end up hating C and C++ and see them as the source of all problems (just like many Rust programmers).

In reality, C and C++ were the saviors of Android and Google reluctantly had to conjure the NDK to make up for a severe lack of performance compared to the iPhone. Note how even in the current Android they mention improving the UI performance and having less “jank”. Without C++ Android would have been DoA, but it doesn’t look like there will be a blog post thanking C++ any time soon :-)

I can’t take seriously reports about the benefits of a tool that don’t mention any of the downsides. When the devs post a blog cursing the troubles they had getting Java and C++ and Rust to work together and pitying themselves for having to read both C++ and Rust, then we’ll be getting closer to the truth.

Re: Memory Safe Languages in Android 13

#249

Post by berkut »

estebank wrote: post #244
berkut wrote: post #218

Earlier quoted context omitted.

At least in VFX, at the high-end Maya's only really used for modelling/UVing/layout now, other apps have taken over the rendering/lighting side of things... But anyway, in my experience a lot of the crashes are often due to quickly hacked together plugins for the various DCCs written for artists, that don't have good error checking or testing, and it's not completely clear to me how that situation's going to improve…

panics can be caught and the presence of those unwraps come with enough data that filing a bug report upstream is helpful enough to fix the bug.

Sure, but that (we do it) happens currently with C/C++ and signal handler traps which gather the callstack and collate them: the issue isn't usually that we don't know the crashes aren't happening or having the call stacks - the issue is hacky code that was written for one purpose is now being used for other things it wasn't designed for (because it is useful to artists, despite its limitations), and there isn't the time to go back and write it properly for the new expanded use-case. That's my point: a new safer language isn't going to improve much in this area without more development time provided to write better code, given the time constraints are going to be the same as they are currently.
Post reply on HN