Fin d'un cauchemar : une Apple kext rétro-compatible prend en charge le Trim sur les SSD tiers

[Membre supprimé 1060554]

Un récent article de MacGénération a signalé la bonne nouvelle : ☞OS X El Capitan prend en charge le TRIM sur les SSD tiers☜.

Pour resituer le contexte : jusqu'à ce jour, une extension du noyau Apple : la IOAHCIFamily.kext prenait en charge le Trim uniquement sur les SSD monté d'usine par Apple, à l'exclusion des SSD tiers installés par l'utilisateur en remplacement d'un HDD sur des Macs déjà relativement anciens. Afin de pallier cette carence, un logiciel comme «Trim Enabler» réussissait à étendre la prise en charge du Trim par la kext Apple sur les SSD tiers après patch de quelques octets.

Mais la mise en place, sous «Yosemite 10.10», d'une mesure de sécurité au démarrage : le kext_signing (vérification de l'intégrité des extensions du noyau Apple) induisait un blocage du démarrage lors de la vérification de la IOAHCIFamily.kext patchée par le kernel avec affichage à l'écran du sigle d'interdiction de stationner. Afin d'esquiver cette menace, le développeur de «Trim Enabler» (Oskar Groth) introduisit dans son programme l'instruction de désactiver le kext_signing sous «Yosemite» : comme ledit kext_signing est une instruction stockée dans la mémoire statique de la Carte-Mère : NVRAM visitée par l'EFI au démarrage et dont les arguments sont passés via le boot_loader : boot.efi au kernel - la mesure consistait à substituer à l'argument de boot par défaut le boot-args=kext-dev-mode=1 autorisant des développeurs à tester sous «Yosemite» des extensions expérimentales sans courir le risque d'un plantage au boot.

Ce patch de la NVRAM garantissant la prise en charge par le kernel de la IOAHCIFamily.kext patchée réclamait de surcroît une mise-à-jour verrouillant le cache de démarrage du Système : le kernelcache, de manière à ce qu'il y ait chargement "en bloc" du paquet des extensions au lieu de prise en charge discrète une à une avec vérification de chacune. Par suite, la solution mise-en-place proscrivait 2 classiques du démarrage avec option : le reset_NVRAM (qui, en faisant sauter le privilège "developer", réactivait le kext_signing et donc vouait le Mac au plantage lors du test de la IOAHCIFamily.kext patchée) et le démarrage "Sans extensions", car ce dernier vidant les caches-Système, supprimait notamment le kernelcache et induisait un démarrage avec chargement discret des kexts une à une qui rendait réopérante la procédure du kext_signing et donc le plantage arrivé à la IOAHCIFamily.kext patchée.

Non seulement l'utilisateur se trouvait restreint dans ses possibilités de démarrage manuels avec option (parfois bien utiles), mais devait rester vigilant dans l'utilisation de logiciels de nettoyage proposant un vidage des caches-Système, quand il ne s'exposait pas à l'installation d'applications impliquant en catimini une manipulation de la NVRAM...

☞ dans ce contexte que je viens brièvement de rebrosser, où l'utilisateur de «Yosemite» qui avait activé le Trim sur un SSD tiers avait l'Épée de Damoclès du plantage suspendue en permanence au-dessus de la tête, l'annonce de la prise en charge du Trim sur les SSD tiers dans «El Capitan» apparaît donc bien comme la fin d'un cauchemar.

--------------------
​

Mais, comme on pouvait s'y attendre, cette mesure de libéralisation prise par Apple ne fait pas les affaires des promoteurs d'un logiciel comme «Trim Enabler» qui se trouve de ce fait frappé d'obsolescence. Rien d'étonnant, par suite, si le désir naturel de "persévérer dans leur être" (comme dit Spinoza) ne les conduise à émettre beaucoup plus de fumée que de lumière sur le nouvel état de la question, dans le but de garder à ce programme une apparence d'utilité.

Quels sont, sous «El Capitan», les ressorts de la prise en charge du Trim sur les SSD tiers ? 2 outils introduits par Apple simultanément : 1° une nouvelle extension spécifiquement dédiée à la prise en charge du Trim sur SSD tiers : la AppleDataSetManagement.kext qui, pour être activée, doit être localisée dans le répertoire-Système : /System/Library/Filesystems (et pas dans le répertoire : /System/Library/Extensions) ; 2° un nouveau programme binaire UNIX dédié à la gestion de la AppleDataSetManagement.kext --> le trimforce, installé nativement at: /usr/bin/trimforce.

