Discussion:Mitigation de la vulnérabilité spectre

Relecture sur le résumé introductif

voici mes remarques suite à ma relecture sur le résumé introductif :

• Tournures de phrases :
  • "de cette dernière" -> "à la popularisation de la vulnérabilité spectre" (un peu plus long mais je trouve ça un peu plus clair).
  • "La recherche permanente d'amélioration des performances" -> "La recherche permanente sur l'amélioration des performances,"
• Lien bleu : mitigation -> Mot peu courant

Haydgoki (discuter) 21 janvier 2019 à 15:28 (CET)

J'ai pris en compte les suggestions de modification et je les ai ajoutées au résumé

Deregnab (discuter) 21 janvier 2019 à 16:05 (CET)

Relecture de la partie "Principe de mitigation"

voici mes remarques suite à ma relecture sur cette partie :

• Tournures de phrases :
  • "On découpe généralement les défenses face aux attaques spectre en 3 catégories" -> "On peut résumer la plupart des défenses face aux attaques spectres en 3 catégories"
  • "Ces trois méthodes de mitigation sont ensuite regroupées en 2 catégories, les solutions matérielles et les solutions logicielles." -> "Ces trois catégories de mitigation peuvent être appliquées soit par des solutions logicielles, soit par des solutions matérielles". (on pourrait faire cette transformation si j'ai bien compris le sens, ça me paraît plus clair.
• Lien bleu ou phrase d'explication : "Les canaux couverts". On ne voit pas forcément ce que c'est du premier coup.

Haydgoki (discuter) 21 janvier 2019 à 15:52 (CET)

Je suis d'accord avec les modifications à apporter à la tournure. La première phrase rend mieux et la seconde nous permet d'éviter d'avoir un répétition au sein de l'article

Je vais regarder pour bleuir l'expression canal couvert

Deregnab (discuter) 21 janvier 2019 à 16:18 (CET)

Relecture de la partie "Enjeux de la mitigation"

• Bleuir :
  • Meltdown (vulnérabilité)

• Orthographe :
  • ce qui a permis a des personnes -> ce qui a permis à des personnes
  • Des moyens sont mis a disposition -> Des moyens sont mis à disposition
  • des techniques de mitigations -> des techniques de mitigation
  • et des principes de mitigations appliquées -> et des principes de mitigation appliqués
  • des calculs haute performance parallélises -> des calculs haute performance parallélisés
  • Le but est savoir -> Le but est de savoir
  • qui sont couteux -> qui sont coûteux
  • logique que de voir -> logique de voir (sans "que")

• Question de rédaction :
  • "était important pour ces fabricants" <- que désigne "ces" ? vous n'avez pas énoncé qui étaient les fabricants concernés. Correction possible : important pour les fabricants concernés"
  • "il reste assez difficile de savoir si la vulnérabilité n'est toujours pas existante" <- double négation = attention. Correction possible : il reste assez difficile de savoir si la vulnérabilité existe toujours"
  • "vérifier si son système" <- vérifier si un système, plutôt ? le "son" est un peu personnel, il fait référence au "on"
  • "Ces résultats sont de l'ordre d'environ 2-3% plus lent pour des travaux parallèles à un nœud, et d'environ 5-11% plus lent pour des travaux" <- la phrase est bancale, notamment à cause de la répétition "de l'ordre d'environ", mais aussi parce que ce ne sont pas les résultats qui sont plus lents. Il faudrait reformuler cette affirmation.
  • "Les résultats, exprimés en pourcentage moyen en termes de ralentissement" <- on ne comprend pas forcément comment sont exprimés les pourcentages. Je suppose qu'il s'agit d'un rapport de temps entre les deux exécutions, mais cela n'est pas dit "clairement". Vous pourriez peut-être le préciser ?

Diieus (discuter) 21 janvier 2019 à 17:00 (CET)

Je viens de mettre à jour les modifications mineures.

Pour les questions de rédaction, je suis d'accord pour la plupart, et j'ai directement mis à jour avec les corrections qui me paraissaient cohérentes.

Je n'ai pas modifié "vérifier si son système", je voulais justement que le "son" soit personnel, puisque je reference un site ou on peut directement savoir si son système est actuellement vulnérable. Etant donné qu'on fait le test sur sa machine, je pense que ça serait ambigu d'utiliser "un système", car on pourrait supposer qu'il est possible de tester à distance si un système est vulnérable, ce qui n'est pas le cas. Après je suis d'accord que la phrase peut être reformulée.

Seysn (discuter) 22 janvier 2019 à 12:09 (CET)

Il reste à bleuir Grsecurity dans cette section.

Diieus (discuter) 26 janvier 2019 à 14:57 (CET)

J'ai rajouté le lien bleu

Deregnab (discuter) 28 janvier 2019 à 14:58 (CET)

Peut-être aussi pourriez-vous, dans la partie "Limiter la perte de performance", mieux citer l'article de Monsieur Prout ? Les résultats présentés dans les tableaux viennent de son article, non ?

Diieus (discuter) 26 janvier 2019 à 15:05 (CET)

Je ne sais pas trop comment mieux referencer les résultats. J'ai l'impression que mettre une reference à chaque titre serait plutôt lourd et pas forcement utile, étant donné que je reference déjà les résultats dans leur introduction. Mais d'un autre côté, je suis quand même d'accord avec cette remarque.

Seysn (discuter) 28 janvier 2019 à 16:27 (CET)

Relecture de la partie "Solutions appliquées"

• Bleuir :
  • Intel
  • iOS
  • macOS High Sierra

• Orthographe :
  • qui est censé être plus précise -> qui est censée être plus précise

• Question de rédaction :
  • "trois solutions pour mitiger les vulnérabilités d’exécution spéculative : Prévenir les techniques de spéculation, Enlever les données sensibles de la mémoire et Enlever les canaux d'observation." <- Pourquoi avoir gardé les majuscules alors même que la phrase est construite avec des virgules ? Il faudrait soit les enlever, soit mettre entre guillemets les descriptions des trois solutions.
  • vous parlez de plusieurs organismes comme Microsoft, Apple ou Mozilla, mais parfois vous employez ces noms pour parler au pluriel (ex : "Mozilla ont désactivé l'objet") et parfois au singulier (ex : "Apple mentionne avoir publié des mises à jour"). Essayez de normaliser cela.

Diieus (discuter) 26 janvier 2019 à 14:57 (CET)

C'est fait !

Seysn (discuter) 28 janvier 2019 à 16:23 (CET)

Relecture de la partie "Solutions matérielles"

voici mes remarques suite à ma relecture sur cette partie :

• Syntaxe/orthographe :
  • "Spectre3,4. Néanmoins" -> passage de ligne pour ouvrir un nouveau paragraphe. Nouvelle solution, nouveau paragraphe.
  • "Ce prototype est en cours de développement est et vise pour le moment"
• Tournure de phrase :

"Cette solution n'est pas réaliste car conduirait à une perte de performance significative" -> "Cette solution n'est pas réaliste car elle conduirait à une perte de performance's significative"

• Lien bleu :
  • l'exécution spéculative --> encore une fois, au cas où on aurait pas lu le résumé introductif
  • structure
  • adresse
  • architecture

Autres remarques : "Par conséquent, les données des instructions qui ne retournent pas un succès" -> qu'est-ce qui détermine un succès d'une instruction ?

(à noter que je corrigerai l'orthographe moi même mais que je vous laisse le choix sur les tournures de phrases et le reste.)

Haydgoki (discuter) 21 janvier 2019 à 16:24 (CET)

J'ai ajouté les liens comme recommandé

Plutôt que de créer un nouveau paragraphe j'ai choisi de modifier la formulation de la phrase car il ne s'agit d'un nouveau type de solution mais d'une alternative fonctionnant sur le même principe que Safespec

J'ai tenté de rajouter l'explication concernant le succès d'une instruction. Peux-tu me faire un retour sur ton impression à la lecture de cet ajout.

Deregnab (discuter) 21 janvier 2019 à 16:49 (CET)

Pour moi la notion de succès me paraît assez claire désormais. Néanmoins il manquerait une paire de parenthèse pour ne pas casser le rythme de la phrase

Haydgoki (discuter) 21 janvier 2019 à 17:00 (CET)