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

551–560 of 606 posts

Re: Memory Safe Languages in Android 13

#551

Post by bluGill »

steveklabnik wrote: post #531
bluGill wrote: post #513

Earlier quoted context omitted.

There is a time when you need unsafe. Hopefully those are rare, but most rust projects will need it. (remember Rust is aiming for systems programming, some domains never need unsafe, but others will need it). I'm a c++ guy interested in Rust, my understanding is Unsafe lets me design custom high performance interfaces that do weird pointer tricks (which is needed to interface to the C and C++98 interfaces I work with…

> most rust projects will need it. If you mean "writing unsafe in your codebase yourself," this isn't borne out by the numbers. If you mean "depending on unsafe somewhere in your dependencies" then 100% of Rust code needs unsafe, just like any other language. Interacting with hardware, many operating systems' APIs, these aren't created in a way to guarantee it, and you need to interact with them to do anything.

I'm biased here because I work in embedded where I can't see any way to write code that directly interacts with hardware without unsafe. There are other world out there that I don't know much about.

Re: Memory Safe Languages in Android 13

#552

Post by jstimpfle »

kaba0 wrote: post #550
jstimpfle wrote: post #472

Earlier quoted context omitted.

> Systems programming is a lot about accessing APIs, dealing with all sorts of intricacies like interrupts, different execution contexts So now you need to make your interrupts talk to your Java objects? Is this any safer? Is it easier to get a VM running in your kernel (probably no mean feat to do that in the first place) and you'll never get any concurrency bugs? And if you reduce memory bugs by half, those will be…

An OS will always need some tiny assembly part, as some instructions needed for the kernel simply never gets generated by compilers. Also, an OS itself is pretty much a garbage collector for resources, it could very well reuse/link into its own GC for better performance. Are we really talking about the “price” of managed code, when C code is chock-full of linked list data structures? A list of boxed objects is more c…

Those linked lists give some nice guarantee that significantly simplify a lot of code and give some guarantees that you just can't have otherwise.

Context switching can be expensive, but I don't see what's specific about managed envs about that. Fundamentally you have to have trust in code, and need to have the hardware support to enforce authenticity of the trusted code in order to avoid context switching. A different, promising development to reduce context switches is CPUs growing more and more cores, and more and more kernel resources being available through io_uring and similar async interfaces.

Re: Memory Safe Languages in Android 13

#553

Post by tome »

jstimpfle wrote: post #490
tome wrote: post #487

Earlier quoted context omitted.

> sorry but the extension isn't compatible with the extensions you're already using In nearly 10 years of professional Haskell I've never come across a practical situation where extensions that were mutually incompatible. Can you name any extensions that are incompatible in a way that actually matters in practice?

No, I haven't followed the language in 6 years. I remember there was at least one instance but can't recall. Other extensions significantly change the semantics of language module interfaces in more obtrusive ways than I'd like - compared to say C where it's pretty easy to offer a simple interface. Some of these things would make working in the language pretty painful. I remember trying some library to toy around wit…

> I remember trying some library to toy around with a basic 400 line OpenGL program. It always needed 8 seconds to rebuild at the time.

This is a fair criticism. Compile times are slow.

Extension confusion is not a fair criticism. Extensions typically remove restrictions. They don't create incompatible languages.

Granted, it's a bit annoying to have to turn them all on, one by one. These days one should just enable GHC2021 and forget about language extensions. That saves one having to be Edward Kmett, or from bothering to think about language extensions at all.

Re: Memory Safe Languages in Android 13

#554

Post by spookie »

quotemstr wrote: post #505
p-e-w wrote: post #356

Earlier quoted context omitted.

> NOTE: down to 36% from 65% because of moving from C++ to Rust and other memory safe languages Imagine if in any other field, a process or technology were developed that cuts the number of high-severity issues in half. For example, a modification to the standard anesthesia protocols that demonstrably reduces anesthesia-related fatalities by 50% in clinical practice. And now imagine, in reaction to this revolutionary…

> Utterly unthinkable, isn't it? > Yet in software engineering, this is exactly what has been happening every day for more than a decade. Consider what happened to poor Semmelweis when he discovered in the middle of the 19th century that hand-washing improved medical outcomes: doctors of the time were too proud to accept his results and drove him out of the profession (and to his early grave) rather than change their…

Woah.

A bit much, eh? I write programs in whatever I want as an hobby. Why does that make me a murderer? Everyone needs to chill about this.

Re: Memory Safe Languages in Android 13

#555

Post by kllrnohj »

pkolaczk wrote: post #401
goodpoint wrote: post #150

Earlier quoted context omitted.

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

Toy benchmarks are also a lot easier to write in "C-like" Java instead of "normal" Java. That is, avoiding boxing, interfaces, etc..

Re: Memory Safe Languages in Android 13

#556

Post by vineyardmike »

simiones wrote: post #443
vineyardmike wrote: post #437

Earlier quoted context omitted.

> This isn't primarily about replacing existing software. There are plenty of engineers that argue for continuing to use memory-unsafe programming languages. > New projects written in C are being started every day. But it is mostly about existing software, even if its not about replacing existing software. I write C++ code every day. I hate it, and I'd rather not. But I use C++ libraries written by my teammates, and…

