Bonjour,
Les derniers Kernel semblent plus mauvais en terme de performance. Un serveur fonctionnait sur un kernel "maison" 4.14, j'ai voulu le remettre en kernel officiel Debian Buster donc 4.19, les performances se sont écroulées: hausse de la conso CPU, du load, et augmentation des temps de réponse PHP de l'ordre de +50% ! Le dernier kernel 5.3 n'apportera aucune solution.
On peut depuis le 5.2 désactiver les protections contre les failles de sécurité affectant tous les processeurs modernes (pas que Intel, mais aussi ARM, AMD et MIPS) avec le paramètre de boot mitigations=off C'est mieux, mais je ne retrouve pas les perfs du 4.14 (conso CPU et temps de réponse).
Lien vers la doc sur ces paramètres: https://linuxreviews.org/HOWTO_make_Linux_run_blazing_fast_(again)_on_Intel_...
Voilà ce que ça donne sur un serveur en production :
[image: cpu.png]
Savez vous ce qu'il faudrait faire pour retourner au niveau de perf du 4.14 ?
Merci !
Hello,
A tout hasard, est ce que tu appliques également les mises à jour du microcode Intel à la volée lors du boot, avec le paquet intel-microcode ? La différence de performances peut aussi venir de là.
-- Florian STOSSE | Ingénieur en sécurité informatique
Le mar. 17 déc. 2019 à 16:26, Greg greg-frsag@duchatelet.net a écrit :
Bonjour,
Les derniers Kernel semblent plus mauvais en terme de performance. Un serveur fonctionnait sur un kernel "maison" 4.14, j'ai voulu le remettre en kernel officiel Debian Buster donc 4.19, les performances se sont écroulées: hausse de la conso CPU, du load, et augmentation des temps de réponse PHP de l'ordre de +50% ! Le dernier kernel 5.3 n'apportera aucune solution.
On peut depuis le 5.2 désactiver les protections contre les failles de sécurité affectant tous les processeurs modernes (pas que Intel, mais aussi ARM, AMD et MIPS) avec le paramètre de boot mitigations=off C'est mieux, mais je ne retrouve pas les perfs du 4.14 (conso CPU et temps de réponse).
Lien vers la doc sur ces paramètres: https://linuxreviews.org/HOWTO_make_Linux_run_blazing_fast_(again)_on_Intel_...
Voilà ce que ça donne sur un serveur en production :
[image: cpu.png]
Savez vous ce qu'il faudrait faire pour retourner au niveau de perf du 4.14 ?
Merci !
Greg _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Oui, et en cas d'absence de ces microcodes, les protections ne peuvent fonctionner, et donc c'est comme si elles étaient désactivées.
Le mar. 17 déc. 2019 à 16:48, Florian Stosse florian.stosse@gmail.com a écrit :
Hello,
A tout hasard, est ce que tu appliques également les mises à jour du microcode Intel à la volée lors du boot, avec le paquet intel-microcode ? La différence de performances peut aussi venir de là.
-- Florian STOSSE | Ingénieur en sécurité informatique
Le mar. 17 déc. 2019 à 16:26, Greg greg-frsag@duchatelet.net a écrit :
Bonjour,
Les derniers Kernel semblent plus mauvais en terme de performance. Un serveur fonctionnait sur un kernel "maison" 4.14, j'ai voulu le remettre en kernel officiel Debian Buster donc 4.19, les performances se sont écroulées: hausse de la conso CPU, du load, et augmentation des temps de réponse PHP de l'ordre de +50% ! Le dernier kernel 5.3 n'apportera aucune solution.
On peut depuis le 5.2 désactiver les protections contre les failles de sécurité affectant tous les processeurs modernes (pas que Intel, mais aussi ARM, AMD et MIPS) avec le paramètre de boot mitigations=off C'est mieux, mais je ne retrouve pas les perfs du 4.14 (conso CPU et temps de réponse).
Lien vers la doc sur ces paramètres: https://linuxreviews.org/HOWTO_make_Linux_run_blazing_fast_(again)_on_Intel_...
Voilà ce que ça donne sur un serveur en production :
[image: cpu.png]
Savez vous ce qu'il faudrait faire pour retourner au niveau de perf du 4.14 ?
Merci !
Greg _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Ce n'est pas aussi simple, les benchmarks fait par Phoronix sur le sujet montrent bien que mettre à jour le microcode seulement, même en désactivant les remédiations, à un impact sur les performances.
En tous cas j'essaierai de garder une vieille version du microcode si ton but est de retrouver les performances initiales.
Le mar. 17 déc. 2019 à 17:51, Greg greg-frsag@duchatelet.net a écrit :
Oui, et en cas d'absence de ces microcodes, les protections ne peuvent fonctionner, et donc c'est comme si elles étaient désactivées.
Le mar. 17 déc. 2019 à 16:48, Florian Stosse florian.stosse@gmail.com a écrit :
Hello,
A tout hasard, est ce que tu appliques également les mises à jour du microcode Intel à la volée lors du boot, avec le paquet intel-microcode ? La différence de performances peut aussi venir de là.
-- Florian STOSSE | Ingénieur en sécurité informatique
Le mar. 17 déc. 2019 à 16:26, Greg greg-frsag@duchatelet.net a écrit :
Bonjour,
Les derniers Kernel semblent plus mauvais en terme de performance. Un serveur fonctionnait sur un kernel "maison" 4.14, j'ai voulu le remettre en kernel officiel Debian Buster donc 4.19, les performances se sont écroulées: hausse de la conso CPU, du load, et augmentation des temps de réponse PHP de l'ordre de +50% ! Le dernier kernel 5.3 n'apportera aucune solution.
On peut depuis le 5.2 désactiver les protections contre les failles de sécurité affectant tous les processeurs modernes (pas que Intel, mais aussi ARM, AMD et MIPS) avec le paramètre de boot mitigations=off C'est mieux, mais je ne retrouve pas les perfs du 4.14 (conso CPU et temps de réponse).
Lien vers la doc sur ces paramètres: https://linuxreviews.org/HOWTO_make_Linux_run_blazing_fast_(again)_on_Intel_...
Voilà ce que ça donne sur un serveur en production :
[image: cpu.png]
Savez vous ce qu'il faudrait faire pour retourner au niveau de perf du 4.14 ?
Merci !
Greg _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Greg _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le mardi 17 décembre 2019 18:10:19 CET, vous avez écrit :
Ce n'est pas aussi simple, les benchmarks fait par Phoronix sur le sujet montrent bien que mettre à jour le microcode seulement, même en désactivant les remédiations, à un impact sur les performances.
Les benchmarks de phoronix, c'est vraiment a titre indicatif, faut pas prendre ca comme une référence ...
Par contre je viens de voir passer ça dans la newsletter LLVM de cette semaine (ce qui explique le déterrage de thread), ce qui pourrait expliquer au moins en partie les pertes de performance constatées :
https://www.intel.com/content/www/us/en/support/articles/000055650/processor...
Je cite : "Intel has observed performance effects associated with the workaround ranging from 0-4% on many industry-standard benchmarks. In subcomponents of these benchmarks, Intel has observed outliers higher than the 0-4% range."
Il n'y a pas que des bugs de sécurité dans les mises a jour microcode, il y a aussi des corrections de vrais bugs ...
En tous cas j'essaierai de garder une vieille version du microcode si ton but est de retrouver les performances initiales.
Le mar. 17 déc. 2019 à 17:51, Greg greg-frsag@duchatelet.net a écrit :
Oui, et en cas d'absence de ces microcodes, les protections ne peuvent fonctionner, et donc c'est comme si elles étaient désactivées.
Le mar. 17 déc. 2019 à 16:48, Florian Stosse florian.stosse@gmail.com a
écrit :
Hello,
A tout hasard, est ce que tu appliques également les mises à jour du microcode Intel à la volée lors du boot, avec le paquet intel-microcode ? La différence de performances peut aussi venir de là.
-- Florian STOSSE | Ingénieur en sécurité informatique
Le mar. 17 déc. 2019 à 16:26, Greg greg-frsag@duchatelet.net a écrit :
Bonjour,
Les derniers Kernel semblent plus mauvais en terme de performance. Un serveur fonctionnait sur un kernel "maison" 4.14, j'ai voulu le remettre en kernel officiel Debian Buster donc 4.19, les performances se sont écroulées: hausse de la conso CPU, du load, et augmentation des temps de réponse PHP de l'ordre de +50% ! Le dernier kernel 5.3 n'apportera aucune solution.
On peut depuis le 5.2 désactiver les protections contre les failles de sécurité affectant tous les processeurs modernes (pas que Intel, mais aussi ARM, AMD et MIPS) avec le paramètre de boot mitigations=off C'est mieux, mais je ne retrouve pas les perfs du 4.14 (conso CPU et temps de réponse).
Lien vers la doc sur ces paramètres: https://linuxreviews.org/HOWTO_make_Linux_run_blazing_fast_(again)_on_In tel_CPUs
Voilà ce que ça donne sur un serveur en production :
[image: cpu.png]
Savez vous ce qu'il faudrait faire pour retourner au niveau de perf du 4.14 ?
Merci !
Greg
Je confirme ce que te dit Florian, certaines mises à jour du microcode corrigent soit directement une faille, soit corrigent une faille de concert avec l'OS (principalement le kernel).
Je te conseille d'utiliser le script spectre-meltdown-checker qui fait un diagnostic de l'état du système vis à vis de chaque faille. Tu y découvriras pour chaque faille le ou les pré-requis au niveau du micro-code et/ou de l'OS: https://github.com/speed47/spectre-meltdown-checker
Cela te permettra potoentiellement de downgrader le microcode pour revenir à tes anciennes performances.
A noter, le micro-code se met à jour: - soit par flashage du BIOS - soit par chargement du microcode au boot de ta machine: - via un initrd (prise en compte en début de boot) - via un service (prise en compte plus tard dans la phase de boot)
De plus, tu as remarqué une dégradation de l'usage CPU mais l'impact principal de ces correctifs concernent tout ce qui est relatif aux appels systèmes donc principalement les I/O car à chaque appel système depuis le user-space, il faut flusher le cache du CPU ! J'ai pu remarqué des pertes de l'ordre de 30% notamment sur les accès disques en écriture aléatoire.
Ces correctifs sont vraiment vicieux car à chaque correctif, Intel nous dit que l'impact est de l'ordre de quelques pourcents mais tout les correctifs cumulés entrainent de sérieuses régréssions des performances au final.
Cordialement,
Et dire que les nouveaux processeurs doivent nous apporter plus de performances. Pour ma part, je n'ai pas vraiment mesuré l'impact des 2 failles. Avant même que leur existence ne soit dévoilée, je trouvais déjà certains CPU décevants. Ma vieille workstation Terra i7-970 avec 32 GB de RAM et un SSD compile plus vite (avec un facteur x5 de mémoire sur des batchs) par rapport A mon portable Dell Inspiron 7773 avec son i7-8850U, 16 GB de RAM et un SSD. Alors oui, c'est une génération U oui mais elle a presque 10 ans de moins, ça fait mal.
Pour les Windowsiens, j'ai trouvé 2 outils qui recherchent la faille : https://www.grc.com/inspectre.htm (très rapide) https://www.ashampoo.com/en/usd/psr/1304/security-software/spectre-meltdown-... (lui a mouliné un certains temps)
Comme j'envisage de remplacer mon vieux i7, je me pose pas mal de question pour savoir quel sera le meilleur choix pour Visual Studio 2019 (et un peu de gaming de temps en temps, on se refait pas ^^). Intel i7/i9, Intel Xeon, AMD ? Revoir le sujet des perfs de spectre et meltdown revenir me fait m'interroger sérieusement.
Vincent
-----Message d'origine----- De : FRsAG frsag-bounces@frsag.org De la part de Jean-Francois Maeyhieux Envoyé : mardi 17 décembre 2019 18:32 À : frsag@frsag.org Objet : Re: [FRsAG] Impact sur les performances des protections contre Spectre/Meltdown
Je confirme ce que te dit Florian, certaines mises à jour du microcode corrigent soit directement une faille, soit corrigent une faille de concert avec l'OS (principalement le kernel).
Je te conseille d'utiliser le script spectre-meltdown-checker qui fait un diagnostic de l'état du système vis à vis de chaque faille. Tu y découvriras pour chaque faille le ou les pré-requis au niveau du micro-code et/ou de l'OS: https://github.com/speed47/spectre-meltdown-checker
Cela te permettra potoentiellement de downgrader le microcode pour revenir à tes anciennes performances.
A noter, le micro-code se met à jour: - soit par flashage du BIOS - soit par chargement du microcode au boot de ta machine: - via un initrd (prise en compte en début de boot) - via un service (prise en compte plus tard dans la phase de boot)
De plus, tu as remarqué une dégradation de l'usage CPU mais l'impact principal de ces correctifs concernent tout ce qui est relatif aux appels systèmes donc principalement les I/O car à chaque appel système depuis le user-space, il faut flusher le cache du CPU ! J'ai pu remarqué des pertes de l'ordre de 30% notamment sur les accès disques en écriture aléatoire.
Ces correctifs sont vraiment vicieux car à chaque correctif, Intel nous dit que l'impact est de l'ordre de quelques pourcents mais tout les correctifs cumulés entrainent de sérieuses régréssions des performances au final.
Cordialement, -- -------------------------------------- Jean-François Maeyhieux Atanar Technologies http://www.atanar.com --------------------------------------
Le mardi 17 décembre 2019 à 17:50 +0100, Greg a écrit :
Oui, et en cas d'absence de ces microcodes, les protections ne peuvent fonctionner, et donc c'est comme si elles étaient désactivées.
Le mar. 17 déc. 2019 à 16:48, Florian Stosse < florian.stosse@gmail.com> a écrit :
Hello,
A tout hasard, est ce que tu appliques également les mises à jour du microcode Intel à la volée lors du boot, avec le paquet intel- microcode ? La différence de performances peut aussi venir de là.
-- Florian STOSSE | Ingénieur en sécurité informatique
Le mar. 17 déc. 2019 à 16:26, Greg greg-frsag@duchatelet.net a écrit :
Bonjour,
Les derniers Kernel semblent plus mauvais en terme de performance. Un serveur fonctionnait sur un kernel "maison" 4.14, j'ai voulu le remettre en kernel officiel Debian Buster donc 4.19, les performances se sont écroulées: hausse de la conso CPU, du load, et augmentation des temps de réponse PHP de l'ordre de +50% ! Le dernier kernel 5.3 n'apportera aucune solution.
On peut depuis le 5.2 désactiver les protections contre les failles de sécurité affectant tous les processeurs modernes (pas que Intel, mais aussi ARM, AMD et MIPS) avec le paramètre de boot mitigations=off C'est mieux, mais je ne retrouve pas les perfs du 4.14 (conso CPU et temps de réponse).
Lien vers la doc sur ces paramètres: https://linuxreviews.org/HOWTO_make_Linux_run_blazing_fast_(again)_on_Intel_...
Voilà ce que ça donne sur un serveur en production :
Savez vous ce qu'il faudrait faire pour retourner au niveau de perf du 4.14 ?
Merci !
Greg _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Salut Vincent,au vu des failles sur l'archi Intel actuelle, du prix, de la conso et des perfs pour de la productivité vs les Ryzen, AMD est clairement le choix du moment si l'usage premier est une workstation, mêmeavec du jeu occasionnel... En desktop ou HEDT. Après, qui sait si les AMD ne seront pas touchés à leur tour par des failles critiques dans le même genre. Mais ce n'est pas le cas en ce moment du moins...My 2 cents.Richard -------- Message d'origine --------De : Vincent Duvernet vincent.duvernet@nolme.com Date : 17/12/2019 21:52 (GMT+01:00) À : Jean-Francois Maeyhieux b4b1@free.fr, frsag@frsag.org Objet : Re: [FRsAG] Impact sur les performances des protections contre Spectre/Meltdown Et dire que les nouveaux processeurs doivent nous apporter plus de performances.Pour ma part, je n'ai pas vraiment mesuré l'impact des 2 failles. Avant même que leur existence ne soit dévoilée, je trouvais déjà certains CPU décevants.Ma vieille workstation Terra i7-970 avec 32 GB de RAM et un SSD compile plus vite (avec un facteur x5 de mémoire sur des batchs) par rapport A mon portable Dell Inspiron 7773 avec son i7-8850U, 16 GB de RAM et un SSD.Alors oui, c'est une génération U oui mais elle a presque 10 ans de moins, ça fait mal.Pour les Windowsiens, j'ai trouvé 2 outils qui recherchent la faille : https://www.grc.com/inspectre.htm (très rapide)https://www.ashampoo.com/en/usd/psr/1304/security-software/spectre-meltdown-... (lui a mouliné un certains temps)Comme j'envisage de remplacer mon vieux i7, je me pose pas mal de question pour savoir quel sera le meilleur choix pour Visual Studio 2019 (et un peu de gaming de temps en temps, on se refait pas ^^).Intel i7/i9, Intel Xeon, AMD ?Revoir le sujet des perfs de spectre et meltdown revenir me fait m'interroger sérieusement.Vincent-----Message d'origine-----De : FRsAG frsag-bounces@frsag.org De la part de Jean-Francois MaeyhieuxEnvoyé : mardi 17 décembre 2019 18:32À : frsag@frsag.orgObjet : Re: [FRsAG] Impact sur les performances des protections contre Spectre/MeltdownJe confirme ce que te dit Florian, certaines mises à jour du microcode corrigent soit directement une faille, soit corrigent une faille de concert avec l'OS (principalement le kernel).Je te conseille d'utiliser le script spectre-meltdown-checker qui fait un diagnostic de l'état du système vis à vis de chaque faille.Tu y découvriras pour chaque faille le ou les pré-requis au niveau du micro-code et/ou de l'OS:https://github.com/speed47/spectre-meltdown-checkerCela te permettra potoentiellement de downgrader le microcode pour revenir à tes anciennes performances.A noter, le micro-code se met à jour:- soit par flashage du BIOS- soit par chargement du microcode au boot de ta machine: - via un initrd (prise en compte en début de boot) - via un service (prise en compte plus tard dans la phase de boot)De plus, tu as remarqué une dégradation de l'usage CPU mais l'impact principal de ces correctifs concernent tout ce qui est relatif aux appels systèmes donc principalement les I/O car à chaque appel système depuis le user-space, il faut flusher le cache du CPU !J'ai pu remarqué des pertes de l'ordre de 30% notamment sur les accès disques en écriture aléatoire.Ces correctifs sont vraiment vicieux car à chaque correctif, Intel nous dit que l'impact est de l'ordre de quelques pourcents mais tout les correctifs cumulés entrainent de sérieuses régréssions des performances au final.Cordialement,---------------------------------------- Jean-François Maeyhieux Atanar Technologies http://www.atanar.com--------------------------------------Le mardi 17 décembre 2019 à 17:50 +0100, Greg a écrit :> Oui, et en cas d'absence de ces microcodes, les protections ne> peuvent fonctionner, et donc c'est comme si elles étaient> désactivées.> > Le mar. 17 déc. 2019 à 16:48, Florian Stosse <> florian.stosse@gmail.com> a écrit :> > Hello,> > > > A tout hasard, est ce que tu appliques également les mises à jour> > du microcode Intel à la volée lors du boot, avec le paquet intel-> > microcode ? La différence de performances peut aussi venir de là.> > > > --> > Florian STOSSE | Ingénieur en sécurité informatique> > > > > > Le mar. 17 déc. 2019 à 16:26, Greg greg-frsag@duchatelet.net a> > écrit :> > > Bonjour,> > > > > > Les derniers Kernel semblent plus mauvais en terme de> > > performance.> > > Un serveur fonctionnait sur un kernel "maison" 4.14, j'ai voulu> > > le remettre en kernel officiel Debian Buster donc 4.19, les> > > performances se sont écroulées: hausse de la conso CPU, du load,> > > et augmentation des temps de réponse PHP de l'ordre de +50% !> > > Le dernier kernel 5.3 n'apportera aucune solution.> > > > > > On peut depuis le 5.2 désactiver les protections contre les> > > failles de sécurité affectant tous les processeurs modernes (pas> > > que Intel, mais aussi ARM, AMD et MIPS) avec le paramètre de boot> > > mitigations=off> > > C'est mieux, mais je ne retrouve pas les perfs du 4.14 (conso CPU> > > et temps de réponse).> > > > > > Lien vers la doc sur ces paramètres: > > > https://linuxreviews.org/HOWTO_make_Linux_run_blazing_fast_(again)_on_Intel_... > > > > > Voilà ce que ça donne sur un serveur en production :> > > > > > > > > > > > > > > Savez vous ce qu'il faudrait faire pour retourner au niveau de> > > perf du 4.14 ?> > > > > > Merci !> > > -- > > > Greg> > > _______________________________________________> > > Liste de diffusion du FRsAG> > > http://www.frsag.org/%3E > > _______________________________________________> Liste de diffusion du FRsAG> http://www.frsag.org/_______________________________________________Liste de diffusion du FRsAGhttp://www.frsag.org/_______________________________________________Liste de diffusion du FRsAGhttp://www.frsag.org/
Richard Baret, le mar. 17 déc. 2019 22:02:28 +0100, a ecrit:
Après, qui sait si les AMD ne seront pas touchés à leur tour par des failles critiques dans le même genre. Mais ce n'est pas le cas en ce moment du moins...
AMD n'est pas touché par meltdown (qui est dû à un bug), mais il l'est par Spectre (qui est dû à la notion même d'optimisation de branchement etc. implémentée par tout processeur moderne)
Samuel
Le mar. 17 déc. 19 à 21:49:38 +0100, Vincent Duvernet vincent.duvernet@nolme.com écrivait :
Et dire que les nouveaux processeurs doivent nous apporter plus de performances. Pour ma part, je n'ai pas vraiment mesuré l'impact des 2 failles. Avant même que leur existence ne soit dévoilée, je trouvais déjà certains CPU décevants. Ma vieille workstation Terra i7-970 avec 32 GB de RAM et un SSD compile plus vite (avec un facteur x5 de mémoire sur des batchs) par rapport A mon portable Dell Inspiron 7773 avec son i7-8850U, 16 GB de RAM et un SSD.
Mais il faut avoir à l'esprit qu´on ne peut pas comparer les CPU utilisés en fixe avec ceux des portables.
C'est vrai aussi mais quand même près de 10 ans, ça commence à faire.
-----Message d'origine----- De : FRsAG frsag-bounces@frsag.org De la part de Thierry Thomas Envoyé : mardi 17 décembre 2019 22:20 À : frsag@frsag.org Objet : Re: [FRsAG] Impact sur les performances des protections contre Spectre/Meltdown
Le mar. 17 déc. 19 à 21:49:38 +0100, Vincent Duvernet vincent.duvernet@nolme.com écrivait :
Et dire que les nouveaux processeurs doivent nous apporter plus de performances. Pour ma part, je n'ai pas vraiment mesuré l'impact des 2 failles. Avant même que leur existence ne soit dévoilée, je trouvais déjà certains CPU décevants. Ma vieille workstation Terra i7-970 avec 32 GB de RAM et un SSD compile plus vite (avec un facteur x5 de mémoire sur des batchs) par rapport A mon portable Dell Inspiron 7773 avec son i7-8850U, 16 GB de RAM et un SSD.
Mais il faut avoir à l'esprit qu´on ne peut pas comparer les CPU utilisés en fixe avec ceux des portables. -- Th. Thomas. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Comparer un i7-970 et un i7-8550U, même s'ils ont 7 ans d'écart (et pas 10), c'est un peu comparer la vitesse d'une subaru impreza GT d'il y a 7 ans avec une twingo d'aujourd'hui... Petit rappel des caractéristiques de l'un et de l'autre: Model | I7-970 | I7-8550U Release | Q3-2010 | Q3-2017 Freq (Base/Turbo) | 3.2/3.46 GHz | 1.8/4.0 GHz Cache | 12MB | 8MB Cores/Threads | 6 / 12 | 4 / 8 TDP | 130W | 15W
Le premier consomme 10L/100km quand l'autre fait du 1L/100km, rien que pour cela on ne parle pas tout à fait de la même chose.
Ceci étant dit, il est clair que la performance par thread évolue beaucoup moins vite par le passé, et c'est un constat qui n'est pas neuf, je suis retombé l'autre jour sur un article de Herb Sutter qui le soulignait déjà en 2005: "The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software" (http://www.gotw.ca/publications/concurrency-ddj.htm). L'article est d'une clairvoyance étonnante, n'hésitez pas à le relire.
Pour avoir passé les 10 dernières années à optimiser des supercalculateurs, avancer qu'Intel n'a fait aucun progrès ni évolution me semble, comment dirais-je ? Hasardeux... Mais c'est une excellente chose qu'AMD revienne les chatouiller à la fois sur le terrain des performances intrinsèque et sur le terrain très important pour nous autres consommateurs qu'est le rapport prix/performance.
Le sujet des side-channel attacks que sont Spectre & Meltdown est très intéressant, et les exploits révélés il y a deux ans sont brillantissimes, d'une créativité que je ne peux m'empêcher de trouver magnifique. Il me semble difficile de blamer à ce point les fabriquants de microprocesseurs sur leur existence même, même s'il y aurait beaucoup à dire sur la façon et le niveau de transparence (ou son absence) avec lesquels ils ont géré la publication et la mitigation de ces failles.
Je me garderais bien de donner des conseils à qui que ce soit concernant l'importance ou non d'appliquer les correctifs sur vos infrastructures, mais pour ceux qui souhaitent creuser, il y a une excellente vidéo de Eric Brandwine concernant le fonctionnement de ces failles et la manière dont les hyperscalers ont mis en place des contre-mesures sur leurs infrastructures: Speculation & leakage: Timing side channels & multi-tenant computing (https://www.youtube.com/watch?v=kQ4H6XO-iao).
Une des conclusions de cette vidéo est que sur la dernière génération de processeurs ARM qu'AWS vient de sortir (Graviton 2), il n'y a pas de SMT/Hyperthreading, et ce n'est pas complètement un hasard.
Bonne soirée, Arthur
On Wed, Dec 18, 2019 at 12:53 AM Vincent Duvernet < vincent.duvernet@nolme.com> wrote:
C'est vrai aussi mais quand même près de 10 ans, ça commence à faire.
-----Message d'origine----- De : FRsAG frsag-bounces@frsag.org De la part de Thierry Thomas Envoyé : mardi 17 décembre 2019 22:20 À : frsag@frsag.org Objet : Re: [FRsAG] Impact sur les performances des protections contre Spectre/Meltdown
Le mar. 17 déc. 19 à 21:49:38 +0100, Vincent Duvernet < vincent.duvernet@nolme.com> écrivait :
Et dire que les nouveaux processeurs doivent nous apporter plus de performances. Pour ma part, je n'ai pas vraiment mesuré l'impact des 2 failles. Avant même que leur existence ne soit dévoilée, je trouvais déjà certains CPU décevants. Ma vieille workstation Terra i7-970 avec 32 GB de RAM et un SSD compile plus vite (avec un facteur x5 de mémoire sur des batchs) par rapport A mon portable Dell Inspiron 7773 avec son i7-8850U, 16 GB de RAM et un SSD.
Mais il faut avoir à l'esprit qu´on ne peut pas comparer les CPU utilisés en fixe avec ceux des portables. -- Th. Thomas. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/ _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le mer. 18 déc. 19 à 19:10:16 +0100, Arthur Petitpierre arthur@petitpierre.org écrivait :
Le sujet des side-channel attacks que sont Spectre & Meltdown est très intéressant, et les exploits révélés il y a deux ans sont brillantissimes, d'une créativité que je ne peux m'empêcher de trouver magnifique. Il me semble difficile de blamer à ce point les fabriquants de microprocesseurs sur leur existence même, même s'il y aurait beaucoup à dire sur la façon et le niveau de transparence (ou son absence) avec lesquels ils ont géré la publication et la mitigation de ces failles.
Je suis d´accord avec le reste du message, mais je me permets de relever ce passage : les risques liés à la complexité des MMU et à l´hyperthreading étaient connus depuis 2006 / 2007. Cf. par exemple un message de Theo de Raadt :
https://marc.info/?l=openbsd-misc&m=118296441702631&w=2.
Les performances des processeurs intel ces 10 dernières années n'ont que peu évoluées et en réalité, les gains de performance sont issus notamment des optimisations sur les mécanismes de prédiction et la gestion de la cache, qui sont par essence les domaines impactées par les failles de cette année.
Intel s'est reposé sur ses lauriers devant un manque de concurrence à la hauteur et n'a que peut progresser sur la finesse de gravure et utilise toujours la même architecture depuis trop de générations. Ce retard leur est actuellement difficile à rattraper, faute d'innovation en R&D depuis 10 ans.
AMD, quant à lui est revenu sur le devant de la scène ces 2 dernières années et pour le choix d'un processeur pour une workstation, je te conseille sans hésiter un AMD Ryzen 9 3900X qui présente 12 coeurs et 24 threads pour un prix raisonable et le tout gravé en 7nm pour les coeurs (14nm pour la partie controlleur, anciennement northbridge). Des tests de scalabilité montre que l'idéal serait 10 coeurs sur cette architecture. Donc je pense que le 3900X est plus intéressant que le 3950X avec ses 16 coeurs et 32 threads. De plus l'architecture étant différente et bien plus moderne, les failles concernant Intel ne les concernent pas (seulement 3 failles mitigées pour un AMD contre 14 pour un Intel).
En datacenter, AMD a son jeu à jouer maintenant car le rythme des mitigations à appliquer aux processeurs Intel impliquent un temps de maintenance imprévu non négligeable (14 failles en 1 an) tout en apportant ses régréssions de performances. Ce qui représente une charge de travail conséquente et non productive aux sysadmins.
Cordialement, -- -------------------------------------- Jean-François Maeyhieux Atanar Technologies http://www.atanar.com --------------------------------------
Le mardi 17 décembre 2019 à 20:49 +0000, Vincent Duvernet a écrit :
Et dire que les nouveaux processeurs doivent nous apporter plus de performances. Pour ma part, je n'ai pas vraiment mesuré l'impact des 2 failles. Avant même que leur existence ne soit dévoilée, je trouvais déjà certains CPU décevants. Ma vieille workstation Terra i7-970 avec 32 GB de RAM et un SSD compile plus vite (avec un facteur x5 de mémoire sur des batchs) par rapport A mon portable Dell Inspiron 7773 avec son i7-8850U, 16 GB de RAM et un SSD. Alors oui, c'est une génération U oui mais elle a presque 10 ans de moins, ça fait mal.
Pour les Windowsiens, j'ai trouvé 2 outils qui recherchent la faille : https://www.grc.com/inspectre.htm (très rapide) https://www.ashampoo.com/en/usd/psr/1304/security-software/spectre-meltdown-... (lui a mouliné un certains temps)
Comme j'envisage de remplacer mon vieux i7, je me pose pas mal de question pour savoir quel sera le meilleur choix pour Visual Studio 2019 (et un peu de gaming de temps en temps, on se refait pas ^^). Intel i7/i9, Intel Xeon, AMD ? Revoir le sujet des perfs de spectre et meltdown revenir me fait m'interroger sérieusement.
Vincent
-----Message d'origine----- De : FRsAG frsag-bounces@frsag.org De la part de Jean-Francois Maeyhieux Envoyé : mardi 17 décembre 2019 18:32 À : frsag@frsag.org Objet : Re: [FRsAG] Impact sur les performances des protections contre Spectre/Meltdown
Je confirme ce que te dit Florian, certaines mises à jour du microcode corrigent soit directement une faille, soit corrigent une faille de concert avec l'OS (principalement le kernel).
Je te conseille d'utiliser le script spectre-meltdown-checker qui fait un diagnostic de l'état du système vis à vis de chaque faille. Tu y découvriras pour chaque faille le ou les pré-requis au niveau du micro-code et/ou de l'OS: https://github.com/speed47/spectre-meltdown-checker
Cela te permettra potoentiellement de downgrader le microcode pour revenir à tes anciennes performances.
A noter, le micro-code se met à jour:
- soit par flashage du BIOS
- soit par chargement du microcode au boot de ta machine:
- via un initrd (prise en compte en début de boot)
- via un service (prise en compte plus tard dans la phase de boot)
De plus, tu as remarqué une dégradation de l'usage CPU mais l'impact principal de ces correctifs concernent tout ce qui est relatif aux appels systèmes donc principalement les I/O car à chaque appel système depuis le user-space, il faut flusher le cache du CPU ! J'ai pu remarqué des pertes de l'ordre de 30% notamment sur les accès disques en écriture aléatoire.
Ces correctifs sont vraiment vicieux car à chaque correctif, Intel nous dit que l'impact est de l'ordre de quelques pourcents mais tout les correctifs cumulés entrainent de sérieuses régréssions des performances au final.
Cordialement,
Jean-François Maeyhieux Atanar Technologies http://www.atanar.com
Le mardi 17 décembre 2019 à 17:50 +0100, Greg a écrit :
Oui, et en cas d'absence de ces microcodes, les protections ne peuvent fonctionner, et donc c'est comme si elles étaient désactivées.
Le mar. 17 déc. 2019 à 16:48, Florian Stosse < florian.stosse@gmail.com> a écrit :
Hello,
A tout hasard, est ce que tu appliques également les mises à jour du microcode Intel à la volée lors du boot, avec le paquet intel- microcode ? La différence de performances peut aussi venir de là.
-- Florian STOSSE | Ingénieur en sécurité informatique
Le mar. 17 déc. 2019 à 16:26, Greg greg-frsag@duchatelet.net a écrit :
Bonjour,
Les derniers Kernel semblent plus mauvais en terme de performance. Un serveur fonctionnait sur un kernel "maison" 4.14, j'ai voulu le remettre en kernel officiel Debian Buster donc 4.19, les performances se sont écroulées: hausse de la conso CPU, du load, et augmentation des temps de réponse PHP de l'ordre de +50% ! Le dernier kernel 5.3 n'apportera aucune solution.
On peut depuis le 5.2 désactiver les protections contre les failles de sécurité affectant tous les processeurs modernes (pas que Intel, mais aussi ARM, AMD et MIPS) avec le paramètre de boot mitigations=off C'est mieux, mais je ne retrouve pas les perfs du 4.14 (conso CPU et temps de réponse).
Lien vers la doc sur ces paramètres: https://linuxreviews.org/HOWTO_make_Linux_run_blazing_fast_(again)_on_Intel_...
Voilà ce que ça donne sur un serveur en production :
Savez vous ce qu'il faudrait faire pour retourner au niveau de perf du 4.14 ?
Merci !
Greg _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Spectre touche tous les processeurs modernes, AMD compris.
Il va falloir faire un choix entre sécurité et pérennité vs. les performances ... choix évident, et pour atteindre le même niveau de perfs il va falloir acheter des serveurs et donc des processeurs...
Le mar. 17 déc. 2019 à 22:24, Jean-Francois Maeyhieux b4b1@free.fr a écrit :
Les performances des processeurs intel ces 10 dernières années n'ont que peu évoluées et en réalité, les gains de performance sont issus notamment des optimisations sur les mécanismes de prédiction et la gestion de la cache, qui sont par essence les domaines impactées par les failles de cette année.
Intel s'est reposé sur ses lauriers devant un manque de concurrence à la hauteur et n'a que peut progresser sur la finesse de gravure et utilise toujours la même architecture depuis trop de générations. Ce retard leur est actuellement difficile à rattraper, faute d'innovation en R&D depuis 10 ans.
AMD, quant à lui est revenu sur le devant de la scène ces 2 dernières années et pour le choix d'un processeur pour une workstation, je te conseille sans hésiter un AMD Ryzen 9 3900X qui présente 12 coeurs et 24 threads pour un prix raisonable et le tout gravé en 7nm pour les coeurs (14nm pour la partie controlleur, anciennement northbridge). Des tests de scalabilité montre que l'idéal serait 10 coeurs sur cette architecture. Donc je pense que le 3900X est plus intéressant que le 3950X avec ses 16 coeurs et 32 threads. De plus l'architecture étant différente et bien plus moderne, les failles concernant Intel ne les concernent pas (seulement 3 failles mitigées pour un AMD contre 14 pour un Intel).
En datacenter, AMD a son jeu à jouer maintenant car le rythme des mitigations à appliquer aux processeurs Intel impliquent un temps de maintenance imprévu non négligeable (14 failles en 1 an) tout en apportant ses régréssions de performances. Ce qui représente une charge de travail conséquente et non productive aux sysadmins.
Cordialement,
Jean-François Maeyhieux Atanar Technologies http://www.atanar.com
Le mardi 17 décembre 2019 à 20:49 +0000, Vincent Duvernet a écrit :
Et dire que les nouveaux processeurs doivent nous apporter plus de performances. Pour ma part, je n'ai pas vraiment mesuré l'impact des 2 failles. Avant même que leur existence ne soit dévoilée, je trouvais déjà certains CPU décevants. Ma vieille workstation Terra i7-970 avec 32 GB de RAM et un SSD compile plus vite (avec un facteur x5 de mémoire sur des batchs) par rapport A mon portable Dell Inspiron 7773 avec son i7-8850U, 16 GB de RAM et un SSD. Alors oui, c'est une génération U oui mais elle a presque 10 ans de moins, ça fait mal.
Pour les Windowsiens, j'ai trouvé 2 outils qui recherchent la faille : https://www.grc.com/inspectre.htm (très rapide)
https://www.ashampoo.com/en/usd/psr/1304/security-software/spectre-meltdown-... (lui a mouliné un certains
temps)
Comme j'envisage de remplacer mon vieux i7, je me pose pas mal de question pour savoir quel sera le meilleur choix pour Visual Studio 2019 (et un peu de gaming de temps en temps, on se refait pas ^^). Intel i7/i9, Intel Xeon, AMD ? Revoir le sujet des perfs de spectre et meltdown revenir me fait m'interroger sérieusement.
Vincent
-----Message d'origine----- De : FRsAG frsag-bounces@frsag.org De la part de Jean-Francois Maeyhieux Envoyé : mardi 17 décembre 2019 18:32 À : frsag@frsag.org Objet : Re: [FRsAG] Impact sur les performances des protections contre Spectre/Meltdown
Je confirme ce que te dit Florian, certaines mises à jour du microcode corrigent soit directement une faille, soit corrigent une faille de concert avec l'OS (principalement le kernel).
Je te conseille d'utiliser le script spectre-meltdown-checker qui fait un diagnostic de l'état du système vis à vis de chaque faille. Tu y découvriras pour chaque faille le ou les pré-requis au niveau du micro-code et/ou de l'OS: https://github.com/speed47/spectre-meltdown-checker
Cela te permettra potoentiellement de downgrader le microcode pour revenir à tes anciennes performances.
A noter, le micro-code se met à jour:
- soit par flashage du BIOS
- soit par chargement du microcode au boot de ta machine:
- via un initrd (prise en compte en début de boot)
- via un service (prise en compte plus tard dans la phase de boot)
De plus, tu as remarqué une dégradation de l'usage CPU mais l'impact principal de ces correctifs concernent tout ce qui est relatif aux appels systèmes donc principalement les I/O car à chaque appel système depuis le user-space, il faut flusher le cache du CPU ! J'ai pu remarqué des pertes de l'ordre de 30% notamment sur les accès disques en écriture aléatoire.
Ces correctifs sont vraiment vicieux car à chaque correctif, Intel nous dit que l'impact est de l'ordre de quelques pourcents mais tout les correctifs cumulés entrainent de sérieuses régréssions des performances au final.
Cordialement,
Jean-François Maeyhieux Atanar Technologies http://www.atanar.com
Le mardi 17 décembre 2019 à 17:50 +0100, Greg a écrit :
Oui, et en cas d'absence de ces microcodes, les protections ne peuvent fonctionner, et donc c'est comme si elles étaient désactivées.
Le mar. 17 déc. 2019 à 16:48, Florian Stosse < florian.stosse@gmail.com> a écrit :
Hello,
A tout hasard, est ce que tu appliques également les mises à jour du microcode Intel à la volée lors du boot, avec le paquet intel- microcode ? La différence de performances peut aussi venir de là.
-- Florian STOSSE | Ingénieur en sécurité informatique
Le mar. 17 déc. 2019 à 16:26, Greg greg-frsag@duchatelet.net a écrit :
Bonjour,
Les derniers Kernel semblent plus mauvais en terme de performance. Un serveur fonctionnait sur un kernel "maison" 4.14, j'ai voulu le remettre en kernel officiel Debian Buster donc 4.19, les performances se sont écroulées: hausse de la conso CPU, du load, et augmentation des temps de réponse PHP de l'ordre de +50% ! Le dernier kernel 5.3 n'apportera aucune solution.
On peut depuis le 5.2 désactiver les protections contre les failles de sécurité affectant tous les processeurs modernes (pas que Intel, mais aussi ARM, AMD et MIPS) avec le paramètre de boot mitigations=off C'est mieux, mais je ne retrouve pas les perfs du 4.14 (conso CPU et temps de réponse).
Lien vers la doc sur ces paramètres:
https://linuxreviews.org/HOWTO_make_Linux_run_blazing_fast_(again)_on_Intel_...
Voilà ce que ça donne sur un serveur en production :
Savez vous ce qu'il faudrait faire pour retourner au niveau de perf du 4.14 ?
Merci !
Greg _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Le mer. 18 déc. 2019 à 09:15, Greg greg-frsag@duchatelet.net a écrit :
Il va falloir faire un choix entre sécurité et pérennité vs. les performances ... choix évident, et pour atteindre le même niveau de perfs il va falloir acheter des serveurs et donc des processeurs...
Question : hors environnements dans lesquels le CPU est partagé entre plusieurs utilisateurs et sur lesquels ont ne maîtrise pas forcément le code exécuté (hôte de virtualisation ou hébergement mutualisé), est-il réellement nécessaire de patcher ces failles ?
Je n'en suis pas convaincu, la plupart (totalité ?) n'étant pas exploitables sans un accès préalable à la machine.
Oui C'est pour ça que sur mes serveurs de stockage (par exemple), ou de databases (autre exemple), je désactive tout ça
On 12/18/19 6:12 PM, Jonathan Leroy - Inikup via FRsAG wrote:
Le mer. 18 déc. 2019 à 09:15, Greg greg-frsag@duchatelet.net a écrit :
Il va falloir faire un choix entre sécurité et pérennité vs. les performances ... choix évident, et pour atteindre le même niveau de perfs il va falloir acheter des serveurs et donc des processeurs...
Question : hors environnements dans lesquels le CPU est partagé entre plusieurs utilisateurs et sur lesquels ont ne maîtrise pas forcément le code exécuté (hôte de virtualisation ou hébergement mutualisé), est-il réellement nécessaire de patcher ces failles ?
Je n'en suis pas convaincu, la plupart (totalité ?) n'étant pas exploitables sans un accès préalable à la machine.
Bonjour,
Et en cas de problème, quand il faudra déclarer à la CNIL qu'il y a eu une fuite, et que lors de l'audit on découvre que tout n'a pas été mis en œuvre pour protéger les données personnelles, l'amende va piquer.
Quel enjeu pourrait bien primer sur la protection de la vie d'autrui ?
Je n'aimerais vraiment pas avoir à entendre un jour qu'un-e de mes proches s'est retrouvée exposé-e personnellement à cause d'un-e sysadmin qui a désactivé des protections pourtant critiques, tout cela pour économiser quelques cycles CPU...
Bien cordialement, -- Maxime DERCHE
Le 18/12/2019 à 18:26, frsag@jack.fr.eu.org a écrit :
Oui C'est pour ça que sur mes serveurs de stockage (par exemple), ou de databases (autre exemple), je désactive tout ça
On 12/18/19 6:12 PM, Jonathan Leroy - Inikup via FRsAG wrote:
Le mer. 18 déc. 2019 à 09:15, Greg greg-frsag@duchatelet.net a écrit :
Il va falloir faire un choix entre sécurité et pérennité vs. les performances ... choix évident, et pour atteindre le même niveau de perfs il va falloir acheter des serveurs et donc des processeurs...
Question : hors environnements dans lesquels le CPU est partagé entre plusieurs utilisateurs et sur lesquels ont ne maîtrise pas forcément le code exécuté (hôte de virtualisation ou hébergement mutualisé), est-il réellement nécessaire de patcher ces failles ?
Je n'en suis pas convaincu, la plupart (totalité ?) n'étant pas exploitables sans un accès préalable à la machine.
Liste de diffusion du FRsAG http://www.frsag.org/
Le ven. 20 déc. 2019 à 17:15, Maxime DERCHE maxime@mouet-mouet.net a écrit :
Et en cas de problème, quand il faudra déclarer à la CNIL qu'il y a eu une fuite, et que lors de l'audit on découvre que tout n'a pas été mis en œuvre pour protéger les données personnelles, l'amende va piquer.
Sauf que, hors environnement mutualisé, une fois que l'attaquant est entré dans le système c'est déjà trop tard. Qu'il passe ensuite root ou non, il a déjà accès au code de l'application et donc à la base de données (les infos de connexion à celle-ci étant dans 99 % des cas stockés dans un fichier PHP).
-- Jonathan Leroy
Ne pas faire de votre cas une généralité comme parler de fichier php ce qui est hors de propos. Le but des protections n'est pas d'arrêter les attaques malheureusement mais de réduire la surface d'attaque d'un serveur/service//appli.
Et je ne le répéterais jamais assez, il faut patcher ses serveurs et mettre en place les MAJ régulièrement de tous les services.
Quant à Intel il est très mal barré BranchScope, PortSmash, Meltdown/Spectre, TLBleed et Foreshadow, ZombieLoad 1 et 2, etc... puis Plundervolt pour la dernière faille en date de ce mois-ci. Sans compter l'approvisionnement chez les différents fournisseurs des qui a laissé à désirer cette année et je ne vois pas d'amélioration là-dessus pour cet nouvelle année.
Le ven. 20 déc. 2019 à 19:53, Jonathan Leroy - Inikup via FRsAG < frsag@frsag.org> a écrit :
Le ven. 20 déc. 2019 à 17:15, Maxime DERCHE maxime@mouet-mouet.net a écrit :
Et en cas de problème, quand il faudra déclarer à la CNIL qu'il y a eu
une fuite, et
que lors de l'audit on découvre que tout n'a pas été mis en œuvre pour
protéger les
données personnelles, l'amende va piquer.
Sauf que, hors environnement mutualisé, une fois que l'attaquant est entré dans le système c'est déjà trop tard. Qu'il passe ensuite root ou non, il a déjà accès au code de l'application et donc à la base de données (les infos de connexion à celle-ci étant dans 99 % des cas stockés dans un fichier PHP).
-- Jonathan Leroy _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le ven. 20 déc. 2019 à 20:08, Refuznik refuznikster@gmail.com a écrit :
Ne pas faire de votre cas une généralité
On discute, je donne mon point de vue, je ne vois pas en quoi je fais de mon cas une généralité.
comme parler de fichier php ce qui est hors de propos.
C'est un exemple, extrêmement courant qui plus est. La majorité des intrusions se font de depuis le web, donc ça ne me semble pas être hors de propos.
Le but des protections n'est pas d'arrêter les attaques malheureusement mais de réduire la surface d'attaque d'un serveur/service//appli.
On est d'accord.
Et je ne le répéterais jamais assez, il faut patcher ses serveurs et mettre en place les MAJ régulièrement de tous les services.
"Il faut" n'est pas un argument. Quand la MAJ en question engendre une perte de 30 % de perfs en moyenne (dans mon cas) en améliorant très peu la sécurité en retour, on est en droit de débattre de la nécessité de la déployer.
On discute, je donne mon point de vue, je ne vois pas en quoi je fais de mon cas une généralité.
T'as dit juste ce qu'il fallait (imho) :>
comme parler de fichier php ce qui est hors de propos.
Vrai que le PHP, c'est un langage hyper rare sur les serveurs...
C'est un exemple, extrêmement courant qui plus est. La majorité des intrusions se font de depuis le web, donc ça ne me semble pas être hors de propos.
+1 Avec un tel langage en carton...
"Il faut" n'est pas un argument. Quand la MAJ en question engendre une
+1 Tout dépend effectivement du contexte.
Hello,
Je n'aimerais vraiment pas avoir à entendre un jour qu'un-e de mes proches s'est retrouvée exposé-e personnellement à cause d'un-e sysadmin qui a désactivé des protections pourtant critiques, tout cela pour économiser quelques cycles CPU...
C'est pour ça que sur mes serveurs de stockage (par exemple), ou de databases (autre exemple), je désactive tout ça
Si pour le stockage je ne peux qu'approuver, pour les databases, je ne sais pas trop.
Je n'aimerais vraiment pas avoir à entendre un jour qu'un de mes proches s'est retrouvé exposé personnellement à cause d'un sysadmin qui a désactivé des protections pourtant critiques, tout cela pour économiser quelques cycles CPU...
Disons que trop de protections deviens très vite contre productif. C'est comme les gens qui mettent 3 couches de firewalls, et qui a la fin prennent 3 mois a comprendre pourquoi cette foutu règle de ne marche pas... (a cause du firewall transparent entre les 2 autres).
Il y a clairement 2 type de x86 : - ceux qui se prennent le traffic dans la tronche : reverse proxy / serv php / firewall (routeurs) - ceux qui sont loiiiiin derrière ceux là souvent dans des reseaux fermés et/ou avec des VRF / netns différents qui eux n'ont pas besoin des ces protections orienté HT, car elles sont désactivées et le CPU n'as vraiment pas que ça à foutre de vérifier des choses, car il doit calculer des checksums tout le temps et balancer de data sur le wire.
Dans le second cas, ces protections -> benne. Un moment la réponse il faut prendre un proco plus puissant pour gérer des protections, ça passe plus dans le bureau du responsable financier... Même si le risque est là, il faut le prendre... (comme celui d'avoir un accident dans ton moyen de transport favori pour aller au travail).
Ceci n'est que mon expérience perso et mon point de vu. Loin de là de l'imposer.
Xavier
On Wed, 18 Dec 2019 18:12:09 +0100 Jonathan Leroy - Inikup via FRsAG frsag@frsag.org wrote:
| Le mer. 18 déc. 2019 à 09:15, Greg greg-frsag@duchatelet.net a écrit : | > Il va falloir faire un choix entre sécurité et pérennité vs. les performances ... choix évident, et pour atteindre le même niveau de perfs il va falloir acheter des serveurs et donc des processeurs... | | Question : hors environnements dans lesquels le CPU est partagé entre | plusieurs utilisateurs et sur lesquels ont ne maîtrise pas forcément | le code exécuté (hôte de virtualisation ou hébergement mutualisé), | est-il réellement nécessaire de patcher ces failles ? | | Je n'en suis pas convaincu, la plupart (totalité ?) n'étant pas | exploitables sans un accès préalable à la machine.
Dans certains cas l'accès à la machine qui peut se faire via une faille applicative...
Manuel
-- ______________________________________________________________________ Manuel Guesdon - OXYMIUM
-
Arthur Petitpierre -
Florian Stosse -
frsag＠jack.fr.eu.org -
Greg -
Jean-Francois Maeyhieux -
Jonathan Leroy - Inikup -
Manuel Guesdon -
Maxime DERCHE -
Refuznik -
Richard Baret -
Samuel Thibault -
Stéphane Rivière -
Thierry Thomas -
Vincent Duvernet -
Vincent Tondellier -
Xavier Beaudouin