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

281–290 of 606 posts

Re: Memory Safe Languages in Android 13

#281

Post by Jweb_Guru »

pjmlp wrote: post #275
kllrnohj wrote: post #131

Earlier quoted context omitted.

> I think a distinction can be made in that you never really need to use unsafe operations in python or Java. You can't write any code at all in Python or Java without relying on unsafe operations. Both of them have their runtimes written in C/C++. So based off of this unusual line of reasoning, Rust is strictly more memory safe than either of those as it's at least possible to have a Rust program without any unsafe…

There are at least three Java runtimes written in Java, Jikes RVM, MaximeVM, and GraalVM.

At least two of which use an unsafe dialect of Java for significant parts of the runtime, which I'm pretty sure you know well (maybe not Graal, but if not it's because it's bootstrapping on top of existing unsafe code).

Re: Memory Safe Languages in Android 13

#282

Post by Gigachad »

gnull wrote: post #207
lolinder wrote: post #116

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…

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

C-nile developers have been making incorrect arguments for a while now. The reality is which almost everyone can see is that memory safe languages are pretty much always what you want to be using for new code. OS and security sensitive components are the prime targets for rewrites in more secure languages.

Now Google has put this to the test and has the data to prove it. We should not allow the worlds technology security to be held hostage by a group of people too lazy to adapt with the times.

Re: Memory Safe Languages in Android 13

#283

Post by mk89 »

fiedzia wrote: post #242
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…

> they told you that Rust is a memory safe language and you don’t need anything else than the rust compiler - this is how I find 99% of today’s articles about Rust. It is - as long as you don't use unsafe. Which is very rare, so we've made huge progress here already. Validation for cases where unsafe is necessary is needed and welcomed, but doesn't change the fact that 99% safe Rust is much better than 100% unsafe C/…

> It is - as long as you don't use unsafe.

That's what I tried to show in the previous post: it's just not true, because if you rely even on an unsafe function from the standard library affected by a CVE, you're just fucked as if it was in C, C++ or other languages. The only difference is that you don't know what's happening under the hood and you feel "safe" because that's how they sold the language to you. Until you get hacked and "hey we didn't know...".

You just use that "unsafe zip/unzip" function you find in the docs, and with maybe with the wrong input (a weird filename or so) it happens to create undefined behavior that opens up the door to vulnerabilities.

I really believe that Rust, Swift and lots of new[er] programming languages improve in terms of memory safety (at least on the high level), however, we need to admit that they are being sold for what they are not -> memory safe. When I read memory safe it means that it cannot happen at all, and therefore I don't have to think about that kind of stuff when I write a program.

It'd be more honest to say: it's memory safe until:

- you use unsafe

- the libs you rely on use unsafe (and go figure once you start to pull a lib that pulls another lib etc.)

- the standard library functions you use use unsafe

It's an important remark, because the next generations of programmers will build programs based on a false assumption - that they don't have to worry about certain types of errors, while it's just not true.

EDIT: maybe it's just my definition of memory safe too "strict", not sure. Memory safe to me means -> it just can't happen. That's it.

Re: Memory Safe Languages in Android 13

#284

Post by mk89 »

stouset wrote: post #190
mk89 wrote: post #145

Earlier quoted context omitted.

I didn’t say it’s not an improvement. I just wonder who will you blame once you have a hacker exploiting that exact CVE which you didn’t know about because they sold you rust as memory safe language, so you didn’t take the time to run any sanitizer or similar. Does Rust provide a way to check if you’re using unsafe code? What if I want to disable that? If I need to make a mission critical software I need to be aware…

> I didn’t say it’s not an improvement. You… almost literally did? > I am happy that we are moving towards a future where there are less memory bugs, but… are we really?

> You… almost literally did?

I don't understand this comment, to be honest. What does it add to the conversation?

Re: Memory Safe Languages in Android 13

#285

Post by Gigachad »

wiseowise wrote: post #53
synergy20 wrote: post #16