Le nouveau binaire trimforce peut être invoqué selon 2 commandes basiques inverses (réclamant le privilège sudo) : sudo trimforce enable (qui active la AppleDataSetManagement.kext en mode interactif en impliquant de répondre y=yes à 2 demandes d'autorisation successives dans le «Terminal») et sudo trimforce disable (qui désactive la même kext) selon le même type de mode interactif à 2 échelons. Dans les 2 cas de figure, le programme trimforce a pour adresse automatique de sa cible (la AppleDataSetManagement.kext) le répertoire-Système : /System/Library/Filesystems où il doit pouvoir la trouver.

D'après mes expérimentations, il est bien évident que la désactivation du kext-signing n'est plus requise a priori, puisqu'il s'agit d'une Apple_kext native et non d'une Apple_kext patchée. Mais (sous «El Capitan»), il est requis au préalable, en se logeant pour ce faire dans la «Recovery HD 10.11», d'activer le nouvel utilitaire : Security Configuration (Configuration de Sécurité) pour désactiver l'option activée par défaut : Enforce System Integrity Protection sans quoi la commande sudo trimforce enable à partir de l'OS, quand bien même l'utilisateur passe-t-il en privilège root, n'est pas honorée. L'option Enforce System Integrity Protection une fois désactivée, le binaire trimforce se laisse très bien invoquer dans le «Terminal» en droit root et, après re-démarrage, l'Apple_kext native : AppleDataSetManagement.kext se trouve bien effectivement activée et prend en charge le Trim (il n'y a plus qu'à réactiver après coup, depuis la «Recovery HD», l'option Enforce System Integrity Protection de l'utilitaire : Security Configuration --> le nouveau protocole de sécurité est restauré - empêchant notamment des applications de manipuler la NVRAM - sans que l'opération antérieure d'activation de la kext : AppleDataSetManagement.kext ne soit résiliée).

La nouvelle kext Apple_native : AppleDataSetManagement.kext et le nouveau programme binaire : trimforce, d'après mes expérimentations, se laissent copier sans aucun problème, à partir de leur source (l'OS bêta «El Capitan») dans les OS antérieurs : «Yosemite 10.10», «Mavericks 10.9» & «Mountain Lion 10.8» aux emplacements requis : respectivement --> /System/Library/Filesystems/AppleDataSetManagement.kext & /usr/bin/trimforce ; et, après restauration des propriétaires sur le paquet de la kext et le fichier du binaire (par une double commande dans le «Terminal» : sudo chown -R 0:0 /System/Library/Filesystems/AppleDataSetManagement.kext & sudo chown 0:0 /usr/bin/trimforce), il est possible, d'une session admin de chacun de ces OS démarré (10.8, 10.9, 10.10, 10.11) de passer dans le «Terminal» la commande : sudo trimforce enable qui produit dans tous les cas de figure l'activation native du Trim sur un SSD tiers que l'utilisateur aurait installé en interne (à la place d'un HDD et/ou d'un Super-Drive) ou attaché en externe (par exemple en connexion Thunderbolt).

Cette compatiblité rétro-active est, d'après mes expérimentions, honorée pour tous les OS jusqu'à «Mountain Lion 10.8» compris. Dans l'OS «Lion 10.7», par contre, la commande trimforce à destination de la kext : AppleDataSetManagement.kext demeure sans effets.

--------------------
​

Pour les amateurs d'expérimentation, je mets grâcieusement à disposition pour téléchargement depuis le dossier public de ma «DropBox» le dossier : ☞APPLE-TRIM.zip☜ recelant les 2 outils extraits de l'OS «El Capitan-bêta» : la kext Apple_native rétro-compatible --> AppleDataSetManagement.kext et le programme binaire UNIX rétro-compatible --> trimforce.

Une fois le dossier dé-zippé, le plus simple, dans une session admin, est de déplacer a la mano la kext : AppleDataSetManagement.kext à l'adresse suivante : /Système/Bibliothèque/Filesystems (authentification par mot-de-passe admin requise) ; et pour le fichier trimforce, de passer par la fonctionnalité du Finder "Aller au dossier.." en pressant la combinaison de touches : ⌘⇧G (cmd maj G) et, dans la fenêtre de saisie qui s'affiche, de renseigner l'adresse : /usr/bin et presser le bouton : Aller --> le répertoire /usr/bin s'ouvre dans une fenêtre où il n'y a plus qu'à faire glisser le binaire : trimforce (authentification par mot-de-passe admin requise encore).

