Memory Safe Languages in Android 13 • Hacker News Board

Re: Memory Safe Languages in Android 13

#521

Post by athrowaway12 » Fri, Dec 02, 2022, 2:21 PM UTC

pjmlp wrote: post #422

logicchains wrote: post #352

Earlier quoted context omitted.

>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. Not everybody is writing security-critical code. For some things productivity and time-to-market is more important and security is not enough of a concern to justify dealing with a language with horrible compile times and a self-righteous, dogmatic community.

Only because unfortunely liability is still not enforcement by law as it should.

> enforcement of security vulnerability should be by law

I think whether there "should" be a law making you liable could depend on the details of the exploit.

If you get exploited via rowhammer, I don't think anyone would blame you. It would be unreasonable if every small business running a website could be sued if they didn't defend against electromagnetic interference within the RAM.

However, if you're Apple and say -- you could get pwned because someone clicked a button to register version 9000 on the public npm/pypi registry (https://medium.com/@alex.birsan/dependency-confusion-4a5d60f...) -- maybe I agree there's an argument for some accountability there :)

Re: Memory Safe Languages in Android 13

#522

Post by pjmlp » Fri, Dec 02, 2022, 2:26 PM UTC

athrowaway12 wrote: post #521

pjmlp wrote: post #422

Earlier quoted context omitted.

Only because unfortunely liability is still not enforcement by law as it should.

> enforcement of security vulnerability should be by law I think whether there "should" be a law making you liable could depend on the details of the exploit. If you get exploited via rowhammer, I don't think anyone would blame you. It would be unreasonable if every small business running a website could be sued if they didn't defend against electromagnetic interference within the RAM. However, if you're Apple and sa…

Yes it definetly should.

Computing is the only industry, where people accept to live with tainted goods instead of forcing whoever sold them to pay back, cover for their damage or whatever.

We already have high integrity computing, digital stores with returns, consulting with warranty clauses, and some countries are finally waking up that computing shouldn't be a special snowflake.

https://www.twobirds.com/en/insights/2021/germany/the-german...

Re: Memory Safe Languages in Android 13

#523

Post by steveklabnik » Fri, Dec 02, 2022, 2:29 PM UTC

cjg wrote: post #447

jstimpfle wrote: post #426

Earlier quoted context omitted.

I'm one of those people who still write in C, and I like the experience. I've had a lot of fun, and haven't been burned by it, although statistically it's likely that I will be at some point. I've tried a lot of languages in the past, and am currently not willing to dive into a whole new ecosystem, re-learn all the best practices, and unlearn what's worked very well for me with sometimes no good replacement. Best pra…

Implementing a linked list in Rust is somewhat challenging because of the safety issues that arise. Luckily you don't have to, there's one in the standard library: https://doc.rust-lang.org/std/collections/struct.LinkedList.... The equivalent of a generic memcpy is probably something like a .clone() call on a generic type that implements Clone.

> The equivalent of a generic memcpy is probably something like a .clone() call on a generic type that implements Clone.

If you type "memcpy" into the documentation search, rustdoc will point you to

* https://doc.rust-lang.org/stable/std/primitive.slice.html#me...

* https://doc.rust-lang.org/stable/std/intrinsics/fn.copy_nono... (Though it should really point to the reexport at https://doc.rust-lang.org/stable/std/ptr/fn.copy_nonoverlapp... )

The latter will also mention

* https://doc.rust-lang.org/stable/std/ptr/fn.copy.html

Re: Memory Safe Languages in Android 13

#524

Post by josefx » Fri, Dec 02, 2022, 2:30 PM UTC

pizza234 wrote: post #494

josefx wrote: post #460

Earlier quoted context omitted.

> It is a somewhat common attitude in this type of thread. Except the safety features are often a lot easier to use than the original C isms that tend to cause the most issues. So it is less an issue of smart and more one of bad habits. C strings instead of std::string, plain arrays instead of std::vector, implicit ownership instead of smart pointers, ... .

The stats come from Google project(s) - you can be sure that they've used the best practices. If they've failed, rest assured that 90%+ of the rest of the devs will fail, and much worse.

> he stats come from Google project(s) - you can be sure that they've used the best practices

The first Google Style Guide for C++ I ever came across in the wild espoused C with classes, had "standard" in scare quotes and banned most of boost for encouraging functional programming. I almost threw a fit when someone unironically tried to push that POS at work because "Google", it was entirely nonsensical especially given that we made heavy use of boost and math libraries with operator overloading.

Re: Memory Safe Languages in Android 13

#525

Post by steveklabnik » Fri, Dec 02, 2022, 2:32 PM UTC

