Unsigned 0.10 kext will not load in Yosemite (10.10.0)

[tyrotex]

Thanks for making this driver available. However, it appears Apple are no longer permitting unsigned kexts to be loaded in Yosemite, rather than just warning about it, as in Mavericks. From my system.log:

kextutil -t /System/Library/Extensions/SATSMARTDriver.kext
Notice: /System/Library/Extensions/SATSMARTDriver.kext has debug properties set.
Diagnostics for /System/Library/Extensions/SATSMARTDriver.kext:
Code Signing Failure: not code signed
ERROR: invalid signature for fi.dungeon.driver.SATSMARTDriver, will not load

Is there any way we can get the driver working in Yosemite?

[alvarnell]

On Mon, Nov 10, 2014 at 04:45 PM, John Bluhdorn wrote:

Thanks for making this driver available. However, it appears Apple are no longer permitting unsigned kexts to be loaded in Yosemite, rather than just warning about it, as in Mavericks. From my system.log:

kextutil -t /System/Library/Extensions/SATSMARTDriver.kext Notice: /System/Library/Extensions/SATSMARTDriver.kext has debug properties set. Diagnostics for /System/Library/Extensions/SATSMARTDriver.kext: Code Signing Failure: not code signed ERROR: invalid signature for fi.dungeon.driver.SATSMARTDriver, will not load Is there any way we can get the driver working in Yosemite?

You would have to set the nvram variable kext-dev-mode=1, but be warned this will allow any unsigned .kext to load, including rootlets, malware, etc.

A discussion on how to do this is at <http://www.insanelymac.com/forum/topic/298402-os-x-yosemite-dps-builds/page-5 http://www.insanelymac.com/forum/topic/298402-os-x-yosemite-dps-builds/page-5>.

The best solution would be to convince Apple to add 0.10 to it’s OSKextSigExceptionHashList.

-Al-

Al Varnell Mountain View, CA

[tyrotex]

Thanks for the info @alvarnell.

Obviously, I'm very late to this particular party which has been going on since the Yosemite DPs were released. Trying to run OS-X-SAT-SMART-Driver is the first time I've encountered the issue. After reading further, I can see that its lucky I'm not using SSDs requiring TRIM.

You would have to set the nvram variable kext-dev-mode=1, but be warned this will allow any unsigned > .kext to load, including rootlets, malware, etc.

Although I would prefer not to make my system vulnerable, I guess it would not be any worse than it was under Mavericks.

The best solution would be to convince Apple to add 0.10 to it’s OSKextSigExceptionHashList.

Do you know if there is there any process for doing that?

There must be some "official" way around this issue, otherwise all non-commercial development for OS X will grind to a halt or users will be forced to open there Macs to attack. Way to go, Apple!

Given this is an Apple issue, rather than an OS-X-SAT-SMART-Driver issue, I'll close it now. Thanks again for your help.

[kasbert]

Somehow the version 0.8 is in the exception list. The version 0.9 is also there, but it was causing trouble for people, so I removed it. Of course, you can find it from the git history.

[macuserguru]

“Somehow the version 0.8 is in the exception list.“ Understand I this right - 0.8 would work well in Yosemite too?

I dont't understand why Apple don't make his own kext for this feature.

[kasbert]

Yep, 0.8 should work in Yosemite.

