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

541–550 of 606 posts

Re: Memory Safe Languages in Android 13

#541

Post by clnq »

lolinder wrote: post #530
humanrebar wrote: post #500

Earlier quoted context omitted.

How much of the benefit comes from the rewrite itself? A more precise comparison would be rewriting that C or C++ in the same language but with memory safety in mind and see how things turned out. The same question comes up when an existing system is rewritten from language A to language B and big performance gains are seen. The language could be the big cause, but so could the extra engineering effort itself -- upda…

Google isn't rewriting more now than they were before, they're just discussing the use of C/C++ for new code. Presumably, if rewriting chunks of code were enough in its own right, they would never have had so many critical security flaws.

> if rewriting chunks of code were enough in its own right, they would never have had so many critical security flaws.

Reducing defects is one of the main reasons (others being maintainability, readability, better integration, and similar) for refactoring and rewriting code. There's usually not enough time/money to do it, especially for large codebases.

I quite like rewriting parts of a codebase to modernize it, and I have often closed tons of bugs in a short time this way. It is definitely effective. But not as cost-effective as deprioritizing bugs into "won't fix" territory, which is what many companies like to do.

Re: Memory Safe Languages in Android 13

#542

Post by kllrnohj »

p-e-w wrote: post #356
yosefk wrote: post #199

Earlier quoted context omitted.

It's even worse. The majority, not of all bugs, but all vulnerabilities (of all severities) do come from memory safety bugs. TFA: "For more than a decade, memory safety vulnerabilities have consistently represented more than 65% of vulnerabilities across products, and across the industry." On top of that , memory safety vulnerabilities are disproportionately high severity: "Memory safety vulnerabilities disproportion…

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

> Yet in software engineering, this is exactly what has been happening every day for more than a decade.

Not really. Rust is the first major attempt to achieve c/c++ performance & capability while also being safe.

Prior to that nearly every memory safe language came with crippling tradeoffs, and that is why people rejected them. Especially as performance and efficiency took center stage again with the massive increase in battery powered devices & the general plateau of single core CPU performance over the last decade

Re: Memory Safe Languages in Android 13

#544

Post by bogeholm »

dahfizz wrote: post #134
Ar-Curunir wrote: post #90

Earlier quoted context omitted.

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

Sure, but that is kind of what I mean. Safety in rust is something you actively have to think about and work around (at least some of the time). It doesn't just come for free like in python.

Point is, “for free like like in Python” really means “the C implementation hides that for you”

Re: Memory Safe Languages in Android 13

#545

Post by fiedzia »

peoplefromibiza wrote: post #488
ilyt wrote: post #475

Earlier quoted context omitted.

> Vulnerabilities are not the same thing as bugs, a vulnerability like spectre or meltdown are not due to a bug in the software, have an ubiquitous immediate impact on 100% of the devices and are much harder to fix or mitigate, sometimes it's could even prove impossible. Using language-independent bug example in discussion about language-caused bug vectors isn't exactly honest. Rust would stop Heartbleed for example,…

> Rust would stop Heartbleed for example, and that was one of huge vulnerabilities using a low budget project with few developers maintaining one of the most used libraries in the whole World as an example of non memory safe languages perils is not exactly honest. Heartbleed could have been easily fixed if the companies profiting from using OpenSSL donated a few more eyes to look at the code. Similarly to what happen…

> using a low budget project with few developers maintaining one of the most used libraries in the whole World as an example of non memory safe languages perils is not exactly honest

Why? That's the situation of enormous amount of code people use.

Re: Memory Safe Languages in Android 13

#546

Post by UncleMeat »

clnq wrote: post #538
UncleMeat wrote: post #512

Earlier quoted context omitted.

"std::make_" isn't a great comparison (IMO) because Google has a widespread culture of noexcept so it wasn't critical to adopt this style for constructing smart pointers. std::unique_ptr (new Foo()) was a thing for a while there. There is also an alternative absl::MakeUnique that was available before we had std::make_unique available internally so you'll need to search for that too. The style guide, C++ readability,…

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 prevent this by having literally everything use shared_ptr for everything but that sucks for lots of reasons.

Re: Memory Safe Languages in Android 13

#547

Post by themenomen »

p-e-w wrote: post #380
MBCook wrote: post #372

Earlier quoted context omitted.

> Utterly unthinkable, isn't it? No. Ignaz Semmelweis faced it in the 1800s for daring to suggest (what we know know as germs) made people sick and hand washing could drastically reduce medical complications. He was able to prove it too. By the end was locked up in an asylum for his ‘crimes’. Want more recent? How many stories have you heard of instruments or gauze or whatever left in surgical patients? Of operating…

Semmelweis is ancient history. He was active at a time when regulations and "best practices" simply weren't a thing anywhere. Surgeons resisting checklists is new to me. Do you have a reference other than a TV show? My understanding until now was that checklists are extensively used in medicine.

That IS the central issue though, processes, techniques, and so on are not a THING until they are. And something has to change for that to happen.

Re: Memory Safe Languages in Android 13

#548

Post by lanstin »

ilyt wrote: post #481
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

I vastly prefer "just write you code serially and never worry about async then spawn 10000 goroutines" approach over async/await/Future nexus of bad ideas (just do message passing like Erlang or don't do it at all...), but I wouldn't use Go in place where I'd use Rust and vice versa, they kinda feel different (if overlapping in places) niche

It is very freeing. And one concise readable go routine doing the channel reads and the socket ops becomes your connection pool, but is as easy to understand as a Network programming 101 assignment.

Re: Memory Safe Languages in Android 13

#549

Post by burntsushi »

kaba0 wrote: post #497
burntsushi wrote: post #465

Earlier quoted context omitted.

I don't have much Java experience, so I'll have to take your word for it. But it's not completely obvious to me that you're correct. We've moved from an absolutist idea of memory safety to trying to build an implicit ontology of tiers of memory safety based on usage. Now you're talking about going and doing surveys of code and trying to measure the relative frequency of certain things and then using that to drive a t…

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 of a number of production grade regex engines written in C, C++ or Rust. I'm not aware of any.

That Java can "have surprising good performance" is not a statement I'd ever disagree with in general terms. That has absolutely zero to do with anything I've written in this thread (or elsewhere, ever).

Will all due respect, I think you've lost the script here.

Re: Memory Safe Languages in Android 13

#550

Post by kaba0 »

jstimpfle wrote: post #472
gnull wrote: post #444

Earlier quoted context omitted.

Is this a joke? Systems programming is a lot about accessing APIs, dealing with all sorts of intricacies like interrupts, different execution contexts, and managing memory as you said. If you write in C and your program is complex enough, you will spend a lot of time just chasing segfaults and concurrency bugs and getting it to work the first time you write it. If your systems programming is in userspace, that's sort…

> 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 cache-friendly than that. It is simply not always that performance sensitive to begin with (e.g. does it really matter if it queries the available display connectors in 0.0001s or 10x that?)

Regarding MirageOS, they actually achieved better performance by using a managed language than contemporary C OSs for select tasks. This is possible due to context switches being very expensive, and a managed env can get away with (some?) of those.

Post reply on HN