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

421–430 of 606 posts

Re: Memory Safe Languages in Android 13

#421

Post by mk89 »

Rusky wrote: post #319
mk89 wrote: post #283

Earlier quoted context omitted.

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

I think it is just as (un)true that Rust programmers don't need to worry about those errors, as it is that Java/Python/JS/whatever programmers don't need to worry about them. And this is really the only meaning for "memory safe" that can apply to anything that runs on real world hardware and operating systems. It's always conditional on the correctness of the compiler checks, the runtime, and in Rust the unsafe block…

> And I don't think people really expect to be immune to bugs in their compiler or runtime just because the language is "safe"!

I would really ask you to rethink what people think and expect. Maybe you work for a company with lots of people who understand this kind of things. I am more used to people who just jump on the "oh this lib does this, let me use it".

Everywhere I read only Rust is memory safe, you don't have to worry about anything (just don't use safe). As I mentioned before, your code might be implicitly vulnerable because of other libs, and if today it's not maybe an issue, it might be in 5 years when you have tons of libs out there rewritten in Rust and "hey they need to use unsafe code, and I can't exclude them".

For me it's important to have a proper definition and I am not happy about all the marketing around it. I still believe it provides great improvements for the code you own, so you can't mess up with pointers, use after free, and weird things like that.

Re: Memory Safe Languages in Android 13

#422

Post by pjmlp »

logicchains wrote: post #352
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…

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

Re: Memory Safe Languages in Android 13

#423

Post by Jweb_Guru »

Sirened wrote: post #375
tialaramex wrote: post #329

Earlier quoted context omitted.

Wait, previously you were talking about bounds checks which can't be optimised out, now you seem to be saying in C you wouldn't bother writing any bounds checks, which is a quite different claim.

I think what they're saying is that C compilers don't care about aliasing here because it's not actually bounds checking the pointers , it's just a numeric comparison between two random arguments. It's much easier for an optimizing compiler to eliminate a duplicated boolean check between two numbers this way because passing numbers from one function to the next has no aliasing concerns.