The SAT feature does not work with every enclosure and it could cause problems. They should test with all enclosures (not possible) or ask vendors to provide drivers or info (that won't happen either).

[tyrotex]

Thanks to everyone for the comments about 0.8. The 0.8 kext did load OK thanks to the exception list. However, given the Info.plist in 0.8 is pretty empty, it did not show up my external USB drive (Seagate Expansion ST3000DM001) in Disk Utility. However, I finally succeeded by copying the 0.10 Info.plist (which contains an entry for my HDD) into the 0.8 driver and reloading everything. So, I guess this would rate as a workaround for Yosemite users.

I agree with @macuserguru :

I dont't understand why Apple don't make his own kext for this feature

[alvarnell]

On Tue, Nov 11, 2014 at 06:06 PM, John Bluhdorn wrote:

I agree with @macuserguru https://github.com/macuserguru :

I dont't understand why Apple don't make his own kext for this feature

Well I disagree. I don’t understand why Apple doesn’t pay @kasbert for this technology, buying him out or hiring him.

-Al-

Al Varnell Mountain View, CA

[tyrotex]

On Wed, Nov 12, 2014 at 1:36 PM, Al Varnell notifications@github.com wrote:

On Tue, Nov 11, 2014 at 06:06 PM, John Bluhdorn wrote:

I agree with @macuserguru https://github.com/macuserguru :

I dont't understand why Apple don't make his own kext for this feature

Well I disagree. I don’t understand why Apple doesn’t pay @kasbert for this technology, buying him out or hiring him.

I certainly think that would be the best for all concerned, and was not trying to imply that Apple should cut out FOSS developers.

I really appreciate all the work that @kasbert has down to make this driver available. It patches a major hole in Apple's SMART usage, particularly given that internal drives are becoming less important than they once were in Macs, and bulk data is increasingly held on large external drives.

We just need some way to have this useful functionality survive OS X updates and work with Apple security policies.

[macuserguru]

Did you mean this both https://github.com/kasbert/OS-X-SAT-SMART-Driver/blob/master/SATSMARTDriver/Info.plist

Info.plist from driver ver.0.8 is not empty here - but I must compare both.

Could I change the Info.plist without get problems with the signed drivers?

[killerovsky]

@alvarnell:

I agree with @macuserguru:

I dont't understand why Apple don't make his own kext for this feature

Well I disagree. I don’t understand why Apple doesn’t pay @kasbert for this technology, buying him out or hiring him.

Just an idea: What about writing online petition to Apple about official inclusion of SAT driver into OS X (petition via change.org)? No matter whether it will be Apple's own realization or "kasbert"-based. It would be cool if some native speaker of English will do this (properly formulate such petition). I could try to promote this petition among different Mac user groups all over the world.

[macuserguru]

A petition is a very good idea, but we need a solution for today too.

Another way is, as GPGTools for Yosemite gone. https://gpgtools.org “When we first announced that future versions of GPGMail would be available for a small fee, we were pretty scared about the reactions.“

[thepen]

I'm not a developer, unfortunately wouldn't know where to start in using v0.8 or updating plist. However, I did find the apple feature request site: https://www.apple.com/feedback/macosx.html

You can make a request here if you wish, please do, apparently they do pay attention. I just posted the below in 2 parts because of the form limits, please feel free to copy/modify:

Yosemite / kext signing 1of2 and 2of2

Dear Apple,

I've been an Apple fan and customer since my first Mac SE. Thanks for the many excellent products over the years. This is my first time writing in. However, I'm having issues that've been such a time waster to so many, and puts data at risk. It's quite disturbing, what are you thinking? Having upgraded to Yosemite I've encountered several challenges from the new kext signing security feature. My SSDs requiring TRIM support are now without TRIM support.

By disabling kext signing, Yosemite creates a security context that prohibits developers from writing drivers that work without disabling kext signing is confounding. Any and All DIY systems released prior to the new Apple preconfigured hardware purchasing option are unnecessarily stunted by this policy.

Planned obsolescence is understandable I suppose, but a forced choice between security (disabling kext signing) and hardware maintenance (TRIM support or externa drive SMART status reporting) is going too far.

This issue has been such a time waster and puts data at risk. People with DIY TRIM enabled SSDs are on forums unable to start up. SMART status is inaccessible with external drives. It's quite disturbing, what are you thinking? Please create a mechanism for approving 3rd party TRIM support and SMART status checking drivers.

Sincerely, ...

[alvarnell]

Sorry, but I can't fully agree with you position on this.

I would much prefer to be using signed kept files, knowing that it provides an additional level of security to prevent malware from using Kernel extensions to do it's dirty work. I realize that imposes a small fee to obtain an Apple Developer ID, but am certain that could easily be offset from user donations for software as useful as this is.

As far as TRIM is concerned, I'm told that only one manufacturer now recommends it, the rest having provided firmware solutions to accomplish the same thing. Why isn't it up to that manufacturer to provide the means of legally enabling it on OS X machines?

Sent from Janet's iPad

-Al-

Al Varnell

On Dec 29, 2014, at 3:22 PM, thepen notifications@github.com wrote:

I'm not a developer, unfortunately wouldn't know where to start in using v0.8 or updating plist. However, I did find the apple feature request site: https://www.apple.com/feedback/macosx.html

You can make a request. I'm making one to the effect of

Dear Apple, I've been an Apple fan and customer since my first Mac SE. Thanks for the many excellent products over the years. This is my first time writing in. However, I'm having issues that've been such a time waster to so many, and puts data at risk. It's quite disturbing, what are you thinking? Having upgraded to Yosemite I've encountered several challenges from the new kext signing security feature. My SSDs requiring TRIM support are now without TRIM support. By disabling kext signing, Yosemite creates a security context that prohibits developers from writing drivers that work without disabling kext signing is confounding. Any and All DIY systems released prior to the new Apple preconfigured hardware purchasing option are unnecessarily stunted by this policy. Planned obsolescence is understandable I suppose, but a forced choice between security (disabling kext signing) and hardware maintenance (TRIM support or externa drive SMART status reporting) is going too far.

This issue has been such a time waster and puts data at risk. People with DIY TRIM enabled SSDs are on forums unable to start up. SMART status is inaccessible with external drives. It's quite disturbing, what are you thinking? Please create a mechanism for approving 3rd party TRIM support and SMART status checking drivers.

Sincerely, ...

— Reply to this email directly or view it on GitHub.

[macuserguru]

The best way, Apple support this both things self! SMART access for all external drives over all ways TRIM for all internal and external third party SSDs

[thepen]

@alvernall wrote "I realize that imposes a small fee to obtain an Apple Developer ID, but am certain that could easily be offset from user donations for software as useful as this is."

The thing is, Apple is not credentialing developers or 3rd party manufacturers for kext signing, see http://www.cindori.org/trim-enabler-and-yosemite/

Curious, what's the basis for suggesting "only one manufacturer now recommends it, the rest having provided firmware solutions to accomplish the same thing."? All I've read suggests otherwise, TRIM helps all SSDs more or less. Specifically WRT write amplification. http://www.cindori.org/trim-vs-garbage-collection/

":Why isn't it up to that manufacturer to provide the means of legally enabling it on OS X machines?" See above.

[alvarnell]

On Thu, Jan 01, 2015 at 04:00 PM, thepen wrote:

@alvernall wrote "I realize that imposes a small fee to obtain an Apple Developer ID, but am certain that could easily be offset from user donations for software as useful as this is."

The thing is, Apple is not credentialing developers or 3rd party manufacturers for kext signing, see http://www.cindori.org/trim-enabler-and-yosemite/

I think you are misreading the article. Apple won’t credential "Trim Enabler" as their stated position is that "Trim may cause data corruption when used with third party SSD’s.” I don’t know whether I believe this or not, but still it’s Apple’s position. I currently have about a dozen 3rd party extensions that Apple currently allows and as we know SATSMARTDriver.kext 0.8 and 0.9 have been whitelisted for now. Curious, what's the basis for suggesting "only one manufacturer now recommends it, the rest having provided firmware solutions to accomplish the same thing."? All I've read suggests otherwise, TRIM helps all SSDs more or less. Specifically WRT write amplification. http://www.cindori.org/trim-vs-garbage-collection/

This is really off topic for kasbert’s list, so I would rather discuss it elsewhere, but my source for that statement was an interview with OWC founder and CEO Larry O’Connor where he responded to the question:

Q: Did third-party SSD makers get any warning of this change?

With one exception, no third-party SSD maker promoted use of/included a TRIM enabler hack for their drives.

See http://www.zdnet.com/article/os-x-yosemite-and-third-party-ssds-heres-what-you-need-to-know/

-Al-

[macuserguru]

But SATSMARTDriver.kext 0.10 or newer are not whitelisted :-(

[alvarnell]

On Fri, Jan 02, 2015 at 01:25 AM, macuserguru wrote:

But SATSMARTDriver.kext 0.10 or newer are not whitelisted :-(

Which takes us back to November 10 when that was pointed out to start this discussion. Most users don’t need 0.10, so why is this important to you?

Edit: Never mind, I found your #29 discussion.

-Al-

Al Varnell Mountain View, CA

[macuserguru]

0.10 is not important for me - #0.8 works well under 10.10.1 and my used external USB and FW devices. As far as I know, some new devices are not listed in Info_driver.plist

For #0.8 Info_driver.plist 5.491 Byte for #0.10 Info_driver.plist 38.000 Byte