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

111–120 of 606 posts

Re: Memory Safe Languages in Android 13

#111

Post by nneonneo »

selfmodruntime wrote: post #91
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.

Also, there are several different ways to pass self: `self`, `mut self`, `&self`, `&mut self`, and they have very different semantics.

Rust could have taken the C++ route here: `fn static foo()`, `fn foo()`, `fn mut foo()`, `fn &mut foo()`, etc. but I feel like the explicit `self` is very clear and easy to understand.

Re: Memory Safe Languages in Android 13

#112

Post by pcwalton »

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…

> Edit: if you downvote, reply with a link to the last compiler you wrote.

https://github.com/rust-lang/rust/

Re: Memory Safe Languages in Android 13

#113

Post by insanitybit »

pclmulqdq wrote: post #56
insanitybit wrote: post #23

Earlier quoted context omitted.

No language in use meets your definition of memory safe.

Ada seems to fit.

A simple heuristic that I expect to work universally is "could I write a program that prints to my terminal on a linux machine?" and if the answer is "yes" then it does not fit.

Re: Memory Safe Languages in Android 13

#114

Post by throwup »

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…

So many complaints above surface-level syntax here.

> press "shift 3 bracket shift 9 shift 0 bracket" at the top of my structs

Just use an IDE and you can press alt+enter. Same thing you do in Java when writing getters and setters for your AbstractFactoryBeans.

> "let mut" could have been "var"

The "mut" does not belong to the "let", it belongs to the variable name.

  let (read_only, mut read_write) = (1, 2);
> Passing "self" as the first argument was bullshit

Explicit is better than implicit. I quite like the names in the argument list to match the set of names available in the function, rather than having an extra keyword (`static`) that you add to remove a function parameter.

Re: Memory Safe Languages in Android 13

#115

Post by modshatereality »

bmicraft wrote: post #99
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)

You should at least wait until there is more than one working/usable compiler for the language if you're going to start making systemic changes to your multi-billion-dollar code base responsible for the commerce of multiple billions of people on the planet. It's a weird move at this point for google to be making(edit: considering go is already supported on multiple compilers).

Re: Memory Safe Languages in Android 13

#116

Post by lolinder »

Their notes about vulnerability severity are particularly interesting.

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 of switching to a new language.

Google's data suggests that while this is true, almost all severe vulnerabilities are related to memory safety. Their switch to memory-safe languages has led to a dramatic decrease in critical-severity and remotely-exploitable vulnerabilities even as the total number of vulnerabilities has remained steady.

Re: Memory Safe Languages in Android 13

#117

Post by bluGill »

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…

I've only started scratching the surface, but that rust really wants you to use Cargo, while we have our own homegrown package manager, and cmake creates a lot of friction.

I can tell you that bad programmers can write bad code in Rust.

Re: Memory Safe Languages in Android 13

#118

Post by robot_no_421 »

codedokode wrote: post #32

Rust doesn't check for overflow in arithmetic operations in release mode so there are lot of opportunities to create vulnerabilities in Rust.

If you want to check for overflow, then you can use the methods that explicitly check for overflow:

https://doc.rust-lang.org/std/primitive.u32.html#method.chec...

So this is not an issue at all.

Re: Memory Safe Languages in Android 13

#119

Post by joshuamorton »

mk89 wrote: post #104

I am not a Rust or C++ fanboy, and I am happy that we are moving towards a future where there are less memory bugs, but… are we really? - https://www.infoq.com/news/2021/11/rudra-rust-safety/ - https://cve.report/vendor/rust-lang And you can find online similar links and research on the topic. All it takes is that you use that specific piece of code at the wrong time, and that’s it: your system which you once believe…

Yes.

They found 250 bugs after analyzing the entirety of rust and all of it's packages.

There are probably more memory safety bugs in the python standard library and top 50k packages.

Re: Memory Safe Languages in Android 13

#120

Post by kllrnohj »

cryptonector wrote: post #38

> Safety measures make memory-unsafe languages slow > > Mobile devices have limited resources and we’re always trying to make better use of them to provide users with a better experience (for example, by optimizing performance, improving battery life, and reducing lag). Using memory unsafe code often means that we have to make tradeoffs between security and performance, such as adding additional sandboxing, sanitizer…

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 saying anything of the sort. It's saying that the cost, whatever it was, was judged to be worth paying for the improved security for these projects

Post reply on HN