This is a misunderstanding of what's useful about aliasing information. A lot of C code can't be autovectorized because it can't tell that accesses to two arrays don't alias, for example. Similarly it often can't reorder / eliminate redundant updates to arrays because it can't tell they're not aliased. These aren't related to bounds checking specifically but they are things that can improve performance in Rust over C (theoretically, anyway; in practice LLVM is still very much tuned for C so it doesn't take advantage of a lot of this stuff yet, but it likely will in the future).

Re: Memory Safe Languages in Android 13

#424

Post by Thorrez »

heather45879 wrote: post #341
thaumasiotes wrote: post #305

Earlier quoted context omitted.

> Consider h::i::j::k versus h.i.j.k > Two :’s is an extremely loud combination of visual elements compared to the subtle point. :: drags the eye away from the content and says “look at me oscillate” > In addition, humans group similar visual elements together so a combination of anything::doesnt::matter::what::between::clumps it is impossible to escape the common pattern and the eye jumps between the ::’s. Therefore…

Syntax coloring would make it worse because coloring the :: independently of the surrounding tokens will make them stand out even more as a group. Rust is safe but it’s at least as ugly as C++.

It depends on how the coloring is done. If the background is white, the words are black and the :: are gray, the :: won't stand out.

Re: Memory Safe Languages in Android 13

#425

Post by Jweb_Guru »

pjmlp wrote: post #393
Jweb_Guru wrote: post #281

Earlier quoted context omitted.

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

Easy localizable via grep, and not full of UB and memory corruption issues, which is what the 70% of unsafety issues due to memory corruption on C, C++ and Objective-C relate to. At some level of the stack some Assembly or compiler intrisics are needed, not at every line of code.

Jikes is the one I'm most familiar with and people working on its runtime absolutely suffered from UB and memory corruption issues... obviously not throughout the whole standard library but that's not the case for other JVMs either. In fact the Jikes people found it nicer to work in Rust than in Java on components like the garbage collector, because it was a better fit for working safely with this kind of code and they didn't have to write in a restricted subset of the language to avoid triggering the GC.

Re: Memory Safe Languages in Android 13

#426

Post by jstimpfle »

p-e-w wrote: post #368
dralley wrote: post #365

Earlier quoted context omitted.

Well, not exactly. There have been plenty of advancements in bridge / highrise construction over the past 100 years, but in practice we don't go around tearing down old infrastructure that is still functional because it was built with outdated designs and technologies, even when it could theoretically save lives. Buildings get "grandfathered" into meeting code all of the time. Software is not terribly different from…

This isn't primarily about replacing existing software. There are plenty of engineers that argue for continuing to use memory-unsafe programming languages. New projects written in C are being started every day. This is the exact equivalent of physicians continuing to use unsafe medical procedures, and what's worse, many of those engineers defend their dangerous practices by claiming there is no real danger in the fir…

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 practice for Rust seems to be to avoid linked lists for example. I don't know what's the safe replacement for memset and memcpy to anonymous data structures (void pointers -- generic code) but I have a sense that it is more painful. The general recommendations seem to be to switch to different, more complicated datastructures with more failure modes, or to put boxes and Arcs around things.

I don't think this fits me - I like the feeling of understanding what I'm doing, and once in a while coming up with something that compiles and runs fast and robustly. If you can do that in Rust, good for you.

Another part is that it still seems easier to interface with existing ecosystems in C. I tried writing some Win32 Rust code once in an evening and I have to admit I failed. Maybe I picked the wrong bindings library or whatever. At this point in my life, I have little patience to spend my time like this.

I appreciate the work that is being done, and I feel it's not unlikely that at some point we all will switch. At this point though I feel I'm way more productive staying in my current habitat. And that's not only on me, but also that the ecosystem and developed practices likely are not quite ready for a complete switch.

Comparing the investment to simply washing hands and putting on gloves or following a checklist as a surgeon feels unfair to me.

Re: Memory Safe Languages in Android 13

#427

Post by jstimpfle »

kaba0 wrote: post #394
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.

Which memory-unsafe language is more productive and has faster time -to-market than any managed language?

I'm pretty confident that systems programming (you know - moving data around) is easier with raw memory access compared to managed languages.

Re: Memory Safe Languages in Android 13

#428

Post by zeroc8 »

WoodenChair wrote: post #42

The more interesting part of this article for me is that in 2022, Java is still the number 1 language that new pieces of Android are made out of. It probably has to be this way for compatibility, and I personally have no problem with Java. But the hype train would not have you believe this.

Yup, was quite surprised by this too, I was kind of expecting that most of Java's lunch would have been eaten by Kotlin by now.

Re: Memory Safe Languages in Android 13

#429

Post by jstimpfle »

foxes wrote: post #370
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.

Where has time to market and productivity ever been a factor for C and the C ecosystem? My most "productive" languages have been declarative languages like Haskell (depending on how you measure that). I don't care if it takes an extra few minutes to compile either, amortized away in the long term when you don't have to deal with entire additional classes of bugs to deal with. Also why is security never an important c…

I spent a considerable amount of time learning Haskell but I always felt like a slave to the language. Oh, you want to do this other simple thing? Try language extension XYZ, but you'll have to learn some more language theory first. Also sorry but the extension isn't compatible with the extensions you're already using, and you need to require a new dependency on the outside interface.

There are some things that the language is good at, but at some other things (I think a lot actually) it isn't. At the very least, I wouldn't recommend it for writing a video decoder.

Re: Memory Safe Languages in Android 13

#430

Post by tulio_ribeiro »

Well, it looks like Google has finally figured out the solution to all of their security woes: just switch to Rust and watch the vulnerabilities vanish! I'm sure that every other company facing similar issues will be rushing to follow suit. #RustToTheRescue

Memory safety, oh so sweet

Reducing vulnerabilities, a feat

Google switches to Rust

Security improved, a must

Memory corruption, a thing of the past

Safe coding, a task at last

Post reply on HN