301–310 of 408 posts
Earlier quoted context omitted.
They wrote it the first time, didn't they? C isn't special, and training isn't special.
Time is pretty special. iOS alone is over a decade old and a constantly evolving target and it's itself a direct descendant of a 30+ year old system.
That decreases the amount of code to replace, doesn't it?
Earlier quoted context omitted.
It's worth engaging with the fact that essentially nobody disagrees with this (someone will here, but they don't matter), and that it's not happening not because Apple and Google don't want it to happen, but because it's incredibly, galactically hard to pull off. The Rust talent pool required to transition the entire attack surface of an iPhone from C, C++, and ObjC to Rust (substitute any other memory safe language,…
They wrote it the first time, didn't they? C isn't special, and training isn't special.
Languages and understanding them is not special, but decades of development of two different kernels is a huge time investment. Even though Linus Torvalds wrote the basic Linux kernel in 5 months, it was very simple at first.
I doubt writing an entire POSIX-compatible replacement for a kernel would be a small or quick endeavor, and Apple has shown resistance to adopting anything with a GPL 3 license iirc. That is why they switched to ZSH from Bash.
Not to go all 'Rust Evangelism Strike Force' but almost universally, these exploits leverage memory unsafety somewhere in the stack, usually in a parser of some kind (image, text, etc). The fact that this is still tolerated in our core systems is a pox on our industry. You don't have to use Rust, and it won't eliminate every bug (far from it), but memory safety is not optional . We truly need to work more towards eli…
You don't know what you're asking for. In reality, you'll end up replacing C code with memory unsafely with Rust code written by people who understand Rust less than they understand C. The problem? The Rust Evangelism Strike Force always assumes that if you replace a C program with a Rust program, it'll be done by a top-tier expert Rust programmer. If that isn't the case (which it won't be), then the whole thing fall…
Earlier quoted context omitted.
> Haskell Lego Edition Gatekeeping much?
I took the time to learn Rust well in spite of how annoying the Jehovas Witness routine has been for like, what, 5-10 years now? I worked with Carl and Yehuda both on the project right before Cargo (which is pretty solid, those guys don’t fuck around). I think I’ve paid my cover-fee on an opinion.
Earlier quoted context omitted.
They wrote it the first time, didn't they? C isn't special, and training isn't special.
macOS runs the Darwin kernel (developed at NeXT using the Mach kernel, then at Apple). NeXTSTEP was based on a BSD UNIX fork. Development of BSD at Berkeley started in 1977. NeXT worked on their kernel and the BSD UNIX fork in the '80s and '90s before being purchased by Apple. NeXTSTEP formed the base of Mac OSX (which is why much of the Objective-C base libraries start with `NS-something`. There is 45 years worth of…
Earlier quoted context omitted.
Right, but a memory unsafety but is what takes a harmless logic bug in an image parser with no filesystem access to an RCE and sandbox escape. Memory unsafety allows you to change the 'category' of the bug, you become free to do whatever whereas a logic bug forces to to work within the (flawed) logic of the original program.
Not necessarily; see https://github.com/LinusHenze/Fugu14/blob/master/Writeup.pdf for example. It's a full chain that repeatedly escalates privileges without exploiting any memory safety bugs by tricking privileged subsystems into giving it more access than it should have, all the way up through and beyond kernel code execution.
- sane integers: no unsafe implicit cast, more ergonomic overflow/saturate/checked casts
- sane strings: slices with length, standardized and safe UTF-8 operations
- expressive typing preventing API misuse: monads like Optional/Result, mandatory exception handling, better typedefs, ADTs vs tagged unions
And even without the full Rust ownership model, I'd expect the following to solve a majority of the memory safety problems:
- array bounds checks (also string bounds checks)
- typed alloc (alloc a specific type rather than N bytes)
- non-null types by default
- double-free, use-after-free analysis
- thread-save std APIs
In the write-up you linked, Section 2 is a missing error check => Result would surface that. The macOS case contains a relative path vs string comparison => expressive typing of Path would disallow that. DriverKit exploit is a Non-NULL vs NULL API mistake. Kernel PAC is a legit ASM logic bug, but requires a confusion of kernel stack vs. user stack => might have been typed explicitly in another language.
Not to go all 'Rust Evangelism Strike Force' but almost universally, these exploits leverage memory unsafety somewhere in the stack, usually in a parser of some kind (image, text, etc). The fact that this is still tolerated in our core systems is a pox on our industry. You don't have to use Rust, and it won't eliminate every bug (far from it), but memory safety is not optional . We truly need to work more towards eli…
Earlier quoted context omitted.
It took decades.
So make the initial goal a portion. It's not like Apple is going to go away any time soon. The second best time to start is now. And a lot of that was design work that still holds, and a lot of that was code that has been obsoleted.
Earlier quoted context omitted.
I honestly don't understand this. If Google or Apple wanted it to happen, they could force those developers to learn Rust. Are you saying the people that wrote the products in question can't learn Rust well enough to achieve the goal?
Start with the fact that practically all software development at Apple and Google would cease for multiple months while people dealt with the Rust learning curve, which is not gentle, and proceed from there to the fact that Rust demands (or, at least, urgently requests) architectural changes from typical programs designed in other languages. Now: rewrite 20 years worth of code. Let's make sure we're clear: I agree --…