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

261–270 of 606 posts

Re: Memory Safe Languages in Android 13

#261

Post by estebank »

berkut wrote: post #249
estebank wrote: post #244

Earlier quoted context omitted.

panics can be caught and the presence of those unwraps come with enough data that filing a bug report upstream is helpful enough to fix the bug.

Sure, but that (we do it) happens currently with C/C++ and signal handler traps which gather the callstack and collate them: the issue isn't usually that we don't know the crashes aren't happening or having the call stacks - the issue is hacky code that was written for one purpose is now being used for other things it wasn't designed for (because it is useful to artists, despite its limitations), and there isn't the…

It does change the situation if the plugin throws an exception on errors instead of causing a segfault that brings down the parent application.

Re: Memory Safe Languages in Android 13

#262

Post by ghostwriter »

harry8 wrote: post #253
ghostwriter wrote: post #252

Earlier quoted context omitted.

> We have no ssl library written in a memory-safe, functional language that has been proven correct that has dominated the space. Heartbleed wasn't yesterday. Heartbleed didn't affect https://hackage.haskell.org/package/tls even though it isn't formally verified.

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.

Re: Memory Safe Languages in Android 13

#263

Post by Ar-Curunir »

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++?

Re: Memory Safe Languages in Android 13

#264

Post by munificent »

hinkley wrote: post #246
gnull wrote: post #207

Earlier quoted context omitted.

> Defenders of C/C++ frequently note that memory safety bugs aren't a significant percentage of the total bug count, and argue that this means it's not worth the hassle This says more about those C++ defenders.

You can judge a person by the company they keep.

Lie down with C++, wake up with bugs.

Re: Memory Safe Languages in Android 13

#265

Post by metaltyphoon »

pcwalton wrote: post #256
metaltyphoon wrote: post #236

Earlier quoted context omitted.

What reason were used to not use what C# has? It’s infinitely less noisy than Rust’s ::

Using a separate character for namespace resolution and field indexing allows you to have a module with the same name as a value.

Wouldn’t this be trivially solved by having namespaces follow the same PascalCase semantics as types?

I.e

use Std.String;

…. let string = String(…);

Re: Memory Safe Languages in Android 13

#266

Post by munificent »

metaltyphoon wrote: post #236
pcwalton wrote: post #67

Earlier quoted context omitted.

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

What reason were used to not use what C# has? It’s infinitely less noisy than Rust’s ::

Technically, it is only 75% less noisy.

Re: Memory Safe Languages in Android 13

#267

Post by afdbcreid »

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…

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.

Re: Memory Safe Languages in Android 13

#268

Post by masklinn »

estebank wrote: post #241
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…

It's not just about bounds checks. I am way more agressive about borrowing fields of other types, particularly mutable borrows in ways that I wouldn't attempt in C to protect myself from future code from breaking invariants I'd have to rely on. This means I can write the hyper optimized version of an algorithm on any language, but I'm more likely to even attempt it in Rust.

An other bit I first saw observed by Armin Ronacher and which is indeed quite common is that Rust does not require you to be defensive (and pay the price) around protected resources e.g. you can hand out references to rc’d types or mutex’d, and you know it’s safe, if a bit constraining.

And so you save the overhead of the extra refcounting or the re-entrant locks (though that would be unsound anyway), and you can safely use anything which works off of references.

Re: Memory Safe Languages in Android 13

#269

Post by netr0ute »

nneonneo wrote: post #188
netr0ute wrote: post #171

Earlier quoted context omitted.

let mut line = String::new(); stdin().read_line(&mut line)?; This is what I'm talking about. This is so ugly and clunky and needlessly verbose like Java compared to C++ where you can do std::string input; std::cin >> input; and have it Just Work. Why can't Rust do something similar?

Except, you've failed to check for an error, and you need another line to do that. Suppose the user ended their input or the input is a pipe that's been closed - what does your C++ program do? Here's another example. C++ lets you do this: long input; std::cin >> input; process(input); and this is very convenient! It's much shorter than the Rust code for doing the same. It's also wrong! If the input cannot be read, or…

> Some people will say, I just want to get stuff done and not worry about all this safety junk. As someone who works in security and have exploited bugs in C/C++ programs, this is pretty much why we wound up with so many CVEs.

Are constructions like these really the root cause of CVEs? As long as you do a correct check, then you're all good. If Rust can do the same thing in fewer lines, then that may or may not be a good thing because some people might want a lower degree of abstraction or a greater one.

Re: Memory Safe Languages in Android 13

#270

Post by masklinn »

pornel wrote: post #223
Octokiddie wrote: post #81

> This matches the expectations published in our blog post 2 years ago about the age of memory safety vulnerabilities and why our focus should be on new code, not rewriting existing components. and > As we noted in the original announcement, our goal is not to convert existing C/C++ to Rust, but rather to shift development of new code to memory safe languages over time. For those working on C/C++ code bases, how does…

Wrapping of C libraries in a Rust interface works quite well, and makes them safer. For stable battle-tested libraries I think it's even preferable to rewrites. Many informal rules of C libraries like: "don't call read() after close()", "pointer must never be null", or "keep this data alive for as long as the handle is in use" in Rust can be expressed using the type system, and enforced at compile time. Cleanup can b…

Nit: these are not informal rules, they’re clear UBs, they’re “just” not checked.

An informal rule would be “don’t use gets” before it was deprecated, or “don’t use the str* functions”, or “don’t pass a user-provided format to printf”.

Post reply on HN