Apple Disables Trim Support On 3rd Party SSDs In OS X

MojoKid (1002251) writes One of the disadvantages to buying an Apple system is that it generally means less upgrade flexibility than a system from a traditional PC OEM. Over the last few years, Apple has introduced features and adopted standards that made using third-party hardware progressively more difficult. Now, with OS X 10.10 Yosemite, the company has taken another step down the path towards total vendor lock-in and effectively disabled support for third-party SSDs. We say "effectively" because while third-party SSDs will still work, they'll no longer perform the TRIM garbage collection command. Being able to perform TRIM and clean the SSD when it's sitting idle is vital to keeping the drive at maximum performance. Without it, an SSD's real world performance will steadily degrade over time. What Apple did with OS X 10.10 is introduce KEXT (Kernel EXTension) driver signing. KEXT signing means that at boot, the OS checks to ensure that all drivers are approved and enabled by Apple. It's conceptually similar to the device driver checks that Windows performs at boot. However, with OS X, if a third-party SSD is detected, the OS will detect that a non-approved SSD is in use, and Yosemite will refuse to load the appropriate TRIM-enabled driver.

Comments

Depends on the SSD

[khb]

See http://blog.macsales.com/21641... for an example of a properly designed SSD.

kext signing is a GoodThing for security. Making the system less secure so that lazy implementors are protected isn't a good trade off.

Apple *should* have provided a better upgrade experience so that users wouldn't be surprised, or end up with unbootable systems. Users that don't want to have kext protection CAN turn it off see http://www.cindori.org/trim-en...

To me this is akin to Apple's desupport of WPS ages ago. It took everyone else a while to figure out that WPS was a major security hole (indeed, its still there for most consumers).

Re:This isn't new

[dgatwood]

The real problem here, as I see it, is that the developer of the TRIM enabler is writing bug reports that request a ridiculously complex solution that doesn't make much sense, rather than a very trivial solution that does.

The right way to solve this problem would be for Apple to add a single line of code that checks for a magic value in the device tree, and enables TRIM support if it finds it. Then, the TRIM enabler could write a codeless kext for any devices whose TRIM support seems to work, whose sole purpose is to add that magic value into the device tree, that matches at a higher priority than the Apple driver, modifies the device tree, and walks away from the table, allowing the Apple driver to attach, see the flag, and use TRIM support.

Heck, there's probably a flag like that in there already. Just looking at the device tree for my Apple-branded drive in 10.9, I see something pretty glaring:

"IOStorageFeatures" = {"Unmap"=Yes}

and thirty seconds later, found the documentation for that key here. Chances are, if you write a codeless kext that modifies the device tree to add this property to the device, and if you get your matching correct, the unmodified Apple driver will magically enable TRIM support. If so, then you just need to get a proper signing key from Apple, sign the codeless kext, and you're done. If not, file a bug asking for that approach (or a similar approach with a different key) to work.

If that approach doesn't work, then and only then should you even think about writing an actual chunk of kernel code.