Tom's Further Musings About the iPhone

A few weeks ago -- right after the iPhone was launched, in fact -- I heard from frequent Dr. Dobb's contributor Tom Thompson who had been mulling over the new device. He shared his initial musings about the iPhone with us.

So the iPhone has been out -- what? a month or so now? -- giving Tom, who knows a lot of Apple software and mobile phones, a chance to further consider the iPhone. Here are his most recent musings on the iPhone.

-- Jeffrey Veen

Jeffrey was talking about Web design when he said that, but he could have been talking about consumer electronics. Everything about the hardware and software design of consumer electronics is a trade-off. Engineers struggle to build a gadget that has good mix of features, with long battery life...all while trying to hit a price point that won't make the consumer balk at buying the product. Really good engineers and UI designers can deliver the right blend of capabilities while concealing the compromises.

Which brings us to the iPhone. Countless hours have been spent trying to breach the device so that third-party applications -- and I don't mean scripts in the phone's Safari web browser -- can be installed, and it looks they've succeeded in doing it. The techniques used to accomplish this feat are far beyond what the casual consumer is capable of. During these endeavours, it was discovered that all of the phone's software ran at root level. That is, everything executes with administrator privilege. The security implications are obvious: an errant program has unfettered access to *everything* in the phone. Not only could it do damage to the iPhone's system software, but it could make off with your personal information.

"Idiots," some developers say of Apple for doing that. However, given that the iPhone appears to run a desktop operating system, it's easy to jump to the conclusion that they got sloppy. Nothing could be further from the truth. Let's take a closer look and speculate why the Apple engineers did this.

Steve Jobs says the phone runs Mac OS X. I'll grant that this statement is true, but the iPhone's Mac OS X implementation is as similar to the desktop version of Mac OS X as a Subaru wagon is to a Ferrari. Like the cars, the iPhone Mac OS X has the same core components as its desktop sibling, but otherwise in key ways they are also quite different. The desktop Mac OS X has access to loads of memory, massive amounts of storage, and has little concern about power consumption. The iPhone Mac OS X uses a limited amount of RAM (unlike the desktop world, for consumer devices RAM is the most expensive part in the device, and not the CPU), limited storage (the OS itself is supposedly shoehorned into only 700 MB), has Flash storage options that top out at 8GB, and power consumption is paramount. Things are going to be different for the iPhone OS.

Why would Apple use its desktop OS in a consumer device? Because it attacks two critical problems at once. First, it contains software costs because you're not starting from scratch: you're beginning with stable code that's been field-tested for years. Second, the OS has been ported to two processors, the PowerPC and Intel CPUs. (Mac OS X started life as NextStep running on a 68030 CPU.) These code ports made the core OS code sufficiently hardware-agnostic so that a port to the ARM processor derivative (supposedly an ARM1176JZF CPU) wouldn't be costly. Using Mac OS X as the iPhone's OS therefore brings reliability and reduced software development costs to the design. Apple also had an army of engineers seasoned from the recent Intel port to tackle the job.

The ARM1176JZF processor chosen as the iPhone's CPU has a number of features that appeal to mobile device designers. Among these were: a powerful yet compact ARM 6 instruction set, low power consumption, on-chip caches, a vector floating-point coprocessor (handy for 3D graphics), Single-Instruction, Multiple Data (SIMD) instructions for optimized graphics and video processing, a Jazelle coprocessor for hardware-supported Java execution, and last but not least, TrustZone technology for the protection of critical code and data.

Keep in mind that the ARM1176JZF is not a fully-fledged desktop CPU. Its primary function is to achieve many things while going easy on a battery. As a case in point, unlike a typical desktop CPU with MMUs that seamlessly implement memory protection, the ARM1176JZF's TrustZone mechanism requires some changes in the software to provide memory protection. Specifically, the software must be factored into non-secure and secure elements. A software monitor manages communications between the non-trusted and trusted environments.

From a code porting standpoint, right away you can see problems with this scheme. TrustZone requires a considerable code rewrite to split the software into secure and non-secure elements. And as any software engineer knows (or should), code modifications are guaranteed to introduce bugs that adversely affect the reliability of the OS. This requires more testing to ensure that the enhancement isn't going to create more problems than it solves. The one-two punches of rewriting the software and testing it drives up the cost of implementing the TrustZone mechanism.

Another issue with the TrustZone mechanism is that it adds overhead. Considering that the processor is running a full-blown OS, and this overhead probably degrades performance significantly. If Apple has learned anything from its into forway into the PDA market with the Newton, it's that performance is critical.

Given all of these negatives, the Apple engineers probably decided not to use the processor's TrustZone feature. Understand that I'm not criticizing the TrustZone feature of the CPU. If the design team had more time, they probably would have used it. This is one of those design trade-offs that must be made, particularly when you're trying to get the product to market.

Having given up on memory protection, Apple did do things to lock down the system. Shoehorning the OS into less than a gigabyte of storage meant discarding a lot of software utilities, such as console and ssh, which are avenues for trouble. Copy-and-paste also didn't make the cut possibly because of UI issues, but more likely because it's hard to anticipate the memory consumption of such an operation, which is deadly in a device with severely-constrained memory resources. Furthermore, cut-and-paste can present an opportunity for breaching the system. For similar reasons, saving video clips and interactive Flash payback in the browser wasn't supported.

In the end, it was left up to the Safari browser to function as a secure sandbox for "applications" downloaded over the air from the Internet. Based on the exploit announced by Independent Security Evaluators, it seems that Safari's security on the iPhone has been compromised. To their credit, the outfit has notified Apple and given them time to correct the situation. The browser can and will be fortified, although this is always a cat-and-mouse game, with Apple trying to outpatch the black hats. Perhaps the Jazelle coprocessor and a Mobile Java implementation -- accelerated by Jazelle -- can be used create a safer sandbox.

In summary, it's easy to criticize the flaws of the iPhone, while ignoring the fact that it offers many capabilities such as messaging, browsing, and music playback on top of the phone functions, and seems to do them well. Let's keep in mind that a lot of difficult trade-offs were made in getting the iPhone to market. As Jeffrey says: "Good design is problem-solving."

It's just that sometimes there aren't ideal solutions to some of these problems. Apple could have easily done far worse. I have every reason to believe they'll fix these problems in time.

Posted by Jon Erickson at 01:20 PM  Permalink