> > if the programmer is "smart enough". > Can't defend this, but tbh I've never heard it. Take a look at this comment: https://news.ycombinator.com/item?id=33824934 > Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them. It is a somewhat common attitude in this type of thread.

> take a look at this comment

It’s hacker news. People say all sorts of inflammatory crap here. I discount anything said here, especially in response to an article about said topic.

If my c++ writing coworker shared that opinion with me, or someone at a conference, that’s be different.

> Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them

I will admit I vaguely agree with this. My company has all sorts of tools that perform basic checks for memory safety and a style guide that is very opinionated. Just because we can’t switch easily doesn’t mean we can’t try to improve as an org.

I don’t avow the belief that any program is truly smart enough/too dumb to make bugs, but I do think the organization maintaining the code has a responsibility to improve. Especially a large organization. Whether that’s better code review processes, automated tooling, or even soft-banning the use of certain unsafe practices.

Re: Memory Safe Languages in Android 13

#557

Post by clnq »

UncleMeat wrote: post #546
clnq wrote: post #538

Earlier quoted context omitted.

Yes, there are more examples of smart pointer initialization than just std::make_. I couldn't find instances of "absl::Make" in Android Code Search. But your point still stands, and I should add that not all new-delete pairs are evil. With that said, what I've seen still has too many raw pointers. Thanks for the context about UAF. I am curious about this. Much of my C++ experience comes from working with in-house rei…

> Should the smart pointer not be nulled after the object is destroyed? I'm not sure what you are going for here. The way this often happens is there is some module that owns an object with a unique_ptr and references to that object are used elsewhere. But the ownership of the object is complicated so a bug sneaks in where a non-owning reference to the object gets dereferenced after the unique_ptr is deleted. You can…

There are also other smart pointers, like std::'s weak ptr and proprietary stuff.

You can avoid multi-ownership problems of shared ptrs with weak pointer member variables (which only need to be turned into shared in a given {} scope). Some other problems can be solved by marking objects as pending kill without destroying them immediately and ensuring all threads finish access before actual deletion.

Unreal Engine uses both weak pointers and object marking in a global object array. It also uses GC but that's besides the point.

Would the same approach to modern memory management not help Android?

Re: Memory Safe Languages in Android 13

#558

Post by vineyardmike »

josefx wrote: post #524
pizza234 wrote: post #494

Earlier quoted context omitted.

The stats come from Google project(s) - you can be sure that they've used the best practices. If they've failed, rest assured that 90%+ of the rest of the devs will fail, and much worse.

> he stats come from Google project(s) - you can be sure that they've used the best practices The first Google Style Guide for C++ I ever came across in the wild espoused C with classes, had "standard" in scare quotes and banned most of boost for encouraging functional programming. I almost threw a fit when someone unironically tried to push that POS at work because "Google", it was entirely nonsensical especially gi…

> someone unironically tried to push that POS at work because "Google"

Especially since Google has a ton of automated tools to perform tests and analysis on code, and enforces certain behavior before you can merge your code in. Something that is probably missing from a smaller organization that’s simply adopting their style guide. Also probably missing is googles alternative stdlib they use.

Re: Memory Safe Languages in Android 13

#559

Post by kaba0 »

burntsushi wrote: post #549
kaba0 wrote: post #497

Earlier quoted context omitted.

As others mentioned, there is no absolute safety, nor memory, no anything. The hardware can have bugs, the verification toolkit can have, or the properties to be verified could have been incorrectly specified to begin with. I’m just saying that corrupting the heap is much easier with Rust than with Java, and there is no coming back from heap corruption on a process basis, while most exceptional cases are recoverable…

> there is no absolute safety Now we've come full circle. I recommend you go back and read my initial comment in this thread and the comment I was responding to. You've veered far off course from there into waters in which we likely have very little disagreement of any consequence. > And Java can have surprisingly good performance Show me a regex engine written in Java that can compete with my own, RE2, PCRE2 or one…

You may be right, I’m not really disagreeing, I can absolutely stand behind this sentence of yours:

> Where Rust is (somewhat although not entirely) unique is bringing this compartmentalization into a context that (mostly) lacks a runtime and garbage collection

I just think that the model of “breaking down” is different between the two platforms and that might matter for some use cases.

Re: Memory Safe Languages in Android 13

#560

Post by modshatereality »

nickm12 wrote: post #360
modshatereality wrote: post #59

is this a good way to spend developer time? How about *removing* all of the middle-man bloatware instead of wasting how many dev-years rewriting it (edit: and effectively making it even LESS maintainable now that it's in some new niche language with a vastly smaller dev pool). just give me the direct linux experience we all deserve instead of this garbo spamflinger middlewear that google leverages to keep you depende…

"...wasting how many dev-years rewriting it" It sounds like you didn't read the blog post. The whole point is that they are not rewriting code, but writing new code in memory-safe languages (including "niche" languages like Java). This strategy is paying off with fewer severe vulnerabilities due to memory safety bugs.

>It sounds like you didn't read the blog post.

where did you get the impression they are not rewriting code in rust? because the author cited some other blog post saying they should focus on new code and not rewriting it? How does that translate to "The whole point is that they are not rewriting code," ???

Obviously they're going to be rewriting whatever they see fit. If YOU actually read the article you would have seen they have "keystore2" listed as new rust code. I WONDER what was keystore1 implemented in? Nice try, but no cookie.

Post reply on HN