Slashdot Mirror
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.
Apple has never enabled TRIM on non-OEM SSDs, which is probably the conservative and correct thing to do. If you're clever enough to install a new SSD, you're clever enough to enable it on your own (and presumably to know whether you should enable it, and whether it's even a benefit for your particular drive).
The current workaround involved a single software vendor who didn't sign their kexts. Apple's new security policy won't let you load random unsigned kernel modules unless you explicitly turn off the signature checking. While this is inconvenient for me personally - because I have a 3rd-party SSD and I used that software myself - on whole, I'd rather have a more secure OS than the dubious benefit of a possibly slightly faster SSD.
Dewey, what part of this looks like authorities should be involved?
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).
Because you cannot simply add your own key, but you have to disable all driver signing in order to use one non-approved driver?
Yes. See every argument ever about UEFI secure boot on PCs intended to run Windows 8.
In my experience, mac laptops cost 20% more and last twice as long as alternative PC laptop manufacturers. That doesn't seem like a bad deal to me.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
That is an interesting point, however I have owned 5 Mac laptops over the years. A G3 PowerBook, A G4, PowerBook, 2 Core Duos and 1 Core 2 Duo. I have owned about the same number of PC laptops. I have not seen any improvement in reliability over the macs except in the case of ultra cheap netbooks that Apple doesn't directly compete with anyway. Neither of our points matter much as they are totally anecdotal. Also, the 20% figure you list is arbitrary and varies over the years. The point I was trying to make you ignore. Why pay more for Apple to preinstall an SSD for you when you can buy the SAME BRAND if not identical model number they use and install it for usually HALF the cost or less than what they charge for the upgrade? Answer THAT. That is what the article is about after all.
Also - couldn't you actually just sign the drivers that are needed for trim? What prevents that?
As the author of the popular "trim enabler" software (which patches the original apple drivers and so causes the original drivers to fail the kext signing check) puts it:
"all of Apple’s AHCI SATA drivers are closed source and undocumented, which makes it impossible for me to create my own Trim driver and get it signed."
Which is also the reason why there are no trim drivers available from hardware manufacturers like Samsung, etc. No access to Apple's driver documentation - no signed trim drivers.
There are three approaches to computing.
There's the commercial-ubiquitous approach. This is Microsoft's approach. Try to support (or to get manufacturers to support) as much hardware as possible. Be the default solution. Things generally look good (I can't fault Microsoft over their years for most of their UI decisions), stability may not always be terribly good though, and that's the sacrifice, ubiquity over stability, but the gain is to run on just about all hardware in existence. Android is also mostly falling into this category too now.
There's the commercial-restricted approach. Sell your hardware and your software, and only allow a select-few others to sell hardware or software that is compatible with your products. The upside is that the platforms are highly stable, but the downsides are that users will sometimes find they simply can't do something because it's disallowed. It also requires the company to be ever-vigilant about pushing more features and capabilities, as stagnation will mean death. Apple currently leads this community, but SGI, Sun, NeXT, Commodore, and a whole bunch of computer companies throughout the years have tried it and ultimately closed up shop.
The Open-Source method is the third approach, and it's both leading edge (ie, research projects by major universities) and completely behind (many user applications simply don't exist or are only partially functional).
I use Windows, OSX, and Linux daily as desktop environments. Linux is stable and fast, but often not compatible with developments out of Redmond and with a lot of work to make some features function. OSX is very smooth, very stable, and awkwardly locked-down to where some things simply aren't options. Windows is compatible with just about everything and requires weekly reboots to keep it running.
They all suck. All of them.
Do not look into laser with remaining eye.
Turn off the driver signing requirement in Yosemite, problem solved, your hack still works and you're in the same condition you were in Mavericks.
They didn't 'block trim' they blocked your hack to make the driver do something it wasn't intended to do.
The only thing needed for your random SSD to have trim support in OS X is for the manufacture to release a driver for their drives, with trim support ... and considering the Apple driver for AHCI isn't exactly hard to find the source for, its not even much more than compile and distribute.
We could debate why Apple doesn't support trim outside of their own drives, but its hard to argue that its their fault for not supplying a driver for your third party hardware.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Yes... the demented world of Apple where daring to buy a 3rd party peripheral is only for "power users" or "cheapskates" or some other class of person that will be denigrated by the hive mind.
THIS here is the biggest reason to avoid Apple products. Not the price. Not the novelty form factors that cook your machine. Not the fact that nothing is maintainable.
It's THIS attitude here that anyone that's using this "platform for creatives" in a remotely creative way will get shouted down by the hive mind.
A Pirate and a Puritan look the same on a balance sheet.
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.
Check out my sci-fi/humor trilogy at PatriotsBooks.