Ce code pourrait-il endommager mon processeur?

Un ami m’a envoyé ce code et allègue qu’il pourrait endommager le processeur. Est-ce vrai?

void damage_processor() { while (true) { // Assembly code that sets the five control registers bits to ones which causes a bunch of exceptions in the system and then damages the processor Asm( "mov cr0, 0xffffffff \n\t" "mov cr1, 0xffffffff \n\t" "mov cr2, 0xffffffff \n\t" "mov cr3, 0xffffffff \n\t" "mov cr4, 0xffffffff \n\t" ) } } 

Est-ce vrai?

De code utilisateur? Cela provoquera une exception de privilège et le kernel mettra fin à votre programme. Du code du kernel? J’en doute; vous lancerez des exceptions et vous devrez configurer manuellement le gestionnaire d’erreurs pour revenir au code en question et continuer à le faire. Il y a également une bonne chance que vous causiez une sortingple faute si une partie du déplacement CR3 réussissait, car cela contrôle l’adresse de la table des pages et vous obtiendrez probablement des erreurs lors de l’extraction des instructions, de l’extraction par le gestionnaire, puis de l’extraction du gestionnaire à double faute. Le processeur devrait simplement s’arrêter si cela se produit.

Consultez les manuels Intel ou AMD pour la programmation des systèmes. Ils vous indiqueront les exceptions générées lors de l’écriture de bits non valides dans les registres de contrôle.

Peut-être que si vous le laissez fonctionner pendant environ 20 ans.

Peut-être que ce code provoque le blocage de votre processeur / système, mais il n’ya aucune chance qu’il soit endommagé de façon permanente.

Imaginez si cela était vrai: il serait immédiatement utilisé par les virus / chevaux de Troie pour attaquer des ordinateurs ou cacher leur activité après détection.

Même dans le cas où un code pourrait endommager un processeur, le fabricant du processeur pourrait émettre une mise à jour appelée microcode-update, qui ressemble à une solution logicielle pour le processeur. Ces mises à jour de microcode sont fournies par les systèmes d’exploitation et / ou le BIOS (et les fabricants de processeurs) et sont chargées dans le processeur avant l’exécution de ce code.

Pour résumer: non, votre ami a tort, en supposant qu’il s’agisse de plates-formes x86 / x64.

Si le but est d’exercer fébrilement le processeur dans l’espoir de le casser, les systèmes informatiques disposent de solutions thermiques (ventilateurs, échangeurs de chaleur en cuivre, dissipateurs de chaleur, etc.) pour éviter les surchauffes. En cas de défaillance de la solution thermique, le BIOS affirme #THERMTRIP et éteint la machine.

J’ai entendu parler d’un bug dans le Pentium I qui, lorsqu’on lui donnait une série d’instructions absurdes dans une boucle serrée, brûlerait une simple bascule si rapidement que la protection thermique ne pourrait pas le protéger.

Ce que j’ai trouvé référence pour une fois était que de très vieux processeurs pouvaient être préparés en mode réel:

 halt: jmp short halt 

Le bon code était

 halt: nop jmp short halt 

Désolé, le code ne fonctionne pas sur un processeur ARM.

Dans de nombreux processeurs, les instructions qui définissent le mot d’état ou affectent le processeur sont limitées au mode “superviseur”. Les bons systèmes d’exploitation exécutent le code d’utilisateur dans un mode “protégé” qui n’a pas les mêmes capacités que le mode “superviseur”. L’exécution d’instructions privilégiées sur les processeurs modernes en mode utilisateur génère des exceptions.

Vous et votre ami pouvez toujours rechercher les instructions dans un manuel de référence en langage assembleur et en vérifier le fonctionnement.

Le code en question est peu susceptible de faire beaucoup sauf redémarrer la machine. D’après mon expérience, un processeur x86 pourrait être configuré en exécutant du code logiciel.