|
|
Unencrypted kernel release for iOS 10 was intentional, Apple claims
|
|
|
|
MacNN Staff
Join Date: Jul 2012
Status:
Offline
|
|
The kernel code at the heart of iOS 10 is unencrypted for performance purposes, Apple has advised. Following after the discovery of the kernel being issued without encryption as part of the iOS 10 beta ahead of its general release this fall, Apple claims the change from using an encrypted kernel for this version was an intentional decision by the company for valid reasons, instead of a mistake in the mobile operating system's creation and distribution.
"The kernel cache doesn't contain any user info," a brief statement from Apple provided to TechCrunch begins, continuing "and by unencrypting it we're able to optimize the operating system's performance without compromising security."
Typically, the kernel is protected by encryption, obscuring the code and increasing the work for anyone attempting to discover a flaw that they could then maliciously use to their advantage. Making the code more easily accessible without encryption can usually be of benefit, theoretically allowing more eyes to see the inner workings and potentially bringing up more flaws to the attention to the company that it can then fix. The choice to keep it unencrypted could also seen as a move to increase transparency, showing developers and users there aren't any backdoors usable by law enforcement agencies.
(
Last edited by NewsPoster; Jun 23, 2016 at 11:16 AM.
)
|
|
|
|
|
|
|
|
|
Junior Member
Join Date: Dec 2005
Status:
Offline
|
|
Ahem. You're using two terms interchangeably which aren't: specifically "kernel" and "kernel cache" (which is a cache of the code executed by the kernel with code relocation, dynamic binding, decryption, etc.) ready go.
Note where Apple's text says "kernel cache" and yours says "kernel"
Apple's point is that there's no reason to encrypt code because it's already open source, and doesn't contain any user data, so there's no reason to take the performance hit.
Your text makes it sound like they're not encrypting user data in the kernel, which is false.
This was probably a performance operation, maybe to take care of hardware assist and I'd suspect the reason for the same change not appearing in the 32-bit kernel is that it's not being (as) actively maintained.
|
|
|
|
|
|
|
|
|
Junior Member
Join Date: Jul 2012
Location: South Wales, UK
Status:
Offline
|
|
The first line has been altered to clarify it is the code itself that's not encrypted. Hopefully this helps clear up some of the confusion.
|
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: Aug 2007
Status:
Offline
|
|
Quoteth Pee Wee Herman:
"I meant to do that... "
|
|
|
|
|
|
|
|
|
Dedicated MacNNer
Join Date: Aug 2001
Location: California
Status:
Offline
|
|
I would imagine that it would be functionally impossible for anybody, let alone an organization the size of Apple, to make a change like this unintentionally. It's not a "whoops, forgot!" kind of thing.
The question is what the logic behind the decision was, which could be performance, could be because they want to reduce the chance of hoarded zero-day security exploits, or it could be some of both.
|
|
|
|
|
|
|
|
|
Junior Member
Join Date: Dec 2005
Status:
Offline
|
|
To be pedantic, the kernel code could still be "encrypted" (i.e. compressed and signed) and decompressed into the (unencrypted) cache for execution.
It sounds like this was done for performance reasons.
I though "I meant to do that" was the average cat after falling off anything.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Forum Rules
|
|
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is Off
|
|
|
|
|
|
|
|
|
|
|
|