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

291–300 of 606 posts

Re: Memory Safe Languages in Android 13

#291

Post by kobebrookskC3 »

estebank wrote: post #49
stonemetal12 wrote: post #39

Earlier quoted context omitted.

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…

An example from an experiment to benchmark Rust and Java I did recently, where I sent files from one app to another: perf was good enough without tuning, with tuning I could triple the speed and final total time on both versions was comparable. Memory was much greater for Java (even with graalvm). The Rust version didn't suffer from any memory safety issues or race conditions when sending multiple files, but I did ha…

maybe https://docs.rs/cap-std/latest/cap_std/fs/index.html would prevent that?

Re: Memory Safe Languages in Android 13

#292

Post by blub »

Ar-Curunir wrote: post #263
blub wrote: post #248

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…

Yes, C++ was critical to Android in the past, when there was no memory-safe low level systems language that could provide an alternative. Now there is, so they’re using it, and finding benefits, and writing about those benefits. What should they do instead, write an eulogy to C++?

C++ is still essential for Android, but you won’t hear that from the security team bubble.

They should have the dev teams write about the good, the bad and the ugly of using Rust instead of having the security team write a sanitized rainbows and sunshine story.

Re: Memory Safe Languages in Android 13

#293

Post by blub »

Ar-Curunir wrote: post #255
ghostwriter wrote: post #238

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…

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.

They’re not saying that C++ can or can’t be saved. And there’s no “they”, there are hundreds of teams with different expectations and policies.

You’re merely reading what you want between the lines.

Re: Memory Safe Languages in Android 13

#294

Post by clnq »

Ar-Curunir wrote: post #255
ghostwriter wrote: post #238

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…

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 eliminate those types of mistakes. But languages are tools for a job, and only some tools are applicable where C++ is applicable. We should not bury C++ prematurely before answering the question - "what else is as fast and efficient as to replace it for OOP?" And if a project doesn't need fast and efficient code, then why is it using C or C++ in the first place?

Overall, selecting the correct tool for a job is more important than figuring out which tool is better in some abstract way.

Re: Memory Safe Languages in Android 13

#295

Post by blub »

pcwalton wrote: post #67
heather45879 wrote: post #24

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.

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

Parent’s suggestion about typography is nonsense, the Rust project desperately needed somebody with skills in user experience and usability engineering. Now it’s too late.

Re: Memory Safe Languages in Android 13

#296

Post by fiedzia »

mk89 wrote: post #283
fiedzia wrote: post #242

Earlier quoted context omitted.

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

> It is - as long as you don't use unsafe. That's what I tried to show in the previous post: it's just not true, because if you rely even on an unsafe function from the standard library affected by a CVE, you're just fucked as if it was in C, C++ or other languages. The only difference is that you don't know what's happening under the hood and you feel "safe" because that's how they sold the language to you. Until yo…

> When I read memory safe it means that it cannot happen at all, and therefore I don't have to think about that kind of stuff when I write a program.

I've never needed to use unsafe in my Rust applications, which means that my code is 100% memory safe (by Rust definition of course). I expect libraries I am using to provide safe abstractions over unsafe, if there is any there. Sure, there were bugs (including Rust stdlib), but such small scale effectively means that this problems disappeared comparing to languages that aren't safe and that means all I need to do is maybe update some dependency once a year. It's that rare, so I will call it safe and solved problem. We can move to next one (and there are many).

> It'd be more honest to say: it's memory safe until:

Which is what most Rust introductions I've seen will say. I don't think anyone misunderstood this part.

Re: Memory Safe Languages in Android 13

#297

Post by Gigachad »

latenightcoding wrote: post #250

I wonder if their efforts to leverage modern chip capabilities to address memory safety (e.g: ARM memory tagging) contributed to that drop of memory safety vulnerabilities

Looked this up as it's new to me. Seems interesting but not far enough, if you configure it to crash the system on an error for dev only, you aren't going to spot the hard to reach cases which are usually the target of these attacks, and having it set to crash on the release build is likely going to be seen as unacceptable.

Something like Rust which can ahead of time verify that these issues aren't present is a better solution imo. Maybe then we can use this as a last resort check that the usages of unsafe didn't cause issues.

Re: Memory Safe Languages in Android 13

#298

Post by blub »

Manishearth wrote: post #30
heather45879 wrote: post #24

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.

I always say that if the strongest complaint people have about your language is syntax; you've already succeeded.

Syntax is one of the most important characteristics of language.

It’s the difference that makes the difference between Rust-like and C++-like gibberish and poetry.

Re: Memory Safe Languages in Android 13

#299

Post by shpongled »

netr0ute wrote: post #105
shpongled wrote: post #98

Earlier quoted context omitted.

I find it interesting that your complaints are almost totally about the syntax - that is generally the last thing I care about in a language. When I choose languages, I choose them based on semantics, tooling, community/ecosystem, UX, and then maybe syntax

For me, syntax is one of the top priorities because if I can't express what I want using something compatible with how I think, then it doesn't matter if the language has SuperLib 4000 available if I can't program with it.

Personally, the opposite is true for me - case in point: python.

I really dislike both the semantics and syntax of python. However, the scientific computing libraries (pandas, numpy, scipy, scikit-learn, matplotlib, seaborn, etc) are just too productive to turn away from for quick data analysis tasks. If these libraries didn't exist, I wouldn't touch python with a 500-foot pole.

Re: Memory Safe Languages in Android 13

#300

Post by harry8 »

ghostwriter wrote: post #262
harry8 wrote: post #253

Earlier quoted context omitted.

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?

There's a hint it was used at Dell in some capacity 6 years ago, judging by this comment https://www.reddit.com/r/haskell/comments/5gyrdv/what_is_war... The thread discusses "warp-tls" which is a webserver extension that uses that "tls" package as a dependency for TLS support.

Ok but this is surely not compelling evidence of literally anything. Perhaps, in fact, the opposite. This is what we have for evidence and nothing more then WHY???

There is something here, at least one thing, that seems to be dominating outcomes, and is not being discussed.

Nobody has even a half-suggestion of what it might be and that is not making it (or them) go away as problems that are not being solved.

Post reply on HN