Tout d’abord bonne année à tous et meilleurs vœux pour 2018 !

Cette année démarre sur les chapeaux de roues pour tous les ouvriers de l’IT que nous sommes avec l’annonce officielle faite le 3 janvier dernier de deux failles principales découvertes au cœur de l’architecture des processeurs, les dénommées  Meltdown et Spectre. Les deux failles bien que dévoilant des vulnérabilités distinctes reposent toutes les deux sur le principe d’exécution spéculative implémentée dans les processeurs Intel depuis des lustres (l’équipe de Google Project Zero mentionne des CPU datant de 1995…).

Le principe est que derrière un branchement conditionnel (if …) , le processeur va commencer à exécuter certaines instructions par anticipation en utilisant un algorithme prédictif. Si la condition est invalide (branch mispredict), alors les registres affectés par ces exécutions anticipées seront invalidés et le flot d’exécution est raccroché à la condition valide. Toutefois des traces sont laissées au niveau des caches ce qui permet d’aller lire depuis l’espace d’adressage utilisateur (usermode) des données protégées dans l’espace réservé au noyau (kernelmode). Dans le cas de Meltdown, cela permet d’aller décoder l’ASLR, la randomisation du chargement des adresses mémoire du noyau, et de savoir à quelle adresse quel module est chargé, pour pouvoir de nouveau  générer des attaques comme c’était le cas avant la mise en place de ces mécanismes (2007 sur Windows, 2001 sur Linux).

Conséquence, des données sensibles que l’on croyait protégées et inviolables nativement de par l’architecture du processeur peuvent être dérobées.

Pour plus de détails, se reporter au document d’étude concernant chaque faille (Meltdown, Spectre), ainsi qu’au travail préliminaire fourni par Anders Fogh en juillet 2017 et qui avait conduit les différents acteurs (Project Zero, Université de Graz et Cyberus) à remonter le problème aux principaux intéressés Intel, AMD, etc…

Des patches pour Meltdown seulement ont commencé à être déployés d’abord sur Linux, puis Windows, et on a commencé à voir passer des interruptions de service pour passage de ces patches notamment sur les plateformes cloud AMAZON et Microsoft pour la partie IaaS pas plus tard qu’hier dans la journée.

La seule info technique sur la solution de contournement vient de l’adoption du patch dit KAISER proposé par le groupe de travail sur Meltdown, dans la distro Linux mainstream le 29 décembre dernier. La solution est d’implémenter le Kernel Page Table Isolation ou KPTI afin de retirer la visibilité de l’espace d’adressage noyau depuis le user mode. Cette solution s’applique à Meltdown uniquement.

Maintenant la question c’est quelles sont les conséquences d’un tel bouleversement pour les bases de données car il y a déjà quelques retours sur l’impact en termes de performance notamment ici et là.

SQL Server

Microsoft a donc fourni une note spécifique pour SQL Server en précisant le type de scénario (bare metal, machine virtuelle, cloud, linux) le degré d’exposition et les préconisations. Les versions étant concernées par les patches sont les versions à partir de SQL Server 2008 jusqu’à la SQL Server 2017, versions Itanium non comprises. Les plus anciennes ne seront pas corrigées, ce qui devrait inciter les retardataires à migrer si ce n’est pas déjà fait. La bonne nouvelle c’est qu’une grosse partie des fonctionnalités Enterprise de SQL Server 2016 est également disponible en édition standard, ce serait dommage de ne pas profiter de l’occasion.

4 patches de sécurité sur SQL Server sont disponibles pour l’instant pour les versions 2016 et 2017, en GDR et dans le dernier CU à chaque fois, on ne sait pas ce qu’ils contiennent ni ce qu’ils font.

