Les compilateurs construits avec une version antérieure d'eux-mêmes sont-ils protégés contre l'injection de code ?

Question

Je me demandais si les compilateurs modernes d'aujourd'hui comme MS cc, gcc, clang, icc, des versions plus récentes ont été construits avec la version actuelle du même compilateur ?

En raison bien sûr de ce risque :
http://scienceblogs.com/goodmath/2007/04/15/strange-loops-dennis-ritchie-a/
http://c2.com/cgi/wiki?TheKenThompsonHack

Je suis sûr que toutes les personnes impliquées dans le développement des compilateurs susmentionnés connaissent ce problème, par lequel du code est injecté dans le compilateur par une version antérieure de lui-même et se propage de manière invisible.

Maintenant, le vrai problème n'est pas vraiment celui des portes dérobées, mais plutôt celui de la correction de la génération du code, n'est-ce pas ? Que se passe-t-il si quelque part dans la chaîne de construction, une torsion perverse a été introduite par pure erreur, et que le compilateur d'aujourd'hui génère un code incorrect, même si la source du compilateur semble correcte, à cause de la faille de Ken Thompson ?

Alors s'ils sont construits avec eux-mêmes, comment se protègent-ils ?

Answer 1

Je me demandais si les compilateurs modernes d'aujourd'hui comme MS cc, gcc, clang, icc, des versions plus récentes ont été construits avec la version actuelle du même compilateur ?

Le compilateur Roslyn C# peut se construire tout seul ; en fait, il est l'un de ses meilleurs cas d'école. Bien sûr, il n'a pas pu le faire le premier jour, ni même le 100e jour ; il a été construit avec la version précédente du compilateur C#, qui était écrite en C++.

Et si, quelque part dans la chaîne de construction, une tournure perverse a été introduite par pure erreur, et que le compilateur d'aujourd'hui génère un code incorrect, même si les sources du compilateur ont l'air correctes ?

Il s'agit d'une grave préoccupation.

L'une des façons intéressantes de rechercher un bogue dans un compilateur auto-construit est la suivante : appelez le compilateur original non auto-construit Alpha. Construisez le nouveau code source avec Alpha pour produire Beta. Faites ensuite construire le code source par Beta pour produire Gamma. Ensuite, Gamma construit le code source pour produire Delta. S'il existe des différences significatives entre les binaires produits pour Gamma et Delta, vous avez probablement un problème. Beta et Gamma devraient avoir les mêmes résultats pour les mêmes entrées. (Le C# en particulier ne promet pas que la compilation du même code deux fois produise exactement le même binaire, vous devez donc veiller à ce que votre test soit suffisamment sophistiqué pour en tenir compte).

La façon de réduire ce risque est bien sûr la même que celle qui permet de réduire tout risque associé à de mauvais outils : vous enregistrez différentes versions des outils du compilateur dans le référentiel, afin de pouvoir revenir à une version antérieure connue du compilateur en cas de besoin. Et vous testez le compilateur de manière intensive.

Answer 2

En général, la réponse est "oui", pour les compilateurs mis en œuvre dans leur propre langage. Construire le compilateur avec lui-même est l'un des meilleurs tests de correction. Des exécutions successives devraient continuer à produire le même binaire. GC, par exemple, est construit avec un processus d'amorçage en quatre étapes.

Bien sûr, certains langages ne peuvent pas être utilisés pour l'écriture de compilateurs.

EDIT Il faut préciser que cette réponse a été postée alors que la question de fond était "Les compilateurs sont-ils construits avec une version antérieure d'eux-mêmes ?". Elle a été modifiée par la suite.