Earlier quoted context omitted.

I'm learning modern c++ these days, but I don't follow your 'money' logic here...

Cool kids and students move to Rust, C++ doesn’t have influx of new developers hence more demand for existing C++ developers.

We haven't seen the same thing for PHP and other obsolete languages. Cleanup janny work isn't as respected or well paid as building cutting edge new things in modern tools.

Re: Memory Safe Languages in Android 13

#286

Post by mk89 »

masklinn wrote: post #165
mk89 wrote: post #159

Earlier quoted context omitted.

If we leave it to the programmer, what are we improving? We did a big improvement, but why can’t we disable “unsafe”? That would leave absolutely no margin for such errors.

> We did a big improvement, but why can’t we disable “unsafe”? Because there are things which literally can not be safe, and rust will not let you get away with pretending.

> Because there are things which literally can not be safe, and rust will not let you get away with pretending.

Can you post maybe a good article explaining this?

Re: Memory Safe Languages in Android 13

#287

Post by mk89 »

throwup wrote: post #186
mk89 wrote: post #159

Earlier quoted context omitted.

If we leave it to the programmer, what are we improving? We did a big improvement, but why can’t we disable “unsafe”? That would leave absolutely no margin for such errors.

Rust has a culture where people don't use `unsafe` unless absolutely necessary. That is generally good enough in my experience. If you want to go further, you can disable unsafe in a crate by adding #[forbid(unsafe)]. And if you need more control than that, there's probably tooling out there that will help depending on what exactly you need. https://github.com/rustsec/rustsec/tree/main/cargo-audit https://github.com/…

> If you want to go further, you can disable unsafe in a crate by adding #[forbid(unsafe)].

Cool, so it's possible to exclude dependencies which include unsafe stuff! That's awesome.

See, this is the kind of stuff I was looking for.

From the perspective of a team writing new Rust code:

1) Don't allow unsafe (you can have an easy code search for this) 2) Forbid unsafe cargos

Finally: how do you catch unsafe in the standard library?

Re: Memory Safe Languages in Android 13

#288

Post by dagenix »

metaltyphoon wrote: post #265
pcwalton wrote: post #256

Earlier quoted context omitted.

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(…);

That's a different trade off. It's not a solution.

Re: Memory Safe Languages in Android 13

#289

Post by lalaithion »

mark_l_watson wrote: post #247

How does Swift compare to Rust in safety? I read that Swift is only memory safe in single threaded environments, which is not ideal. I was very enthusiastic about Rust about 4 years ago but decided to learn Swift instead as a new “cool non-Lisp language” to learn. Seeing an recent article on writing Python in Rust made me wish that I had chosen differently. I found this article made me feel better about security. I e…

I haven't actually been able to find an example program where Swift violates memory safety in a multithreaded environment; I'd love to see an example.

Re: Memory Safe Languages in Android 13

#290

Post by jdorfman »

mk89 wrote: post #287
throwup wrote: post #186

Earlier quoted context omitted.

Rust has a culture where people don't use `unsafe` unless absolutely necessary. That is generally good enough in my experience. If you want to go further, you can disable unsafe in a crate by adding #[forbid(unsafe)]. And if you need more control than that, there's probably tooling out there that will help depending on what exactly you need. https://github.com/rustsec/rustsec/tree/main/cargo-audit https://github.com/…

> If you want to go further, you can disable unsafe in a crate by adding #[forbid(unsafe)]. Cool, so it's possible to exclude dependencies which include unsafe stuff! That's awesome . See, this is the kind of stuff I was looking for. From the perspective of a team writing new Rust code: 1) Don't allow unsafe (you can have an easy code search for this) 2) Forbid unsafe cargos Finally: how do you catch unsafe in the st…

> 1) Don't allow unsafe (you can have an easy code search for this) 2) Forbid unsafe cargos

This can be accomplished with cargo vet (https://mozilla.github.io/cargo-vet/how-it-works.html?highli...)

Post reply on HN