Memory Safe Languages in Android 13 • Hacker News Board

Re: Memory Safe Languages in Android 13

#461

Post by ilyt » Fri, Dec 02, 2022, 11:19 AM UTC

MBCook wrote: post #372

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…

> Utterly unthinkable, isn't it? No. Ignaz Semmelweis faced it in the 1800s for daring to suggest (what we know know as germs) made people sick and hand washing could drastically reduce medical complications. He was able to prove it too. By the end was locked up in an asylum for his ‘crimes’. Want more recent? How many stories have you heard of instruments or gauze or whatever left in surgical patients? Of operating…

We have smaller version of that with masks in pandemic. Cheap and easy means to reduce problem by a bit ? Nah, let's not do that /s

Re: Memory Safe Languages in Android 13

#462

Post by ilyt » Fri, Dec 02, 2022, 11:26 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…

I mean if you want to use that comparison, C/C++ bridge would have random holes dropping the cars off the cliff below.

The issue is not "bridge is suboptimally designed" or "bridge will need some extra maintenance because something started to break".

The memory safety issues are "some cars randomly explode when passing that bridge" or "when driver breaks 6 seconds after entering the bridge, every other driver dies.

> Software is not terribly different from that.

It is MASSIVELY different, especially anywhere near anything security-related. Most buildings don't have a group of people with hammers trying to find a weak point that will never happen in any actual use conditions and then hit that weakpoint in every similar building built in every place of the world.

Please don't make horribly useless comparisons like that

Re: Memory Safe Languages in Android 13

#463

Post by pkolaczk » Fri, Dec 02, 2022, 11:30 AM UTC

zeroc8 wrote: post #428

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.

Scala hasn't eaten Java's lunch, so how Kotlin could?

Re: Memory Safe Languages in Android 13

#464

Post by jabl » Fri, Dec 02, 2022, 11:32 AM UTC

berkut wrote: post #189

masklinn wrote: post #158

Earlier quoted context omitted.

> But if "security" isn't remotely a concern for a given project (like almost anything graphics / gaming related) Gaming platforms have gotten a lot less lenient over time, and with pretty much every game these days having online components, "security isn't remotely a concern" has become a lot less true.

Sure, but then there's things like HPC / offline graphics / simulation (VFX/CG), where performance is the end-all concern (or memory efficiency sometimes at the expense of CPU time), and security isn't a concern at all there, with lots of things like random index lookups into sparse arrays / grids, etc. I know for a fact that bound checks do make a bit of a difference there, as the data's random, so the branch predic…

I work in HPC, and while security isn't an issue for your typical simulation code, correctness certainly is. Spending a million CPU hours on a supercomputer computing junk because memory unsafely caused the simulation to corrupt itself, and then writing a paper publishing those results isn't good.

Many times when I've helped some researcher make their code run on a cluster I have discovered that the code crashes at runtime if bounds checking is enabled. The usual response is that "this can't be a problem because we've (or someone else) published papers with results computed with this program". Sorry sunshine, this isn't how it works. Maybe the corruption is entirely benign, but how can you tell?

Re: Memory Safe Languages in Android 13

#465

Post by burntsushi » Fri, Dec 02, 2022, 11:37 AM UTC

kaba0 wrote: post #406

burntsushi wrote: post #25

Earlier quoted context omitted.

Is there any practical programming language that is memory safe in its "entirety"? Python, for example, certainly is not. It has unsafe escape hatches (via ffi, at the very least). Yet, everyone I know of says and thinks of Python as a memory safe language. I do as well. > which makes it easier for developers to compartmentalize code to achieve memory-safety The problem here is that this is incomplete. Many many many…

Well, there is still an important difference between Java and Rust — are you driving with a guardrail on a field vs are you driving next to a cliffhanger. The JVM has well-defined bad execution as well, e.g. data racing is well-defined. Safe Rust does prevent data races statically, but if they do happen due to a bad unsafe block, you are entirely on your own. While memory safety can abruptly stop both processes, FFI…

I don't have much Java experience, so I'll have to take your word for it. But it's not completely obvious to me that you're correct. We've moved from an absolutist idea of memory safety to trying to build an implicit ontology of tiers of memory safety based on usage. Now you're talking about going and doing surveys of code and trying to measure the relative frequency of certain things and then using that to drive a tiered hierarchy of memory safety in programming languages.

Sounds hard to do and you also haven't accounted for what problems are being solved in each language. I can pretty much decide to never ever use `unsafe` again, but I'll be leaving perf on the table. If I were writing Java, I would probably be fine with that. But I'm working on interesting problems that want the most perf possible, and so U do very occasionally justify `unsafe` when writing Rust.

Re: Memory Safe Languages in Android 13

#466

Post by peoplefromibiza » Fri, Dec 02, 2022, 11:43 AM UTC

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

Well, first of all, this is said but not proven.

But it's easy to prove that memory safety bugs are not a significant percentage of the total number of bugs, even Google agrees.