Cela fait, aller à : Applications/Utilitaires et lancer le «Terminal». Copier-coller en premier la commande :

sudo chown -R 0:0 /System/Library/Filesystems/AppleDataSetManagement.kext

et ↩︎ (presser la touche "Entrée" du clavier pour activer la commande) --> une demande de password s'affiche (commande sudo) --> taper le mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎ --> les propriétaires du répertoire de la kext sont rétablis récursivement à user=root et group=wheel comme requis). Copier-coller ensuite la commande :

sudo chown 0:0 /usr/bin/trimforce

et ↩︎ (pas besoin de ré-authentification dans les 5' après une 1ère commande sudo) --> les propriétaires du fichier binaire sont rétablis récursivement à user=root et group=wheel comme requis.

Cela fait, au cas où le Trim serait activé via «Trim Enabler», relancer ce programme et choisir dans sa fenêtre de "Désactiver le Trim" --> le programme va requérir un re-démarrage avant lequel, en fermeture de session, il va restaurer à son intégrité l'Apple_kext patchée : IOAHCIFamily.kext, mettre à jour le cache-Système kernelcache et résilier en NVRAM l'argument de boot "developer". Ce re-démarrage (d'une pierre 2 coups) va permettre au kernel de charger (sous l'OS rétro-compatible concerné : 10.10, 10.9, 10.8) la kext Apple_native AppleDataSetManagement.kext fraîchement importée dans le répertoire /System/Libary/Filesystems.

Sur ces nouvelles bases, après le re-démarrage et la session ré-ouverte, relancer le «Terminal» et passer la commande :

sudo trimforce enable

et ↩︎ --> password à l'aveugle et ↩︎ --> un menu interactif s'affiche :

This tool force-enables TRIM for all relevant attached devices, even though
they have not been validated for data integrity while using that functionality.
By using this tool to enable TRIM, you agree that Apple is not liable for any
consequences that may result, including but not limited to data loss
or corruption.
Are you sure you wish to proceed (y/N)?

--> presser la touche y et ↩︎ afin d'agréer --> un nouveau menu ineractif s'affiche :

Your system will immediately reboot when this is complete.
Is this OK (y/N)?

--> presser la touche y de nouveau et ↩︎ pour agréer --> le programme trimforce va activer la kext : AppleDataSetManagement.kext et le Mac va re-démarrer avec prise en charge par le kernel de l'extension active --> le Trim est désormais pris en charge par la néo-extension Apple (rétro-compatible) sans recours désormais à «Trim Enabler» qui est désactivé.

☞ Désormais, il n'y a plus (sous «Yosemite» du moins) d'Épée de Damoclès suspendue à un long et mince crin de cheval sur la tête de l'utilisateur

Afin d'étrenner ma confiance neuve, j'ai successivement démarré mon Mac (OS : «Yosemite 10.10.3») avec l'option : touche ⇧ pressée (démarrage "sans extensions" vidant notamment le cache-Système kernelcache) puis avec l'option ⌘⌥PR (démarrage réinitialisant la NVRAM avec remise au défaut des arguements de boot) --> dans les 2 cas, le chargement de l'OS s'est effectué sans problème aucun jusqu'à l'ouverture de session....

 

[Ibiscus]

Un petit Up et un grand merci pour cette bonne nouvelle.

 

[Ma Dalton]

Cette compatiblité rétro-active est, d'après mes expérimentions, honorée pour tous les OS jusqu'à «Mountain Lion 10.8» compris.

Bonjour macomaniac,

merci pour la mise à disposition des fichiers, dont j'ai profité.

J'ai fait la manip complète sur un MBP 13" early 2011 10.9.5, SSD Crucial M500, tout se passe normalement et se termine bien par :

Your system will immediately reboot when this is complete.
Is this OK (y/N)?

Mais, après reboot, Informations système indique toujours : "Prise en charge de TRIM : NON"

Je souhaitais savoir si c'est "normal", ou non.

D'autre part je ne comprends pas pourquoi il faut placer le .kext dans /System/Library/Filesystems, et non pas dans /System/Library/Extensions.
Github (mais pour Yosemite) parle bien de /Extensions.

D'avance merci.

 

[Membre supprimé 1060554]

Salut Ma.

J'ai péché par « enthousiasme dominical » (mea culpa) lorsque je me suis avancé à proclamer la rétro-compatibilité de l'extension Apple : AppleDataSetManagement.kext à toute une série d'OS antérieurs à «El Capitan 10.11». Comme tu l'as constaté avec ton «Mavericks 10.9.5» et comme je l'ai vérifié ultérieurement en re-bootant systématiquement sur les OS qui vont de «Lion 10.7» à «El Capitan 10.11» pour y opérer la manip, re-démarrer et vérifier dans les Infos_Système si le Trim était bien pris en charge --> seul, parmi les OS précédant «El Capitan», «Yosemite 10.10» supporte la prise en charge de l'extension : AppleDataSetManagement.kext. Je pense que c'est une question de version du kernel : la série des mach_kernel (de «Lion» à «Mavericks») n'a pas l'air de charger l'extension, alors que le nouveau kernel de «Yosemite» la prend bien en charge.

Je pense donc que, pour tous les OS antérieurs à «Yosemite», le recours à «Trim Enabler» s'impose (la carrière de ce logiciel a des chances de s'arrêter avec ces OS). Ça tombe bien : comme aucun des OS avant «Yosemite» n'embarque l'instruction de boot du kext_signing, ils ne font pas la plus petite difficulté à charger une extension patchée par le logiciel. Donc tous les démarrages optionnels classiques sont sûrs : Safe Mode ou reset_NVRAM.

