How Google's Project Zero made Apple refactor its kernel When Apple shipped its security bug-fixes earlier this week, one patch mostly passed under the radar. Ian Beer of Google Project Zero, who found a deep-down vulnerability in the XNU kernel, first reported it to Apple in February this year, and it took until now to clean it up properly. It took eight months, apparently, …
All you need to know, previously apply took the fast lane, now they have to drive safely. Expect a notice increase in iPhone lag...
Good job iOS is still so basic, still not supporting proper multitasking and background service processes, otherwise it would be even worse.
The Mach kernel had a reputation for being slow - it had a slight overhead in being a message-based kernel, but most of its performance deficit came from rights checking.Sumarising the blog post, it would seem that XNU (the NextStep and then MacOS and iOS kernel based on Mach) got round all of that by adding direct system calls that simply bypassed the message-passing and the slow checks and kept pointers to structures that would otherwise have been considered transient.
Of course, ironically, it was precisely the message-passing that made the transience clear and those access checks that were designed to stop this kind of problem arising in the first place.
I think this one needs to be filed under "layer violation considered harmful".
If the performance issue was x86 specific then it would show up on Linux and Windows.
But it appears it's the hardware task switch which is slow on 32 bit processes. However that's only used for transitioning between kernel and user land. (See stackoverflow.)
In any case, NeXTStep's kernel was first written for Motorola 68030 CPUs, not x86. From there it went to x86, then PowerPC, then x86 again.
If my memory hasn't failed me, 68030 still had only two execution contexts that it had inherited from 68000: User and Supervisor, but moving between them was only a matter of a stack push and a status register bit flip (you couldn't do it explicitly: you had to generate an exception, usually via the TRAP instruction, to enter Supervisor mode, or use the RTE instruction to leave it)
> Any idea of the performance on ARM?
Well, actually, it wasn't the context-switching that was the issue, it was the IPC (messaging and permissions) which reportedly was responsible for about 70% of the cost, so CPU effects were minor by comparison.
More modern microkernels are a lot less complicated than Mach, but that just ends up punting elsewhere the problems Mach was supposed to solve.
> Well, actually, it wasn't the context-switching that was the issue, it was the IPC (messaging and permissions) which reportedly was responsible for about 70% of the cost
In classic Unix IPC (think SYSV msg queues, sockets, locks, pipes, you name it) the majority of the time is taken up in the switch from userland to kernel land. Whether you want to consider this to be a context switch or not is kind of up to you but there are a lot of similarities. Where you can replace full kernel entry high level code system calls with a lightweight assembler don't need to state save, don't need a kernel stack etc. calls then massive performance improvements are possible, massive as in many orders of magnitude not a few tens of percent.
QNX, the BB10 ancestor, claims to supposedly have a clever optimization of message passing, which, again claimed, made it a better microkernel than its predecessors (such as MACH).
This is old tech, QNX was around (in 4MB RAM on 386s) in the early 90s, so the patents have lapsed.
Is any of that applicable to this kinda problems?
No snark here. Google found a bug. Apple accepted it and set about the task of fixing it.
Some bugs are easy, some are hard. This one sounds like a lot of work to me especially if this practice had used been in the kernel for a long time
Apple have fixed it (apparently) so kudos to them and kudos to Google for finding it in the first place.
I've just found a bug with a piece of software. Took me several weeks to track down and document. It took longer than it should have done because the behaviour changed between release versions. It is exceedingly boring and painstaking work especially documenting all the test cases.
The software maker has accepted my findings and will be sorting it out. Because it is a possible security hole I'm posting AC.
Because it is a possible security hole I'm posting AC.
Why would that matter? It's not as if you posting an exploit here.
I also take the time to document bugs and inform the relevant developers. I've recently informed Apple of a bug in their handling of OOXML files but I won't be holding my breath for a response. This is only too often the case with them so kudos for Google for holding back from publishing. I wonder if the naming and shaming of Microsoft earlier in the year helped focus Apple's attention on this?
Publishing an exploit publicly is one thing. Keeping it secret but publishing your name and address so that "Honest Ron" can pop round and use friendly persuasion to get the details out of you or your spouse and children, is another. Name and address also might be the clue that it is worth asking about e.g. A.Banker@BritishVirginIslands.com
The anonymous way, "Honest Ron" has to use friendly persuasion on The Register first, which I'm not betting on being impossible, unless "Anonymous Coward' actually is untraceable even by the Reg. But also there's no definite indication, besides the coyness itself, that anyone else would actually be interested in abusing the system.
"A Friend"
(Black helicopter seems unlikely for Ron but I'll put it on anyway)
"Why would that matter? It's not as if you posting an exploit here."
Someone might know be able to put two and two together and work out who he is.
So let me get this straight: Apple had the XNU kernel (i.e. big chunks of Mach) and found that doing things the proper way (y'know, message passing as the Mach design intended) was too slow, so they bypassed it. And now Google (Google! of all people) have identified what a security risk that is.
Meanwhile, in an office in Redmond, Rick Rashid is laughing his head off.
Strange times we live in.
I don't really see the big deal to be quite honest.
Most complicated software, including operating systems, will inevitably have potential security holes that, despite tons of very competent developers, will go unnoticed.
The key thing here is Apple closed the security hole and it does not seem like it was an easy fix by any means. You can't really go mucking about with a fundamental issue in a kernel and expect to be able to release the finished product to millions upon millions of devices without going through a whole load of testing and polishing.
I know people like to bash Apple, MS, Google and other big IT companies but it gets a bit tiresome at after a while.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
