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

391–400 of 606 posts

Re: Memory Safe Languages in Android 13

#391

Post by insanitybit »

kobebrookskC3 wrote: post #291
estebank wrote: post #49

Earlier quoted context omitted.

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?

Capabilities are a good way to mitigate this problem, yes. At minimum cap_std::fs would prevent "../" attacks.

"../" attacks are also just way less of an issue when you shove your programs into minimal containers, which at this point is more or less standard practice.

Re: Memory Safe Languages in Android 13

#392

Post by galangalalgol »

j16sdiz wrote: post #381
aswanson wrote: post #328

Earlier quoted context omitted.

In real-time systems with millions of lines of code, no debugging capabilities outside of logs, and user misuse use cases, you'd be surprised what can lurk beneath.

In my experience, a good, auto, code formatter helps alot. You can’t hide a semi colon from code formatter.

Are you suggesting a code formatter as a mechanism for static analysis? There are really good tools like coverity, and free ones like cppcheck and clang-tidy that will catch that and so much more. Using c++ without cppcheck and clang-tidy in your cmake and pipeline is like leaving the seat up. It takes so little time, and the benefits to others is great.

That said, they won't catch a ton of memory and thread safety issues. You'll need tests with 100% coverage for that. Or you could just write it in rust and the compiler will catch it.

Re: Memory Safe Languages in Android 13

#393

Post by pjmlp »

Jweb_Guru wrote: post #281
pjmlp wrote: post #275

Earlier quoted context omitted.

There are at least three Java runtimes written in Java, Jikes RVM, MaximeVM, and GraalVM.

At least two of which use an unsafe dialect of Java for significant parts of the runtime, which I'm pretty sure you know well (maybe not Graal, but if not it's because it's bootstrapping on top of existing unsafe code).

Easy localizable via grep, and not full of UB and memory corruption issues, which is what the 70% of unsafety issues due to memory corruption on C, C++ and Objective-C relate to.

At some level of the stack some Assembly or compiler intrisics are needed, not at every line of code.

Re: Memory Safe Languages in Android 13

#394

Post by kaba0 »

logicchains wrote: post #352
Gigachad wrote: post #282

Earlier quoted context omitted.

C-nile developers have been making incorrect arguments for a while now. 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. OS and security sensitive components are the prime targets for rewrites in more secure languages. Now Google has put this to the test and has the data to prove it. We should not allow the worlds technology secu…

>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. Not everybody is writing security-critical code. For some things productivity and time-to-market is more important and security is not enough of a concern to justify dealing with a language with horrible compile times and a self-righteous, dogmatic community.

Which memory-unsafe language is more productive and has faster time -to-market than any managed language?

Re: Memory Safe Languages in Android 13

#396

Post by kaba0 »

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.

Google’s C++ coding guide is (was?) not really up-to-date, so there is that.

Modern C++ is indeed a huge upgrade on what came before and with a good amount of static and dynamic analysis the state of low-level programming is much better now, but there really is no reason for new programs to be written with these. Besides the bottom of the stack, managed languages are more than fast enough for nigh everything.

Re: Memory Safe Languages in Android 13

#397

Post by HideousKojima »

raggi wrote: post #338
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…

> We should not bury C++ prematurely before answering the question - "what else is as fast and efficient as to replace it for OOP?" We have an answer: Rust. It's no longer premature, bury it.

Rust isn't OOP though. Structs, traits, etc. let you approximate some aspects of OOP, but not much more than plain old C does.

Re: Memory Safe Languages in Android 13

#398

Post by kaba0 »

unrealhoang wrote: post #385
j16sdiz wrote: post #383

Earlier quoted context omitted.

Rust is over engineered in some area, immature in other. See how many reference types are there, how async is handled and the underspecified unsafe semantic. For higher level tasks, I prefer a language with GC like go or java. Rust can work with references counting, but it don’t mix well with the larger ecosystem. For lower level task, the underspecified unsafe model make it worse than C aliasing problem

> See how many reference types are there, 2, & and &mut. What else?

I guess parent meant ARC, RC, and the like.

Re: Memory Safe Languages in Android 13

#399

Post by Mesopropithecus »

heather45879 wrote: post #251
Mesopropithecus wrote: post #78

Earlier quoted context omitted.

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

Cool, thanks! This sticks out from PL syntax criticism that goes along the lines of "not enough curly braces" etc.

Re: Memory Safe Languages in Android 13

#400

Post by kaba0 »

berkut wrote: post #189
masklinn wrote: post #158

Earlier quoted context omitted.

> But if "security" isn't remotely a concern for a given project (like almost anything graphics / gaming related) Gaming platforms have gotten a lot less lenient over time, and with pretty much every game these days having online components, "security isn't remotely a concern" has become a lot less true.

Sure, but then there's things like HPC / offline graphics / simulation (VFX/CG), where performance is the end-all concern (or memory efficiency sometimes at the expense of CPU time), and security isn't a concern at all there, with lots of things like random index lookups into sparse arrays / grids, etc. I know for a fact that bound checks do make a bit of a difference there, as the data's random, so the branch predic…

That’s why default bound safety with optional unsafe access is a thing. Remove bound safe access after measuring its performance impact. But one should start with the safe thing, as for most part of even HPC, it doesn’t really matter (not everything will be the hot loop).
Post reply on HN