Vulnerabilities are not the same thing as bugs, a vulnerability like spectre or meltdown are not due to a bug in the software, have an ubiquitous immediate impact on 100% of the devices and are much harder to fix or mitigate, sometimes it's could even prove impossible.

The same bias can be explained using the exact same words used in the article

"Despite most of the existing code in Android being in C/C++, most of Android’s API surface is implemented in Java. This means that Java is disproportionately represented in the OS’s attack surface that is reachable by apps."

It can be read as: of course most of the vulnerabilities are due to memory safety bugs, it's much harder to gain root privileges exploiting a bug on the colors of a specific element of the UI, assuming it would be possible.

It can also be read as: most of the userland software is based on Java, which is memory safe by default, assuming there are no bugs in the implementation of the JVM, which is entirely not Java.

Given that, the problems become

- rewriting the entire ecosystem in memory safe languages requires rewriting everything from scratch, which is a task that even Google will have huge problems to complete (reminder: Google is the number one killer of its own projects) in reasonable time or without wasting more money that it's worth on it. Is an half complete not battle tested complete rewrite actually safer? Historical data says it usually isn't.

- are the user actually safer when memory is safe? I mean, memory safety bugs gave us jailbreaking for locked devices, memory safe languages gave us bugs like CVE-2021-44832

I wouldn't classify the issue as black/white, there's a lot of grey to be considered.

Re: Memory Safe Languages in Android 13

#467

Post by ilyt » Fri, Dec 02, 2022, 11:43 AM UTC

jstimpfle wrote: post #426

p-e-w wrote: post #368

Earlier quoted context omitted.

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

My limited experience with Rust was that I need to know exactly what I want to do in the code and compiler is there to make sure I write that intent as actual code, not my assumptions about how the code will work.

I don't feel that I am less in control, just that all of that needs to be put in code and not just go "okay, I know this part don't need a lock coz I will never call it concurrently" and hope for best.

Even writing for embedded (as in no os, tens of kilobytes of RAM microcontrollers) haven't been too bad althought I haven't managed to convince borrow checker to borrow non-contigous block of bits from a register yet... althought that's what unsafe{} is for after all

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

The closer one would be "read that 300 pages of how to do stuff safely and apply it". Once you get into good habits it's not a problem but investment is there

Re: Memory Safe Languages in Android 13

#468

Post by ilyt » Fri, Dec 02, 2022, 11:45 AM UTC

vineyardmike wrote: post #437

p-e-w wrote: post #368

Earlier quoted context omitted.

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…

> 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. But it is mostly about existing software, even if its not about replacing existing software. I write C++ code every day. I hate it, and I'd rather not. But I use C++ libraries written by my teammates, and…

>> This is the exact equivalent of physicians continuing to use unsafe medical procedures

> Plenty of platforms don't support rust. Just because you've improved knee surgery, doesn't mean it works on an elbow... yet. And sometimes you still gotta perform surgery on elbows.

That's a non-argument, obviously if it isn't even applicable it's not a discussion. Also most of what people code on does support Rust

>> if the programmer is "smart enough".

>Can't defend this, but tbh I've never heard it.

Programmer is never smart enough. Decades of bugs showed that

Re: Memory Safe Languages in Android 13

#469

Post by wrongtime » Fri, Dec 02, 2022, 11:45 AM UTC

jstimpfle wrote: post #439

p-e-w wrote: post #366

Earlier quoted context omitted.

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…

It's not like you make a bad git commit and suddenly the world stops working. There are checks and processes and redundancies that reduce the impact of human error dramatically. The earth is still spinning, despite so many things not working everywhere. That's not just in software. In every system, there's relatively few single points of failure. As you zoom out, failure points disappear and new ones appear. Sure, st…

>It's not like you make a bad git commit and suddenly the world stops working.

https://qz.com/646467/how-one-programmer-broke-the-internet-...

Re: Memory Safe Languages in Android 13

#470

Post by Sirened » Fri, Dec 02, 2022, 11:45 AM UTC

gnull wrote: post #440

Sirened wrote: post #374

Earlier quoted context omitted.

writing exploits, for example, is an utter pain in today's safe languages :) C is unmatched in the sheer ease of manipulating raw bytes with some light structuring on top for convenience. I've tried writing exploits in Swift a handful of times but I always gave up after I found myself buried under a pile of UnsafeMutableRawBufferPointers.

You mean, manipulating strings of bytes? Bytes don't have to be memory, you can just use bytestrings in Python or whatever. Raw memory access is something you normally need to create vulnerabilities, not to exploit them :)

har har :)

It's an ergonomics thing, not a "can't" issue. There is a reason I called out Swift in particular—their "unsafe" APIs are so horrid to use that they make you regret doing unsafe things in the first place. Plus, throw in FFI and now you've got an even worse problem because not only are you forced to use the unsafe types, but often a lot of the critical APIs you need to interface with (in *OS exploitation, mach is the worst offender) have such funky types due to their generic nature that you have to go through half a dozen different conversions to get access to the underlying data.