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

91–100 of 606 posts

Re: Memory Safe Languages in Android 13

#91

Post by selfmodruntime »

optymizer wrote: post #76

As an Android user ever since the T-Mobile G1, I'm a fan of not having my phone remotely exploited via WebView, or with an SMS, or the other million ways there are to interact with a device, so I absolutely celebrate this progress. As an Android developer though, I have to be the one bitter old man yelling at cloud. I was spoiled by Java and Kotlin to the point where I cannot look at Rust and think it's a nice modern…

> Passing "self" as the first argument was bullshit in Python, and it's bullshit in Rust too. Don't look at me like that - the compiler can inject it as the first parameter without requiring you to type it in.

Nope, that would be a static function on your struct. By using self you let the compiler know that you want to use an instance function.

Re: Memory Safe Languages in Android 13

#92

Post by burntsushi »

goodpoint wrote: post #74
burntsushi wrote: post #60

Earlier quoted context omitted.

Can you link to anyone with any modicum of credibility declaring that this article is evidence that "Rust solved security"? I'll be the first to point out that memory safety related vulnerabilities are merely a subset (albeit a big one) of all possible vulnerabilities.

That's what I wrote.

... yes? And I'm asking you, who is saying that? You said:

> Some people are posting the article around the Internet as evidence that Rust solved security.

OK, so show me. Let's see all these people declaring that this is "evidence that Rust solved security."

I think it's far more likely that you're exaggerating what folks are saying to make them appear far more unreasonable than they actually are. But we can't know that unless you actually show your work, now can we?

Re: Memory Safe Languages in Android 13

#93

Post by estebank »

selfmodruntime wrote: post #83
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…

>Rust didn't protect me from that, and those are the kind of vulnerabilities that we'll continue seeing regardless of language I'm still thinking about how we could integrate something like that in a language or the languages package manager. I'm unsure if it's possible.

The only things I can think of is the use of newtypes around PathBuf that enforces things like expansion and that makes the check for you when restricting tk a specific directory. Now that I'm writing this out, this feels like it could be a very useful small crate or addition to Camino. Thank you for making me think further about this. Of course, the impl would have an associated runtime cost for the check and a more involved API surface because it's asking the developer for more information. But once you do that you can have an TryInto impl to pass it to any standard method.

Re: Memory Safe Languages in Android 13

#94

Post by gavinray »

optymizer wrote: post #76

As an Android user ever since the T-Mobile G1, I'm a fan of not having my phone remotely exploited via WebView, or with an SMS, or the other million ways there are to interact with a device, so I absolutely celebrate this progress. As an Android developer though, I have to be the one bitter old man yelling at cloud. I was spoiled by Java and Kotlin to the point where I cannot look at Rust and think it's a nice modern…

I'm just commenting to agree with the "D got language design right, Marketing worse than Rust". I cry every time =(

Don't have anything against Rust though, except the syntax can be a bit obtuse.

Re: Memory Safe Languages in Android 13

#95

Post by modshatereality »

pcwalton wrote: post #66
pclmulqdq wrote: post #56

Earlier quoted context omitted.

Ada seems to fit.

Ada has an FFI.

As well as address clause, unchecked_conversion and address_to_access_conversion. Extremely useful tools that give you the choice when to write risky code, and generate a compiler note exactly where such risk lives.

Re: Memory Safe Languages in Android 13

#96

Post by depereo »

thesuperbigfrog wrote: post #26
cwyers wrote: post #15

Earlier quoted context omitted.

I believe what the post you're replying to is implying is, there's a ton of C++ code in the world that isn't going to be ported to Rust, and someone is going to have to fix all of those bugs in C++ code already in the wild. So you can get paid to be that person.

>> there's a ton of C++ code in the world that isn't going to be ported to Rust, and someone is going to have to fix all of those bugs in C++ code already in the wild. So you can get paid to be that person. That is well and good for legacy systems that cannot / will not be updated. Android is not a legacy system and is adopting Rust and seeing security benefits. Linux is not a legacy system and is slowly adopting Rus…

They do say in the article that they are uninterested in rewriting existing c/c++ code in new languages.

There will continue to be c/c++ applications that will need new features, new bug fixes and new development for decades.

Some of the most fundamental code on the planet for the most critical systems are written in those languages. Also a lot of video game development leans heavily on c++ in particular and that's not going to change very quickly. Big or small enterprise hardware vendors won't change to new languages overnight, abandoning potentially decades of system building experience and supporting processes. There's a cost to even being able to run rust alongside your c/c++ code. Some places may never switch or enable interoperability even for new products.

Learning c/c++ will still be lucrative and a good idea today.

Re: Memory Safe Languages in Android 13

#97

Post by netr0ute »

thesuperbigfrog wrote: post #26
cwyers wrote: post #15

Earlier quoted context omitted.

I believe what the post you're replying to is implying is, there's a ton of C++ code in the world that isn't going to be ported to Rust, and someone is going to have to fix all of those bugs in C++ code already in the wild. So you can get paid to be that person.

>> there's a ton of C++ code in the world that isn't going to be ported to Rust, and someone is going to have to fix all of those bugs in C++ code already in the wild. So you can get paid to be that person. That is well and good for legacy systems that cannot / will not be updated. Android is not a legacy system and is adopting Rust and seeing security benefits. Linux is not a legacy system and is slowly adopting Rus…

> Android is not a legacy system and is adopting Rust and seeing security benefits.

> Linux is not a legacy system and is slowly adopting Rust and may see greater use with time.

100% USDA Grade-A Certified Prime BS, as shown by both projects' ages (15+, 30+ years) and maybe the definition of legacy. If you consider legacy to be something you have to keep a certain way so that it functions a certain way, then both are basically legacy technologies. What isn't legacy? I would say projects like Fuchsia and Rust itself aren't legacy because you can move fast and break things there. This also means stuff like C++ is legacy, so there's that too.

Re: Memory Safe Languages in Android 13

#98

Post by shpongled »

optymizer wrote: post #76

As an Android user ever since the T-Mobile G1, I'm a fan of not having my phone remotely exploited via WebView, or with an SMS, or the other million ways there are to interact with a device, so I absolutely celebrate this progress. As an Android developer though, I have to be the one bitter old man yelling at cloud. I was spoiled by Java and Kotlin to the point where I cannot look at Rust and think it's a nice modern…

I find it interesting that your complaints are almost totally about the syntax - that is generally the last thing I care about in a language.

When I choose languages, I choose them based on semantics, tooling, community/ecosystem, UX, and then maybe syntax

Re: Memory Safe Languages in Android 13

#99

Post by bmicraft »

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…

> and effectively making it even LESS maintainable now that it's in some new niche language with a vastly smaller dev pool

How is any language supposed to grow if you're only allowed to use it once everybody does? Somebody has to be first (and google isn't, not by a long shot)

Re: Memory Safe Languages in Android 13

#100

Post by cesarb »

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…

> but I'm thinking of a project where more substantial additions have been made.

The most famous example of that is AFAIK Firefox. There's a (perhaps outdated) list at https://wiki.mozilla.org/Oxidation#Rust_Components of places where Rust was used to replace some component in Firefox; the most famous of these are probably the CSS style calculation which came from the Servo project (https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-en...), and a renderer also from the Servo project (https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-f...).

Post reply on HN