Egalement une liste des fonctionnalités ‘à risque’ est mentionnée principalement tout ce qui concerne de l’exécution de code externe comme CLR, procédures stockées étendues, R/Python, et l’utilisation de serveurs liés hors du périmètre de confiance.  Mais globalement si SQL Server est exécuté en bare metal dans un environnement ‘de confiance’ c’est à dire que tous les composants périphériques sont connus et validés du point de vue sécurité, il n’y a pas de raison de patcher dans l’immédiat.

A savoir qu’une note similaire pour Windows Server est également disponible. On n’a pas pour l’instant de retour sur l’impact de SQL Server 2017 sur Linux avec KTPI activé.

Update ! 11 janvier 2018

Oracle

Pour l’instant pas de nouvelle de l’implémentation de KPTI sur OEL 6 et 7, alors que chez Red Hat on a déjà commencé à travailler sur le sujet. Pas vu pour l’instant de communiqué d’Oracle sur Meltdown, qui est le risque le plus immédiat. Pas de benchmark donc disponible, mais il est à prévoir qu’il y aura un impact sur la partie OS, RDBMS et même cloud puisque Oracle VM s’appuie sur Xen qui est dans le scope.

Update ! 11 janvier 2018

Thierry dans les commentaires nous indique qu’Oracle a publié des correctifs pour OEL 6 et 7:

https://linux.oracle.com/errata/ELSA-2018-0007.html
https://linux.oracle.com/errata/ELSA-2018-0008.html

MySQL:

Percona a commencé à communiquer  sur le sujet pour l’instant même chose pas de benchmark disponible:

“At this time, Percona does not have conclusive results on how much performance impact you might expect on your databases. We’re working on getting some benchmarks results published shortly.”

Pas de comm chez MariaDB sur le sujet pour l’instant On rappelle que les principaux intéressés sont d’une part Intel et dans une moindre mesure AMD, puis les éditeurs d’operating system. Les éditeurs de base de données sont eux en bout de chaîne et hormis Microsoft qui a déjà publié des correctifs pour SQL Server (dont on ignore le contenu), les autres s’en tiennent aux correctifs Linux et Windows.

Update ! 11 janvier 2018

PostgreSQL

La première alerte est venue d’Andres Freund sur la mailing list hackers en début de semaine qui a pu tester rapidement une éventuelle dégradation de perfs en TPS avec et sans l’activitation des KTPIs qui montre un -16% sur une simple requête CPU bound en local. Je vous invite vivement à lire le contenu de ce post et vous abonner à la suite. Robert Haas a déjà commencé à répondre et il y a fort à parier que le fil de discussion s’enrichisse au fil des jours.

Update ! 11 janvier 2018

Conclusion:

Pour l’instant beaucoup de spéculations  sur les impacts en termes de performance de ces nouveaux patches sur les bases de données, et pas beaucoup de faits, mais soyons sûr que ça va arriver dans le mois de janvier. Sur Linux, la solution de séparer les pages tables entre usermode et kernelmode va certainement rajouter des cycles à chaque interruption, appel système, etc… Sur Windows on ne sait pas encore quelles modifications ont été faites pour protéger la randomisation des adresses mémoire du noyau (ASLR), on peut supposer que ce sera du même acabit que sur Linux, à savoir masquer les entrées depuis le usermode.

Ce qui est certain c’est que l’on va voir débouler tout un tas d’opérations de patch de securité chez tous les hébergeurs , certaines ayant commencé déjà sur AWS et potentiellement Azure.

Stay tuned

~David

Continuez votre lecture sur le blog :

• Meltdown sur OLE 7 et performances (Capdata team) [Oracle]
• Identifier une requête consommatrice via le palmarès SQL Server AllDB (David Baffaleuf) [SQL Server]
• Quelles solutions de chiffrement de données pour MySQL / MariaDB (David Baffaleuf) [MySQL]
• Installation Oracle 64 bits sur Red Hat 5 (Capdata team) [OracleVintage]
• Le chiffrement et SQL Server – Episode 1 : Transparent Data Encryption (TDE) vs Always Encrypted (Capdata team) [SQL Server]