What’s wrong with Apple? Why is modern iOS so buggy?

A friend at Apple told me that the testing story for iOS is complete shit, and they actually rely on hundreds of humans to test their software to make up for poor automated testing.

Apple takes the approach of throwing humans instead of automation at a problem quite frequently [1]:

> The press release mentions RMSI, an India-based, geospatial data firm that creates vegetation and 3D building datasets. And the office’s large headcount (now near 5,000) [used to create Apple Maps]

The lack of automated testing is something Apple is working on fixing, but they're a ways away from having anything substantial. The terrible iOS 13 release quite significantly bumped up the internal priority of stability and testing. iOS 14 is likely to be far less buggy than iOS 13 because of this culture change.

[1]: https://www.justinobeirne.com/new-apple-maps

Don't worry, the exploits are being used only against oppressed minorities[1].

[1]https://arstechnica.com/information-technology/2019/09/apple...

Isn't the root cause that two entities can free the given memory and have no high level coordination of it? It basically states this in the article.

That's the category of bug (use after free), but that's not the root cause. The root cause would be found from an analysis of the kernel design to understand why it was possible to get into this scenario in the first place. Uncoordinated mechanisms accessing the same data structure (like you mention) might be the root cause, but it didn't feel like this article explored it (not that they need to, since P0 is focused on the exploit itself - I'm just really curious what 'went wrong' with respect to the architecture here).

(I’m trying to recall the Lightspeed bug from memory so I may have some of it wrong.)

It all boils down to poor state management in a single algorithm.

The algorithm allocates a kernel object, then sends off a subroutine to do some work. (The subroutine happens to run in another thread but that’s not really relevant to the bug.) As part of its job duty, the subroutine is supposed to free the object after its work is done, but only if condition A is true.

If A is false, the subroutine won’t free the memory, and it’s implied that the main routine is supposed to free the memory instead.

Now the issue is that there’s no common code that checks condition A. Instead, the main routine and the subroutine have slightly different ideas about whether condition A is true or not. The condition’s logic is pretty simple so it’s understandable that the kernel developer decided to write the same condition in two different places and two different forms (instead of e. g. factoring it out into a macro). Still, they managed to get it wrong.

The result is that in one particular case, the subroutine thinks A is true. So it frees the object. When the main routine gets back control, it thinks A is false (due to the duplicated, slightly wrong logic), and frees the object, too.

There’s only a small time window between those two frees. But the window is large enough that a userspace thread, if it tries often enough, can force its own object into the place where the kernel object used to be, just in time before the double free happens.

That's a bit like saying the root cause of an automobile accident is that two people were driving without a physical barrier between them.

The statement is true but is not a root or a cause. Its a high level description of what happened.