Live data from Hacker News

Memory Safe Languages in Android 13

security.googleblog.com

251–260 of 606 posts

Re: Memory Safe Languages in Android 13

#251

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.

As somebody who appreciates Lisp, I feel your pain. As somebody who also appreciates Rust, I'm curious, what is your baseline?

Good design theory.

https://www.doverbooks.co.uk/point-and-line-to-plane

Consider h::i::j::k versus h.i.j.k

Two :’s is an extremely loud combination of visual elements compared to the subtle point. :: drags the eye away from the content and says “look at me oscillate”

In addition, humans group similar visual elements together so a combination of anything::doesnt::matter::what::between::clumps it is impossible to escape the common pattern and the eye jumps between the ::’s. Therefore it takes double the cognitive load to read.

What’s worse, the eye gets trapped within each :: because it’s a combination of four dots, which naturally creates an implied circular pattern which draws the viewer in further.

Compare to something like: use HashMap from std.collections

Or… more obviously the python import statements.

Re: Memory Safe Languages in Android 13

#252
post #225

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…

Seems like drawing too many conclusions from evidence while arguing against a straw man? Defenders of C might note that Android is java and IOS is not and compare the security of those two systems and say clearly memory-safe is focusing on the wrong thing. This is equally true but no more valid an argument. The one that really bothers me in all these language-booster discussions (that we should and need to have) is t…

> We have no ssl library written in a memory-safe, functional language that has been proven correct that has dominated the space. Heartbleed wasn't yesterday.

Heartbleed didn't affect https://hackage.haskell.org/package/tls even though it isn't formally verified.

Re: Memory Safe Languages in Android 13

#253
post #225

Earlier quoted context omitted.

Seems like drawing too many conclusions from evidence while arguing against a straw man? Defenders of C might note that Android is java and IOS is not and compare the security of those two systems and say clearly memory-safe is focusing on the wrong thing. This is equally true but no more valid an argument. The one that really bothers me in all these language-booster discussions (that we should and need to have) is t…

> We have no ssl library written in a memory-safe, functional language that has been proven correct that has dominated the space. Heartbleed wasn't yesterday. Heartbleed didn't affect https://hackage.haskell.org/package/tls even though it isn't formally verified.

Does anybody at all use that library in production at scale, ever? Genuine question. Maybe they do?

Why hasn't this really good result meant _everybody_ now uses that library by default and has to justify using something else?

There is something here not being discussed, what is it?

Re: Memory Safe Languages in Android 13

#254

Glad to see robust work here. This strongly supports what should already be obvious, but sadly is not always understood; that memory safe languages are radically safer than memory unsafe languages. The impact is blatantly demonstrated here.

When Heartbleed was a topic of discussion, some pointed out that Rust wouldn't have 100% protected from that vulnerability. So it is good to see some proof that using a safer language does in fact pay off in terms of fewer defects. I just wish there were some info around cost associated with development effort. Did the Rust code take longer to develop? If initial development was longer, what if we include time saved…

Rust and C++ are about equally difficult (or easy) to program in, the languages are much more alike than they are different.

Re: Memory Safe Languages in Android 13

#255

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…

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.

Re: Memory Safe Languages in Android 13

#256

Earlier quoted context omitted.

I was responsible for that decision, and I'm also a typographer (worked for years on vector rendering of fonts). :)

What reason were used to not use what C# has? It’s infinitely less noisy than Rust’s ::

Using a separate character for namespace resolution and field indexing allows you to have a module with the same name as a value.

Re: Memory Safe Languages in Android 13

#257

Earlier quoted context omitted.

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

They focus on quality control and compliance to safety requirements in specific domains and industries, for instance MISRA.

Re: Memory Safe Languages in Android 13

#258
post #77

Earlier quoted context omitted.

I think a distinction can be made in that you never really need to use unsafe operations in python or Java. In rust, you need unsafe. Just about every data structure in the stdlib uses unsafe. I think it's fair to call Rust a memory safe language. But I don't think it's on the same tier as a fully managed language like python.

One could implement many data structures without unsafe, but with less efficiency. E.g. using an arena allocator

I would like to dispute the "with less efficiency" simplification, because depensing on the size and usage patterns of your code, a doubly linked list or sikilar graph datastructure, backed by an arena will be faster than the way those data structures appear in books.

Re: Memory Safe Languages in Android 13

#259
post #226

Earlier quoted context omitted.

Security is absolutely a concern in these areas (except maybe offline graphics). In my experiences with university HPC clusters, security is very important because you have a lot of young students with no Unix experience accessing the resources. We've had real compromises of individual research machines because of this. This happens all the time at research universities, but it's not always public. In one public exam…

That's security of the generic infrastructure the code's running under though is it not? It's not security of say CUDA kernel code being executed on a GPU? I'm talking about the actual HPC algorithm code heavily priortising performance (or in some cases memory efficiency), at the expense of pretty much everything else (other than correctness, obviously).

If your high performance code running on a sensitive cluster is vulnerable, then it opens up the rest of the system to exploitation also. How is it a problem of the infrastructure around the code, and not the code itself?

Re: Memory Safe Languages in Android 13

#260

Earlier quoted context omitted.

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

They focus on quality control and compliance to safety requirements in specific domains and industries, for instance MISRA.

This might be of interest https://github.com/PolySync/misra-rust
Post reply on HN