raxxorraxor wrote: post #516

Gigachad wrote: post #282

Earlier quoted context omitted.

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

Meh, bad argument. How about you write better code in Rust to replace existing stuff. There is so much more to consider and I think one of Rusts most repellent features is the preaching about its advantages. I definitely has some that are hard to deny. Still... how about just doing it, nobody is held hostage here.

> How about you write better code in Rust to replace existing stuff.

No matter what people do, it's never enough for the critics. Many people criticize Rust fans for "rewriting it in Rust"!

> how about just doing it

People absolutely are. That's what the article is about, even.

Re: Memory Safe Languages in Android 13

#526

Post by steveklabnik » Fri, Dec 02, 2022, 2:36 PM UTC

UncleMeat wrote: post #507

rob74 wrote: post #412

Earlier quoted context omitted.

> Besides the bottom of the stack, managed languages are more than fast enough for nigh everything And yet, there is a lot of enthusiasm (at least here on HN) for web development in Rust...

There are plenty of people who want to write in Rust for the fun of it. But I'm not aware of too many people saying that you should avoid writing a web application in java/python/js in favor of rust. Pretty much the only people being told to stop doing what they are doing are the people starting new projects that process untrusted data in C and C++.

You and your parent are saying slightly different things with regards to web dev; they said there's enthusiasm for doing it, not that you shouldn't write web applications in those languages.

Someone can think it's fine to write a web application in java/python/js and Rust.

Re: Memory Safe Languages in Android 13

#527

Post by kaba0 » Fri, Dec 02, 2022, 2:40 PM UTC

steveklabnik wrote: post #518

kaba0 wrote: post #493

Earlier quoted context omitted.

Could you point me to some resources on that? I only know about #[repr] options, but that isn’t absolute control (e.g. for having structs usable from rust and internal asm)

What is “internal assembly”? I’m not familiar with that term. Is there anything else that the various repr options don’t give you? My team at work does OS dev in Rust, and haven’t ever run into cases where Rust can’t do what we need it to do in these cases.

* inline assembly, just my brain stopped working for a sec :D

Well, my specific case is writing a fast interpreter in Rust, where I would like to use elements like a stackframe from both inline asm and proper Rust code. In my first iteration I chose a dynamically sized u64 array, wrapped in a safe API, because I couldn’t be more specific. But even with known size elements the best I can do - to my knowledge - is Layout? Or just a raw pointer and a wrapper with helper functions, as otherwise I can’t modify the object in question from both places.

Re: Memory Safe Languages in Android 13

#528

Post by pkolaczk » Fri, Dec 02, 2022, 2:42 PM UTC

mk89 wrote: post #418

nickm12 wrote: post #367

Earlier quoted context omitted.

"Memory safe to me means -> it just can't happen. That's it." I'd suggest rethinking this definition. You are always at the mercy of the lower-levels of your system, both in the runtime and the compiler. By this definition, nothing is memory-safe, since it is possible for your code in a "memory safe" language to encounter memory-safety issues in its runtime or the operating system. Memory-safe means the bug won't hap…

> By this definition, nothing is memory-safe, since it is possible for your code in a "memory safe" language to encounter memory-safety issues in its runtime I am trying not to be extreme here, and of course I agree we objectively can't guarantee 100% safety, especially what's happening outside our code. However, importing a library happens within our code , it's in our executable, even if you don't write 90% of what…

> the JVM checks at runtime for overflows

It doesn't. Overflows wrap around in Java.

> dangling pointers

Only to managed memory. You may still allocate something through Unsafe and you're on your own, just as in Rust. And some popular Java libraries do use Unsafe / FFI under the hood.

Re: Memory Safe Languages in Android 13

#529

Post by O_H_E » Fri, Dec 02, 2022, 2:45 PM UTC

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…

just fyi, you can still write all the Java/Kotlin you want to stay relevant.

this post have nothing to do with writing apps for android. They are talking about developing the android system itself. They are writing new system code in Rust instead of C++. Userspace code is still enoraged to be written in Kotlin.

Re: Memory Safe Languages in Android 13

#530

Post by lolinder » Fri, Dec 02, 2022, 2:46 PM UTC

humanrebar wrote: post #500

tulio_ribeiro wrote: post #435

Earlier quoted context omitted.

While new safety features in C++ may be impressive, Google's data shows that memory safety vulnerabilities are still a major issue. Switching to a memory-safe language like Rust can help reduce the risk of vulnerabilities and improve the overall security and reliability of a product. The potential benefits make it a worthwhile investment, even if it requires some effort to migrate from C++. #RustIsTheRealDeal

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.