Pour «Yosemite», par contre, ça marche impeccablement : j'ai désactivé «Trim Enabler» et le Trim est désormais pris en charge pour mon SSD de tierce-partie Crucial par la nouvelle extension Apple. Aucun problème. Je crois que l'avertissement menaçant qui s'affiche dans la fenêtre du «Terminal» lorsqu'on met en place l'extension par la commande trimforce - du style : si vous paumez vos données, n'allez pas vous plaindre à Apple - concerne les SSD tiers "anciens" ou "exotiques". Quelqu'un qui a un SSD d'une bonne marque et ne datant pas de la XXVè dynastie n'a sans doute guère de mouron à se faire.

Ta question finale équivaut à se demander : en quoi consiste le programme /bin/trimforce invocable par le commande du même nom dans le «Terminal» avec l'option : enable ? Tout bien pesé, dans un script rigolo qui opère 3 sous-commandes (à passer en mode root) :

cp -R /System/Library/Filesystems/AppleDataSetManagement.kext /System/Library/Extensions/AppleDataSetManagement.kext
touch /System/Library/Extensions
kextcache -u /

où, comme tu le lis clairement, la première commande opère tout bonnement une recopie du répertoire original de la kext (recelé dans le dossier-Système : Filesystems) au dossier de destination des Extensions où il doit être localisé pour faire partie des ressources d'extensions chargeables. La 2è restaure le timestamp sur le dossier des Extensions qui a été affecté par l'opération de copie précédente. La 3è reconstruit les caches-Système et va donc solidariser dans le cache de démarrage kernelcache le nouveau bloc des extensions "mises-à-jour" avec le clone du code du kernel. C'est ce cache que le boot_loader : boot.efi charge directement au démarrage.

Comme tu vois, la présence de l'extension AppleDataSetManagement.kext dans le dossier Filesystems n'a pas une fonction "active" (l'extension ne peut pas être chargée dans cette localisation), mais une fonction de "paradigme" en réserve : c'est-là l'original qui permet à la commande trimforce de trouver la source de sa recopie à destination du dossier des Extensions. Si l'AppleDataSetManagement.kext n'existe pas dans le dossier Filesystems, la commande trimforce enable ne passe pas, faute d'une source de sa copie. Inversement, la commande : trimforce disable ne diffère de la 1ère que par la commande initiale qui est :

rm -rf /System/Library/Extensions/AppleDataSetManagement.kext

--> il y a purement et simplement suppression de la kext recopiée dans les Extensions (mais préservation du paradigme dans les Filesystems pour une copie ultérieure éventuelle).

Comme expliqué par le gars dans le papier de «Github» que j'ai été lire, on peut se passer de la commande trimforce et passer les commandes en manuel (ou même 'jeter' la kext a la mano via le Finder dans le dossier des Extensions. À condition de réparer les dégâts ensuite en ligne de commande avec un chown 0:0 /System/Library/Extensions/AppleDataSetManagement.kext, puis les 2 commandes touch et kextcache).

 

[Ma Dalton]

Bonsoir,

merci pour les explications détaillées, je vais donc réactiver TrimEnabler.