Alors déplorer aujourd'hui que « ça n'est pas possible, ma bonne dame », c'est oublier qu'on a troqué des choses qui existaient et qui marchaient très bien
Je ne suis pas vraiment d'accord. Certes on peut (et c'est toujours vrai aujourd'hui) se préparer un système aux petits oignons en compilant tout manuellement. Mais très peu de gens ont les compétences pour créer et maintenir un tel système.
Désactiver un jeu d'instruction à la compilation, voire dans certains cas dès la phase de configuration, c'est déjà loin d'être évident sur des processeurs modernes. En plus on se retrouve avec un système unique, sur lequel si des bugs spécifiques apparaissent, il faut les gérer seul ou quasiment.
Là il s'agit (si on veut être prudent) de désactiver complètement les fonctionnalités RTM et HLE (et tout ce qui touche à l'hyperthreading, mais ça ça se fait bien). Non seulement il va y avoir un impact vraiment fort sur les perfs qui n'est pas forcément acceptable professionnellement, mais en plus il faut adapter tes fichiers de config et de compilation pour ainsi dire type de machine par type de machine.
A titre d'exemple mon ingesteur de données custom 0MQ+ScyllaDB se prenait 70% de pertes de perfs jusqu'à l'arrivée de retpoline au moment de SPECTRE/MELTDOWN. Pas évident de devoir choisir entre tourner à 30% de perfs ou tripler la facture d'hébergement.
Je ne vois pas comment on peut écarter un tel bon système en disant qu'il n'existe pas d'alternative au tout « j'exécute n'importe quel binaire » d'aujourd'hui.
Ça n'est absolument pas la question, certes Debian a des paquets binaires que l'on peut auditer, mais si tu dois compiler quoi que ce soit à la mimine, si tu veux un kernel optimisé ou si tu as besoin du moindre pilote (même libre) qui effectue une étape de compilation au déploiement du package - tu rentres dans le rouge immédiatement.
En fait même si tu ne prends que des packages standards libres Debian, tu vas probablement te retrouver dans le rouge quand même. Déjà pas mal de packages, modules et pilotes sont compilés avec la capacité de détecter et d'activer au runtime des optimisations CPU (crypto, NUMA, HLE etc.), ensuite tu fais quoi si tu as un environnement qui utilise ces instructions ? Tu recompile et tu redéploies tout ? (Dans le cas de retpoline, c'est ce qui s'est passé...)
Généralement si tu bosses dans tout un tas de domaines tu vas chercher à exploiter au maximum ton infrastructure, donc laisser le compilateur optimiser pour toi en mettant un -march qui correspond à ton architecture. Aller choisir les flags à la main un par un est complexe, surtout que les gars chez GCC ne s'attendent absolument pas à avoir un processeur qui possède le flag X mais pas le flag Y - vu qu'il existe exactement 0 processeur réel dans cette situation.
Donc tu te retrouves à essuyer les plâtres sur des configs de compilation qui n'ont aucun sens. Ou tu désactives les fonctions au niveau kernel (ou microcode) et tu regardes ce qui casse. Et clairement c'est pas un job que n'importe qui peut faire, et comme la majorité des boites n'a pas d'Ulrich Drepper sous la main...
Bref utiliser Debian avec des packages traçables n'évite absolument pas le problème. Ça mitige un peu dans le sens ou effectivement tu n’exécutes pas un code tiers qui a une intention malicieuse à la base - mais pour autant ça ne bloque pas une attaque via des logiciels établis.
[^] # Re: « Vulnérabilité » pour des cas d'utilisation spécifiques
Posté par Kaane . En réponse au journal Nouvelle vulnérabilité pour les processeurs Intel : l’attaque CacheOut. Évalué à 4.
Je ne suis pas vraiment d'accord. Certes on peut (et c'est toujours vrai aujourd'hui) se préparer un système aux petits oignons en compilant tout manuellement. Mais très peu de gens ont les compétences pour créer et maintenir un tel système.
Désactiver un jeu d'instruction à la compilation, voire dans certains cas dès la phase de configuration, c'est déjà loin d'être évident sur des processeurs modernes. En plus on se retrouve avec un système unique, sur lequel si des bugs spécifiques apparaissent, il faut les gérer seul ou quasiment.
Là il s'agit (si on veut être prudent) de désactiver complètement les fonctionnalités RTM et HLE (et tout ce qui touche à l'hyperthreading, mais ça ça se fait bien). Non seulement il va y avoir un impact vraiment fort sur les perfs qui n'est pas forcément acceptable professionnellement, mais en plus il faut adapter tes fichiers de config et de compilation pour ainsi dire type de machine par type de machine.
A titre d'exemple mon ingesteur de données custom 0MQ+ScyllaDB se prenait 70% de pertes de perfs jusqu'à l'arrivée de retpoline au moment de SPECTRE/MELTDOWN. Pas évident de devoir choisir entre tourner à 30% de perfs ou tripler la facture d'hébergement.
Ça n'est absolument pas la question, certes Debian a des paquets binaires que l'on peut auditer, mais si tu dois compiler quoi que ce soit à la mimine, si tu veux un kernel optimisé ou si tu as besoin du moindre pilote (même libre) qui effectue une étape de compilation au déploiement du package - tu rentres dans le rouge immédiatement.
En fait même si tu ne prends que des packages standards libres Debian, tu vas probablement te retrouver dans le rouge quand même. Déjà pas mal de packages, modules et pilotes sont compilés avec la capacité de détecter et d'activer au runtime des optimisations CPU (crypto, NUMA, HLE etc.), ensuite tu fais quoi si tu as un environnement qui utilise ces instructions ? Tu recompile et tu redéploies tout ? (Dans le cas de retpoline, c'est ce qui s'est passé...)
Généralement si tu bosses dans tout un tas de domaines tu vas chercher à exploiter au maximum ton infrastructure, donc laisser le compilateur optimiser pour toi en mettant un -march qui correspond à ton architecture. Aller choisir les flags à la main un par un est complexe, surtout que les gars chez GCC ne s'attendent absolument pas à avoir un processeur qui possède le flag X mais pas le flag Y - vu qu'il existe exactement 0 processeur réel dans cette situation.
Donc tu te retrouves à essuyer les plâtres sur des configs de compilation qui n'ont aucun sens. Ou tu désactives les fonctions au niveau kernel (ou microcode) et tu regardes ce qui casse. Et clairement c'est pas un job que n'importe qui peut faire, et comme la majorité des boites n'a pas d'Ulrich Drepper sous la main...
Bref utiliser Debian avec des packages traçables n'évite absolument pas le problème. Ça mitige un peu dans le sens ou effectivement tu n’exécutes pas un code tiers qui a une intention malicieuse à la base - mais pour autant ça ne bloque pas une attaque via des logiciels établis.