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

401–410 of 606 posts

Re: Memory Safe Languages in Android 13

#401

Post by pkolaczk »

goodpoint wrote: post #150
kllrnohj wrote: post #147

Earlier quoted context omitted.

I can't speak to the others, but Java & Kotlin do not at all have C++-like performance, especially not in anything beyond a toy level benchmark. And even in those toy level benchmarks (like https://benchmarksgame-team.pages.debian.net/benchmarksgame/... ), there's a clear divide between C/C++/Rust & everything else.

The claim that performance are comparable only on "toy benchmarks" is false. Additionally, most of such simple benchmarks are not representative for real-life workload, and anyways the initial point was about safety. Anyhow the whole HN conversation is now a trainwreck where any dissenting opinion is downvoted so there's no point to continue.

Toy benchmarks give JVM an edge because JVM optimizes code locally. Small amount of code in a benchmark means a majority of it can be inlined and then the JVM can actually remove a lot of Java-specific overhead like heap allocations, at least theoretically (I've seen it utterly fail in some cases even on toy benchmarks, though). However in bigger programs JVM has no way to optimize the inherent overheads stemming from the design of the Java language.

Rust and C++ don't have those overheads from the start, and then on top of that their compilers can do whole program optimization because they have plenty of time and resources to do so.

Re: Memory Safe Languages in Android 13

#402

Post by kaba0 »

chlorion wrote: post #278
kllrnohj wrote: post #120

Earlier quoted context omitted.

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…

There were (or are?) some older call of duty games being sold on steam that had unpatched RCE vulnerabilities in them. Simply joining a server ran by a malicious host can result in the players system being totally compromised. These games would go on sale once a year or whatever and attract new players, and people would post warnings in the steam forums and whatnot to try to stop people from being effected by the iss…

That’s why managed languages in itself are not enough. Security on desktop OSs are a joke, with perhaps mac being a bit ahead than the rest.

But especially desktop linux.. every random bash script could encrypt your documents, or leak out your browser cache, do whatever it wants..

Re: Memory Safe Languages in Android 13

#403

Post by HideousKojima »

chlorion wrote: post #278
kllrnohj wrote: post #120

Earlier quoted context omitted.

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…

There were (or are?) some older call of duty games being sold on steam that had unpatched RCE vulnerabilities in them. Simply joining a server ran by a malicious host can result in the players system being totally compromised. These games would go on sale once a year or whatever and attract new players, and people would post warnings in the steam forums and whatnot to try to stop people from being effected by the iss…

Similarly there was an RCE discovered in Dark Souls III about a year ago. And even though modders had s fix for it before the details of the exploit were even publicly revealed, it took the devs 8 months or so to finally fix it.

Re: Memory Safe Languages in Android 13

#404

Post by wiseowise »

Gigachad wrote: post #285
wiseowise wrote: post #53

Earlier quoted context omitted.

Cool kids and students move to Rust, C++ doesn’t have influx of new developers hence more demand for existing C++ developers.

We haven't seen the same thing for PHP and other obsolete languages. Cleanup janny work isn't as respected or well paid as building cutting edge new things in modern tools.

Right, all those HFT, ML, Aerospace, Gaming, auto industries written in PHP, how could I forgot about those.

Re: Memory Safe Languages in Android 13

#405

Post by kaba0 »

eklitzke wrote: post #254
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…

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

Yeah, Rust is basically modern C++ idioms made mandatory by the compiler (move, copy semantics).

Re: Memory Safe Languages in Android 13

#406

Post by kaba0 »

burntsushi wrote: post #25
cyber_kinetist wrote: post #18

Earlier quoted context omitted.

Rust (despite the common understanding) is not a memory-safe language in its entirety. It is a language designed to have a strict division of safe/unsafe which makes it easier for developers to compartmentalize code to achieve memory-safety.

Is there any practical programming language that is memory safe in its "entirety"? Python, for example, certainly is not. It has unsafe escape hatches (via ffi, at the very least). Yet, everyone I know of says and thinks of Python as a memory safe language. I do as well. > which makes it easier for developers to compartmentalize code to achieve memory-safety The problem here is that this is incomplete. Many many many…

Well, there is still an important difference between Java and Rust — are you driving with a guardrail on a field vs are you driving next to a cliffhanger.

The JVM has well-defined bad execution as well, e.g. data racing is well-defined. Safe Rust does prevent data races statically, but if they do happen due to a bad unsafe block, you are entirely on your own. While memory safety can abruptly stop both processes, FFI is very rare in Java, it is an almost completely pure platform being Java all the ways down, so in my experience the former is safer from this aspect.

Re: Memory Safe Languages in Android 13

#407

Post by jillesvangurp »

insanitybit wrote: post #8

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.

I think this indeed echoes similar experiences and studies at other large companies (e.g. Apple, Microsoft, Meta, etc.) regarding the characteristics of their recent investments into rust code vs. C/C++ code. I don't think it is surprising to anyone at this point. But it is nice to see it re-confirmed.

Re: Memory Safe Languages in Android 13

#408

Post by KMag »

harry8 wrote: post #369
raggi wrote: post #349

Earlier quoted context omitted.

WireGuard is a recent and prominent example of a system that has been formally verified ( https://www.wireguard.com/formal-verification/ ). There are implementations in a variety of languages due to integration considerations. You will find at the bottom of that page C implementations of curve25519 that are proofed and derived from F* and Coq. Curve25519 is a relatively simple implementation and only one part of any…

Now that is interesting. I didn't know that and will have to look further to understand what it means. Wireguard seems to be written almost entirely in C, is that right?

The symbolic proofs of the protocol are independent of the implementation. The portions of the implementation that are formally verified are written in F* and Coq, and emitted as machine-generated C.

Re: Memory Safe Languages in Android 13

#409

Post by kaba0 »

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…

> You need unsafe.

You beed it for that feature. It is questionable whether you really want to mandate a special memory layout (because you can’t really do that even in Rust, you don’t have explicit control of struct alignments, paddings, order(!) )

Re: Memory Safe Languages in Android 13

#410

Post by kaba0 »

kllrnohj wrote: post #131
dahfizz wrote: 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.

> I think a distinction can be made in that you never really need to use unsafe operations in python or Java. You can't write any code at all in Python or Java without relying on unsafe operations. Both of them have their runtimes written in C/C++. So based off of this unusual line of reasoning, Rust is strictly more memory safe than either of those as it's at least possible to have a Rust program without any unsafe…

I’m not sure going down this road is meaningful because as soon as we get to machine code generators you get a “reset” on safety, no matter the language you implement a compiler in, it can have logic bugs which will result in many sort of serious bugs, including memory ones. This is true of both the rust compiler and Java’s JIT compiler.

Interpreters and the rest of the VM is a different beast, while they also have to be bootstrapped from some unsafe language one way or another, they are usually written in a much more expert, security- and correctness oriented way than your average program. So while they can and do have bugs, they are exceptionally well tested and, well, I wouldn’t expect the JVM to die out under my program the same way you don’t really expect the kernel to freeze either. This is also true of Rust stdlibs, I assume, but is it true of third party libs?

Post reply on HN