Memory Safe Languages in Android 13 • Hacker News Board

Re: Memory Safe Languages in Android 13

#361

Post by awesomeMilou » Fri, Dec 02, 2022, 4:30 AM UTC

p-e-w wrote: post #356

yosefk wrote: post #199

Earlier quoted context omitted.

It's even worse. The majority, not of all bugs, but all vulnerabilities (of all severities) do come from memory safety bugs. TFA: "For more than a decade, memory safety vulnerabilities have consistently represented more than 65% of vulnerabilities across products, and across the industry." On top of that , memory safety vulnerabilities are disproportionately high severity: "Memory safety vulnerabilities disproportion…

> NOTE: down to 36% from 65% because of moving from C++ to Rust and other memory safe languages Imagine if in any other field, a process or technology were developed that cuts the number of high-severity issues in half. For example, a modification to the standard anesthesia protocols that demonstrably reduces anesthesia-related fatalities by 50% in clinical practice. And now imagine, in reaction to this revolutionary…

That seems to be a very limited view on the issue, since the stakes with ansthesia related issues are much higher (a human life).

Re: Memory Safe Languages in Android 13

#362

Post by Xorlev » Fri, Dec 02, 2022, 4:31 AM UTC

logicchains wrote: post #355

Ar-Curunir wrote: post #255

Earlier quoted context omitted.

Google is one of the biggest C++ shops out there, and also authors and maintains many of the static analysis tools and safety features you mention. If they’re saying that C++ can’t be saved, maybe they’re worth listening to.

>If they’re saying that C++ can’t be saved, maybe they’re worth listening to. Google's one of the worst C++ shops because their code standard basically forbids using modern C++, and their C++ is more like 90s Java than modern C++. It's no wonder they want to get away from it.

I...what?

I write C++ at Google, and it encourages use of modern C++ features, and many things you see adopted in std have roots in our libraries.

I'm curious what you think Google prevents us from using and why you think our C++ is like 90s Java.

https://abseil.io/tips has a lot of our philosophies and abseil is chunks of our internal libraries published externally.

Re: Memory Safe Languages in Android 13

#363

Post by nickm12 » Fri, Dec 02, 2022, 4:35 AM UTC

mk89 wrote: post #159

bluGill wrote: post #149

Earlier quoted context omitted.

Rust would have prevented about half of the CVEs in C code (I've seen a few different studies with somewhat different results, half is close enough for discussion). The other half is on you to write good code. Note that the half Rust would prevent tends to be less impactful, still a CVE, but the exploit is less impactful to end users.

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.

Unsafe is necessary for Rust to meet its goal of being a systems language. If Rust didn't provide unsafe, then Rust programmers would be forced write this code in C, which would be just as unsafe, but a worse developer experience.

Re: Memory Safe Languages in Android 13

#364

Post by dagmx » Fri, Dec 02, 2022, 4:36 AM UTC

modshatereality wrote: post #115

bmicraft wrote: post #99

Earlier quoted context omitted.

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

Many languages had only a single compiler implementation when they were brought into the limelight for critical development so your benchmark would fail almost everything.

Re: Memory Safe Languages in Android 13

#365

Post by dralley » Fri, Dec 02, 2022, 4:39 AM UTC

p-e-w wrote: post #356

yosefk wrote: post #199

Earlier quoted context omitted.

It's even worse. The majority, not of all bugs, but all vulnerabilities (of all severities) do come from memory safety bugs. TFA: "For more than a decade, memory safety vulnerabilities have consistently represented more than 65% of vulnerabilities across products, and across the industry." On top of that , memory safety vulnerabilities are disproportionately high severity: "Memory safety vulnerabilities disproportion…

> NOTE: down to 36% from 65% because of moving from C++ to Rust and other memory safe languages Imagine if in any other field, a process or technology were developed that cuts the number of high-severity issues in half. For example, a modification to the standard anesthesia protocols that demonstrably reduces anesthesia-related fatalities by 50% in clinical practice. And now imagine, in reaction to this revolutionary…

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 that. The cost of replacing foundational software is tremendous, much higher than just "adopting a new protocol".

Of course, new software should still take heed of this and try to improve.

Re: Memory Safe Languages in Android 13

#366

Post by p-e-w » Fri, Dec 02, 2022, 4:42 AM UTC

awesomeMilou wrote: post #361

p-e-w wrote: post #356

Earlier quoted context omitted.

> NOTE: down to 36% from 65% because of moving from C++ to Rust and other memory safe languages Imagine if in any other field, a process or technology were developed that cuts the number of high-severity issues in half. For example, a modification to the standard anesthesia protocols that demonstrably reduces anesthesia-related fatalities by 50% in clinical practice. And now imagine, in reaction to this revolutionary…

That seems to be a very limited view on the issue, since the stakes with ansthesia related issues are much higher (a human life).

Every human life is directly or indirectly impacted by software. Software controls transport, food and energy production, and all human communication. If all software suddenly stopped working, society would collapse instantly and hundreds of millions of people would die within a year.

The attitude "it's just computers, nothing truly important like medicine" might have been viable 40 years ago, but it certainly isn't anymore.

Re: Memory Safe Languages in Android 13

#367

Post by nickm12 » Fri, Dec 02, 2022, 4:45 AM UTC

mk89 wrote: post #283

fiedzia wrote: post #242

Earlier quoted context omitted.

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

"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 happen in YOUR CODE. If your safe Rust code calls a library that uses unsafe incorrectly, yes you can encounter a memory-safety issue. But the memory safety bug is in the library, not your code. It is even possible to encounter a memory-safety issue in Rust if you never use unsafe, but in that case the memory safety bug is in the Rust compiler, not your code.

Re: Memory Safe Languages in Android 13

#368

Post by p-e-w » Fri, Dec 02, 2022, 4:46 AM UTC

dralley wrote: post #365

p-e-w wrote: post #356

Earlier quoted context omitted.

> NOTE: down to 36% from 65% because of moving from C++ to Rust and other memory safe languages Imagine if in any other field, a process or technology were developed that cuts the number of high-severity issues in half. For example, a modification to the standard anesthesia protocols that demonstrably reduces anesthesia-related fatalities by 50% in clinical practice. And now imagine, in reaction to this revolutionary…

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 first place if the programmer is "smart enough".

Re: Memory Safe Languages in Android 13

#369

Post by harry8 » Fri, Dec 02, 2022, 4:50 AM UTC

raggi wrote: post #349

harry8 wrote: post #225

Earlier quoted context omitted.

Seems like drawing too many conclusions from evidence while arguing against a straw man? Defenders of C might note that Android is java and IOS is not and compare the security of those two systems and say clearly memory-safe is focusing on the wrong thing. This is equally true but no more valid an argument. The one that really bothers me in all these language-booster discussions (that we should and need to have) is t…

WireGuard is a recent and prominent example of a system that has been formally verified ( https://www.wireguard.com/formal-verification/ ). There are implementations in a variety of languages due to integration considerations. You will find at the bottom of that page C implementations of curve25519 that are proofed and derived from F* and Coq. Curve25519 is a relatively simple implementation and only one part of any…

Now that is interesting. I didn't know that and will have to look further to understand what it means.

Wireguard seems to be written almost entirely in C, is that right?

Re: Memory Safe Languages in Android 13

#370

Post by foxes » Fri, Dec 02, 2022, 4:54 AM UTC

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.

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 concern? There are a lot of security issues which are self inflicted if you use C. Using something like rust means a lot of issues simply don't exist. The optimal solution.