Journal Bootstrap Binary seed

60
4
fév.
2019

Demat'iNal,

J'ai été frappé (ouille) par cet exposé au FOSDEM 2019.
Le sujet sous-jacent était « comment arriver à un compilateur C » à partir de… source. Et il est vrai que jamais je ne m'étais posé la question sous cet angle : arriver à faire qu'un compilateur pour un langage X soit écrit dans ce même langage X suppose… que l'on ait déjà un compilateur pour X. Ce problème se gérant soit par la disponibilité d'un autre compilateur, soit d'une version antérieure du même compilateur.

Prenons un exemple : la première ligne de code de GCC-9 n'a pas pu être compilée avec gcc-9 (vu que celui-ci n'existait pas encore), mais avec une version antérieure, disons GCC-8, qui lui même a été pour la première fois compilé par GCC-7 etc (ignorons les versions mineurs pour la simplicité de l'exemple).

Mais qu'y avait il au… tout début ? Serions nous capable de reconstruire GCC-9 (dont une partie est écrite en C++) sans GCC ?

Une chaîne possible serait de passer par GCC-4.7, dernier GCC à être écrit purement en C, mais supportant le C++. Et on peut compiler GCC-4.7 à partir d'un autre compilateur, a priori plus simple, TCC. Mais encore faut-il être capable de compiler TCC, ce qui reste plus simple que de compiler GCC.

Ce dépôt montre un chemin possible pour bootstrapper à partir de rien. Et c'est fascinant ! On commence par un petit bout de binaire écit à la main (il faut bien !) pour aller vers un langage de macro simplissime, puis un assembleur simpliste et enfin un assembleur correct, une mini-VM etc.

Il y a pleins d'approches intéressantes du problème, ce journal vous enjoind à jouer avec l'idée ! Quelques liens sympatoches :

J'ai un peu honte de ne découvrir ça que maintenant, ça a l'air d'être un sujet bien étudié et avec pas mal de littérature, certainement plus probante que les quelques liens du dessus…

  • # J'ai exactement ce problème avec mon langage

    Posté par (page perso) . Évalué à 10.

    Mon langage s'appelle de C-Cool, il suffit de décrire grossièrement le programme que tu veux obtenir en langage naturel. Par exemple, le code du compilateur est écrit en C-Cool et est le suivant : « Fais un compilateur pour un langage dont il me suffirait de décrire grossièrement le programme que je veux en langage naturel ».

    Reste juste le problème de bootstrap.

  • # coquille

    Posté par (page perso) . Évalué à 7.

    Il s'agit de « The Ken Thompson Hack »: Hack et non Attack.

    • [^] # Re: coquille

      Posté par . Évalué à -8.

      Oui, mais non…

      Le lien (proposé dans le journal) libellé Ken Thompson Attack mène effectivement à un document titré « The Ken Thompson Hack », ceci dit :

      1) dans ledit document, on peut lire :

      Ken wrote, In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode.

      2) si tu cherches le mot "attack" dans les slides de l'exposé sur GNU Mes, tu trouveras :

      2.1) au début de la section titrée « Reduced Binary Seed bootstrap: Why? » (diapo 12/64), la première justification libellée ainsi :

      Safety/Security
      Ken Thompson’s "Reflections on trusting trust" attack

      2.2) un peu plus bas, à la diapo 14/64, une citation de Bruce Schneier qui utilise l'expression « "Trusting trust" attack ».

      • [^] # Re: coquille

        Posté par (page perso) . Évalué à 8.

        Je ne sais pas si c'est de l'humour, mais tu as une sacré propension à justifier n'importe quoi en produisant une floppée de détails tout à fait inutiles (si c'est de l'humour, je m'excuse).

        Sinon je crois que ça fait référence (involontairement ?) à la Karger-Thompson Attack.

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

        • [^] # Re: coquille

          Posté par . Évalué à -10. Dernière modification le 05/02/19 à 06:03.

          Ce n'est pas de l'humour et tu serais bien inspiré de lire ce que j'ai écrit et de vérifier par les sources si tu le veux, puisque je les donne. Je n'ai justifié que des énoncés valides, certainement pas n'importe quoi !

          Au moins, à la différence des autres personnes qui ont cliqué sur "inutile", tu t'es donné ici la peine d'exprimer ton point de vue et de proposer une explication alternative à l'usage du mot attack, ce qui m'a donné l'occasion d'approfondir sans invalider mon énoncé précédent.

          A) Je reprends ce que j'énonçais et que je maintiens :

          • Ken Thompson parlait lui-même d'attaque ; j'ai cité ses propos dans mon commentaire plus haut et je précise qu'ils sont tirés de son papier titré « Reflections On Trusting Trust » (cf. source, page 3/3, en haut de la colonne de droite, à partir de la 5e ligne ; la source de ce document qui est proposée au début du texte accessible par le lien (proposé dans le journal) libellé Ken Thompson Attack n'est actuellement pas valide, le serveur ne répondant pas) ;
          • Jan Nieuwenhuizen, l'auteur du diaporama et de la présentation associée, fondateur du projet GNU Mes (source), utilise le mot attaque en le rattachant aux travaux de Thompson (je répète l'expression qu'il utilise : « Ken Thompson’s "Reflections on trusting trust" attack ») ;
          • dans son diaporama, Jan cite Bruce Schneier utilisant l'expression « "Trusting trust" attack ».

          B) En considérant le lien que tu proposes (Karger-Thompson Attack), je vois ceci :

          • en titre de section, l'attaque est effectivement rattachée à Karger (Paul A. Karger) en plus de Thompson ;
          • la première entrée de la liste à puces mène à un document PDF exposant la participation de Paul A. Karger (avec Roger R. Schell) à une analyse de vulnérabilité expliquant l'attaque sur le système d'exploitation Multics, analyse publiée en 1974 par l'US Air Force, soit antérieurement à la publication de Ken Thompson qui date de 1984 ;
          • ceci étant, en revenant à la liste à puces, parmi les cinq occurrences du mot attack dans la section, il y en a deux qui sont enrobées dans l'expression « thompson attack demo ».

          C) Sur le même Wiki que tu as cité, on trouve une seule autre occurrence de « Karger » (par une recherche interne au wiki), cf. la page titrée The Semantics Assignment Problem (lien pointant directement vers la section Trusting Trust) où l'on peut lire (le gras est de moi) :

          The most striking and well known example of this was Thompson's "trusting trust" attack (1984). He explained that it was possible to put a malicious backdoor into the binary of a compiler that would persist even if you recompile the compiler from completely clean unmodified sources. See also Karger & Schell (1974).

          Conclusions :

          • j'avais parfaitement raison de soutenir la validité de l'expression « Ken Thompson Attack » au titre de l'usage courant, y compris par des experts du domaine (par exemple, Jan Nieuwenhuizen, fondateur du projet GNU Mes, utilise l'expression « Ken Thompson’s "Reflections on trusting trust" attack ») ;
          • d'autres expressions sont utilisées, comme « "Trusting trust" attack » (Bruce Schneier), ce qui renvoie au papier de Ken Thompson sans le citer ;
          • par ton lien, tu as éclairé la validité de l'expression « Karger-Thompson Attack » et l'antériorité des travaux de Karger (et de Schell) ;
          • si on voulait créditer correctement les auteurs, on pourrait avantageusement utiliser l'expression « Karger-Schell-Thompson Attack »…

          Par curiosité, j'ai mis cette dernière expression dans un moteur de recherche (non encadrée par des guillemets), ce qui me renvoie notamment ceci :

          Google ne trouve aucune occurrence de « Karger-Schell-Thompson Attack » ni de « Karger Schell Thompson Attack » (la même sans les tirets).

          • [^] # Re: coquille

            Posté par . Évalué à -10.

            [ « Reflections On Trusting Trust » de Ken Thompson — coquilles, voire coquillages… ]

            Le sujet de ce fil étant "coquille", j'en propose ci-après quelques unes que j'avais relevées cet été dans le papier de Ken Thompson de 1984, titré « Reflections On Trusting Trust ».

            Le papier aborde la question de l'injection d'une porte dérobée — par un compilateur malveillant — dans un fichier exécutable résultant de la compilation d'un fichier login.c qui, lui, est intègre (ne comprend pas de malveillance). Cette injection se fait via la reconnaissance d'un motif significatif dans le code source de login.c. Par extension, Ken Thompson met en garde contre le risque d'injection de code malveillant par un compilateur malveillant dans tout programme qu'il compile, y compris un compilateur.

            [ Coquilles mineures ]

            Je passe rapidement sur des erreurs mineures de présentation dans le papier : les libellés "Fig 2.1" et "Fig 2.2" sont inversés ; les figures 2.1, 2.2, 2.3 sont dans la section "Stage III" alors qu'elles devraient être dans la section "Stage II".

            [ Coquillage… ]

            En développant son propos, Ken Thompson intègre un exposé concernant l'écriture d'un programme tel qu'une fois compilé, il soit capable de produire en sortie (à l'écran) son propre code source.

            Je suppose que s'il passe par cette étape, c'est pour justifier la possibilité, pour un compilateur malveillant, d'injecter sa malveillance en tant que code source ajouté au code source légitime qu'il compile. Bien que son propos manque d'articulation logique, je pense qu'on peut légitimement inférer ce que je viens de supposer.

            Il prétend formuler une proposition d'un tel programme en C avec le code source de la figure 1, un programme qui prétendument sache afficher le contenu d'une variable textuelle devant contenir tout le code source.

            En fait, ce que propose Ken à la figure 1, c'est un programme qui, une fois compilé et exécuté, produit en sortie le code source des instructions, mais sans la définition de la variable, ou plutôt avec en tête la toute fin de la définition de la variable (tabulation, 0, retour à la ligne, accolade fermante, point-virgule, deux retour à la ligne, '/', '*' …) bref, son code une fois compilé produit en sortie un code source qui ne pourrait même pas être compilé !

            [ Une première réflexion sur le concept de programme auto-reproducteur ]

            En première approche, j'ai estimé qu'un programme tel que celui présenté dans la figure 1, même corrigé, ne peut pas produire en sortie son propre code source, celui-ci étant prétendument stocké dans une variable de type chaîne de caractère (ou tableau de caractères), c'est à dire sans le support d'un fichier externe.

            Considérant l'hypothèse d'un programme tout bête sortant vers l'écran le contenu d'une variable textuelle contenant le code source dudit programme, j'ai trouvé un problème : celui de stocker dans ladite variable textuelle tout le texte du code source, y compris la définition de cette variable.

            Cela m'a semble être un problème de régression à l'infini que j'expose ci-dessous :

            • En effet, la variable textuelle — supposons-la définie en premier dans le programme, en tant que variable globale, comme c'est le cas de la Fig. 1 — devrait contenir le texte du code source dans sa partie définition de fonctions et appels de fonctions, c'est à dire les instructions à exécuter (concrètement : produire en sortie le contenu de la variable textuelle). J'appelle étape 1 cette étape de remplissage de cette variable textuelle.
            • Cependant, elle devrait également contenir le texte de la définition de cette même variable (pour pouvoir aussi produire en sortie cette définition de la variable), ce qui mène à ajouter dans la variable textuelle — avant le texte des instructions à exécuter, inséré à l'étape 1 — le texte correspondant à la définition déjà établie de cette variable (c'est à dire le texte des fameuses instructions à exécuter, agrémenté du sucre syntaxique nécessaire à son insertion dans la variable textuelle), ce qui mène à agrandir le code source de notre programme avec une variable textuelle enrichie. C'est l'étape 2.
            • La variable textuelle enrichie devrait alors, du coup, également contenir le texte permettant ensuite de produire en sortie le contenu précédemment enrichi, ce qui nécessite d'ajouter encore du contenu à la variable textuelle, en tête de celle-ci, texte qui, une fois produit en sortie à l'exécution du programme, exprime le contenu enrichi à l'étape 2. Là on est à l'étape 3
            • En étape 4, il faut encore ajouter du contenu à la variable textuelle pour pouvoir produire en sortie, à l'exécution du programme, le code source enrichi à l'étape 3.
            • Et ainsi de suite, dans une régression à l'infini.

            J'ai alors estimé qu'un contournement des contraintes du défi est possible en injectant dans le fichier exécutable du programme — c'est à dire après compilation — le texte du code source du programme. Cette solution permet d'avoir un programme qui sait afficher son propre code source. Cependant, le processus ne fonctionnera qu'une fois : le code source une fois affiché à l'exécution dudit programme, s'il est utilisé en entrée d'un compilateur, ne permettra pas de produire un programme sachant lui-même afficher son propre code source (pour arriver à ce qu'il le puisse, il faudrait injecter à nouveau le texte du code source après compilation du code source).

            J'ai envisagé un autre contournement au défi : écrire un programme qui affiche le contenu d'un fichier (contenant le même code source du programme). Une fois compilé et exécuté, il affiche le contenu du fichier. Ce contenu est l'exact code source du programme, il peut à son tour être compilé et exécuté. Si le fichier tiers reste disponible pour cette nouvelle instance du programme, la nouvelle instance pourra être exécutée et afficher le contenu du fichier…

            Tout ceci étant exprimé, est-il impératif d'avoir une solution viable au défi pour que l'exposé de Ken Thomson tienne la route par ailleurs ? Ma réponse est non.

            [ Un véritable programme auto-reproducteur — un quine ]

            L'article Quine (informatique) commence ainsi :

            Un quine (ou programme autoreproducteur, self-reproducing en anglais) est un programme informatique (non vide) qui imprime son propre code source. L'opération qui consiste à ouvrir le fichier source et à l'afficher est considérée comme une tricherie. Plus généralement, un programme qui utilise une quelconque entrée de données ne peut être considéré comme un quine valide. Dans beaucoup de langages de programmation, un quine est une variante de la commande suivante :

            Recopier puis recopier entre guillemets la phrase « Recopier puis recopier entre guillemets la phrase »

            Note : la page anglophone de Wikipédia sur le même sujet est plus courte, la voici : Quine (computing).

            • On trouve ici un quine en C, très minimaliste, astucieux et subtil (je m'épargne ici l'explication) :
            main(a){printf(a="main(a){printf(a=%c%s%c,34,a,34);}",34,a,34);}
            • J'ai apprécié le 2e exemple proposé dans cette page (lien menant directement à la bonne position dans la page), dans lequel le tableau de données est lu deux fois et interprété différemment les deux fois. C'est autre chose et c'est une solution bien astucieuse.
            • [^] # Re: coquille

              Posté par . Évalué à -10.

              Eh ben… (0/-7) à cette heure pour mes deux commentaires ci-dessus… Je vais sérieusement envisager d'arrêter de donner de la confiture aux cochons…

              • [^] # Re: coquille

                Posté par . Évalué à 10.

                Pitié oui, s'il-te-plait.

                En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

                • [^] # Re: coquille

                  Posté par . Évalué à -10.

                  Allons, gUI, je ne peux pas décemment te compter parmi les cochons, ce serait irrespectueux pour eux.

              • [^] # Re: coquille

                Posté par (page perso) . Évalué à 10.

                Je vais sérieusement envisager d'arrêter de donner de la confiture aux cochons…

                Ta confiture semble faite avec beaucoup d'attention et de bonne volonté, mais elle est immangeable.
                Pourtant sur ce site beaucoup sont dotés d'un solide appétit d'informations, de points de vues, etc, le tout avec un estomac entraîné à absorber des choses pas évidentes.

                Tes textes sont bardés de trucs dont on ne comprend pas l'utilité, ils sont longs pour expliquer un truc qui se fait en 5 phrases, et tu en rajoutes dans un message supplémentaire, puis encore un message, et encore un autre.
                Ça fait de centaines de lignes pour expliquer un truc basique --> tu as un soucis de vision, d'expression, de synthèse, de je ne sais quoi, mais c'est un GROS soucis.

                • [^] # Re: coquille

                  Posté par . Évalué à -10.

                  Vraiment immangeable ? Comment expliques-tu les quelques points en positif qui apparaissent ? De la complaisance ? Allons ! Je ne fais rien pour obtenir les faveurs de cireurs de pompe. Par contre, au fil des années, ayant souvent eu droit à une tripotée d'ignorants, d'adversaires politiques qui ne supportaient pas mes prises de positions, voire de décérébrés qui fustigeaient mes propos, typiquement au titre qu'ils étaient fumeux, bien qu'ils ne le fussent pas systématiquement et loin de là, j'ai tendance par déformation induite à bien appuyer sur les sources et à sortir la batterie de contrôles du langage naturel, pour désambiguïser, ce qui peut alourdir le propos (sans le rendre immangeable, perfection syntaxique et lexicale oblige), mais on n'a rien sans rien. Du coup, sauf exception, il ne reste que l'attaque sur la forme pour critiquer ma prose, quasiment rien sur le fond (et quand la critique est recevable, je la reconnais).

                  Note que je ne critique pas ton attitude, je ne t'associe à aucune des trois catégories précitées. Je t'explique la déformation induite par l'historique et corrige ton allégation du caractère radicalement immangeable de ma prose. Pour les autres, que chacun se sente libre de se reconnaitre dans l'une ou l'autre catégorie, ou au-delà !

                  • [^] # Re: coquille

                    Posté par (page perso) . Évalué à 6.

                    Les critiques de ton commentaires sont très bien notées. Tes commentaires plongent dans les abîmes des notes. Et tu continues de réfuter toutes les critiques. Jamais de remise en cause, c'est décourageant.
                    En plus tu prétend nous expliquer pourquoi nous te notons mal, alors qu'on te lit depuis des années, qu'on est parfaitement au courant de ton histoire…

                    Quant au fond, ta abordes souvent des sujets techniques, que tu semble peu connaître. Tu ne te rends pas bien compte que tu as affaire à des professionnels en activité. Car nos métiers de programmeur, d'administrateur système, d'ingénieur réseau, etc. ça se pratique, lire des docs ne suffit pas.

                    Tu as déjà vu les commentaires de Zenitram ? il sont abondant, comme les tiens. Zenitram est spécialiste dans un domaine. Il parle rarement technique en dehors.

                    Enfin, les qq notes positives s'expliquent facilement : sur la quantité invraisemblable de tes messages, il y en a qui sont intéressant — et courts.

                    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

                    • [^] # Re: coquille

                      Posté par . Évalué à -10.

                      Tu restes à la surface, sans critiquer sur le fond. C'est pauvre en esprit.

                      Je n'ai aucun mal à comprendre que tu me notes généralement mal, étant donné que tu t'es montré capable d'écrire ceci, dont je cite le passage le plus stupéfiant à mes yeux : « Ton karma est négatif à cause de tes interventions ineptes sur l'informatique, de ta logorhée assez délirante sur Zino et de tes propos d'extrême-droite. »

                      Je m'abstiendrai de te présenter l'ensemble de mes interventions sensées et pertinentes sur l'informatique, tu refuserais de les considérer. Je m'abstiendrai de t'expliquer en quoi Zin[o|d] n'est pas un projet délirant, même s'il est ambitieux, tu n'en as strictement rien à faire. Je m'abstiendrai tout autant de te montrer en quoi je ne suis pas d'extrême droite, puisque tu es complètement borné dans tes convictions.

                      Continue à croire qu'avec la force du nombre qui me "moinse" à l'occasion, marginalement désormais (la kabbale a fonctionné un temps, mais ça s'épuise…), vient la légitimité du "moinsage". Continue à me renvoyer la nécessité selon toi que je me remette en cause (comme si je ne le faisais jamais…), en vaillant bien toi-même à ne pas aller au bout de la démarche de remise en cause que tu as entamée (je t'observe du coin de l'oeil), c'est sûr que ça t'avancera…

                      • [^] # Re: coquille

                        Posté par (page perso) . Évalué à 4.

                        Mais arrête de te la jouer bon sang! ça fait des années que les gens te le demandent.

                        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

                        • [^] # Re: coquille

                          Posté par . Évalué à -10.

                          Me la jouer ? Jouer quoi, à te reprendre quand tu t'égares, nonobstant ton statut de modérateur ? Tu te la joues comment, quand tu écris plus haut que j'ai « une sacré propension à justifier n'importe quoi en produisant une floppée de détails tout à fait inutiles », en réaction à mon allégation largement sourcée et valide que l'expression Ken Thompson Attack est pertinente ?

                          Comme les gens aiment les figures d'autorité et que tu parais en avoir, ils te suivent comme des moutons, jusqu'à se rendre compte par eux-même en comptant les points, quand ils en ont l'opportunité et l'intelligence.

                          • [^] # Re: coquille

                            Posté par (page perso) . Évalué à 4.

                            mon allégation largement sourcée et valide que l'expression Ken Thompson Attack est pertinente ?

                            Ton assertion a été notée négativement bien avant mon commentaire. Elle peut-être sourcée, elle n'en a pas moins été invalidée par les autres.

                            Me la jouer ?

                            Tu te la joues à avoir toujours raison, comme le schtroumpf à lunette.

                            Bonne nuit.

                            "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

                            • [^] # Re: coquille

                              Posté par . Évalué à -7.

                              Ton assertion a été notée négativement bien avant mon commentaire. Elle peut-être sourcée, elle n'en a pas moins été invalidée par les autres.

                              Si tel est le cas, vous êtes plusieurs à avoir été dans l'égarement.

                              Tu te la joues à avoir toujours raison, comme le schtroumpf à lunette.

                              Je défends toujours ce que je tiens pour vérité, ce qui implique aussi de l'humilité lorsque je ne sais pas ou que je reconnais m'être trompé. Je ne me reconnais pas dans la figure du Schtroumpf à lunettes

                              Bonne nuit.

                              J'apprécie et te renvoie le souhait de bonne nuit.

                          • [^] # Re: coquille

                            Posté par . Évalué à 7.

                            Je ne comprends pas qu'un mec aussi brillant que toi n'arrive pas à nous comprendre. Entre deux "mêêê" et "grouik grouik" on utilise bien des mots en Français non ?

                            en réaction à mon allégation largement sourcée et valide

                            On ne te parle pas de la validité ni des sources, mais de l'allégation elle-même. LA FORME BORDEL, LA FORME !!!

                            Et en plus le mot allégation me semble bien mal utilisé ici (mon Gros Robert est plutôt de mon avis), puisque justement le propos est justifié.

                            En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

                  • [^] # Re: coquille

                    Posté par . Évalué à 9. Dernière modification le 05/02/19 à 22:27.

                    sans le rendre immangeable

                    Ton propos ne t'es pas destiné, tu n'as donc pas à le juger. "J'écris bien, ce sont les autres qui ne comprennent pas".

                    Quand j'écris un document et qu'on me fait une remarque (fond comme forme, c'est important), à 90% du temps ça fini par une modification du document, même si j'ai parfaitement raison sur le fond. Si la personne n'a pas compris ce que j'ai écris c'est de ma faute (par définition). Je propose donc une reformulation plus détaillée, plus directe ou moins ambiguë (selon).

                    Plutôt que de pester contre je ne sais quel complot contre toi (franchement, qu'est-ce qu'on s'en fiche de ta vie !) essaie de comprendre ce qu'on te dit. Ce que tu écris est généralement imbuvable, et transpire la vanité. Vrai ou faux, là n'est pas le problème, c'est le ressenti des gens, c'est comme ça. Si tu es si intelligent, tu devrais le comprendre aisément.

                    J'ai "pertinenté" moi-même pas mal de tes commentaires, ce n'est pas pour te faire plaisir, mais c'est bien parce qu'ils m'ont fait plaisirs : pertinents et agréables à lire.

                    Une bonne fois pour toutes, ce n'est pas toi qu'on note mal, c'est ton texte. Il est CHIANT À LIRE !

                    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

                    • [^] # Re: coquille

                      Posté par . Évalué à -7.

                      J'apprécie ton message. Je conçois que mes commentaires publiés plus haut qui ont de mauvaises notes soient chiants à lire.

                      Si la personne n'a pas compris ce que j'ai écris c'est de ma faute (par définition)

                      Je m'inscris en faux. Si ton lecteur ne t'a pas compris, c'est possiblement parce que

                      • tu ne t'es pas exprimé correctement :
                        • par manque de maîtrise de la langue ou par négligence (coquilles) ;
                        • par défaut d'univocité et de justesse (présence d'ambiguïté ; présence d'inférences invalides, par exemple un contre-sens, un paralogisme, etc.)
                        • par inadéquation aux connaissances de ton interlocuteur, lorsque tu le connais.
                      • il n'a pas le niveau auquel tu peux légitimement t'attendre :
                        • il manque de connaissance de la langue (vocabulaire, constructions syntaxiques) ;
                        • il manque de connaissance dans le domaine (j'envisage ici un milieu professionnel, ou plus généralement une relation sur la longue durée, permettant de connaître l'autre ; sur Linuxfr.org il y a tous les niveaux, c'est différent) ;

                      La vanité perçue, je l'assume en réaction aux propos de ZeroHeure que j'ai mis en évidence ici et en réaction aux notes négatives, alors que mes messages sont pertinents. Je conçois qu'ils semblent inutiles parce que chiants à lire pour certains, auquel cas j'invite ceux-là à passer leur chemin plutôt qu'à en juger la pertinence sans les lire et participer au vote.

                      Pourquoi cette invitation ? Parce que de telles notes négatives sont CHIANTES A VOIR, alors que l'effort de rédaction est là et que le fond est là, d'autant plus que ces messages pertinents pourraient plus favorablement attirer l'attention de lecteurs intéressés au sujet s'ils étaient mieux notés. Autrement dit, c'est injuste relativement à la qualité de ma production (je ne peux pas être en adéquation à toutes les attentes ; il y a un historique de kabbale indubitable qui m'a incité à sourcer et désambiguïser, je subis une déformation cognitive de par mon inclination à la désambiguïsation dans le cadre de mon intérêt pour le traitement automatisé du langage naturel [contrôlé ou non]), et c'est injuste relativement à l'intérêt accru que pourraient susciter ces messages s'ils étaient mieux notés.

                      Par exemple, mon commentaire d'analyse critique du papier « Reflections On Trusting Trust » de Ken Thompson revêt un certain intérêt pour les lecteurs intéressés par le présent journal. Qu'est-ce que c'est que cette note de merde ? A quel point faut-il être égaré pour oser noter ça négativement ? Encore une fois, si c'est chiant à lire et qu'on ne lit pas, alors que c'est rédigé correctement et que c'est le fruit de plusieurs heures d'étude, on passe son chemin mais on ne clique pas sur "inutile", ou alors c'est qu'on prend plaisir à faire chier ! Il se trouve que j'en connais sur Linuxfr.org qui prennent un tel plaisir assumé (salut Single…).

                      Autre exemple : ce commentaire de ta part, et l'action de "moinsage" qui va avec, comment l'expliques-tu ? Mon commentaire est immangeable (lourdeur du style) ? Tu sanctionnes le "PS" au titre qu'il est vaniteux ? Tu sanctionnes la vanité que tu perçois dans le corps du message ? Explique si tu veux bien, ça m'intéresse vraiment. Note que si tu n'avais pas écrit le commentaire auquel je réponds présentement, au vu du commentaire dont je viens de donner le lien, j'aurais entériné la conviction que tu es un bouffon, alors que là j'imagine simplement que le style te paraît lourd ou bien que tu sens de la vanité déplacée. Si le style te paraît lourd, je trouve incorrect que tu cliques sur "inutile".

                      Si tu sens une vanité déplacée dans le PS (là je ne parle pas du corps du message), essaie de prendre du recul sur ce que j'ai vécu sur ce site, une dizaine d'années de kabbale plus ou moins forcenée, de la mauvaise fois tellement réitérée, des attaques jusqu'à la déclaration d'intention de me "brûler" (ou "cramer", dans l'expression ambigüe à dessin "on va te cramer")… Si si, un commentaire émanant probablement d'un sioniste n'acceptant pas ma critique du sionisme d'alors, posté sous un commentaire de Benoît Sibaud, qui n'avait pas censuré ledit commentaire, ce que je peux comprendre au titre de la conscience qu'il peut légitimement avoir du niveau de risque qu'il y a à fâcher quelqu'un potentiellement proche de la LDJ…). J'en passe… T'avouerai-je qu'avec des décérébrés comme on en croise, je n'ai pas envie de côtoyer le moindre lecteur de Linuxfr.org dans la vie réelle, pour éviter d'être exposé au risque de tomber sur un anti-fa (c'est à dire un fasciste) de première bourre, tout disposé à en découdre physiquement, par exemple au titre que j'aurais fait des quenelles ou que je serais d'extrême droite (lol !) ?

                      Le niveau de bouffonnerie, de mauvaise foi et d'indécence que j'ai croisé ici (surtout au passé), s'il n'atteint pas ce qu'on peut rencontrer en moyenne dans la vie réelle, est déjà tel que les bras m'en sont tombés plus d'une fois.

                      • [^] # Re: coquille

                        Posté par . Évalué à -10.

                        Je rajoute un terme important en tant que dernière entrée de la liste à puces (c'est à dire dans la partie intitulée « [ton lecteur] n'a pas le niveau auquel tu peux légitimement t'attendre ») :

                        • il manque de capacité à raisonner correctement.

                        Un correspondant connaissant le sujet m'avait communiqué des statistiques comme quoi près de 100 % de la population fait des erreurs basiques de raisonnement.

                        • [^] # Re: coquille

                          Posté par . Évalué à 8.

                          En fait tu ne parles que à toi-même. Tu n'as rien à faire que les autres ne te comprennent pas.

                          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

                  • [^] # Re: coquille

                    Posté par . Évalué à 3. Dernière modification le 09/02/19 à 22:36.

                    Vraiment immangeable ? Comment expliques-tu les quelques points en positif qui apparaissent ? De la complaisance ? Allons !

                    Moi j'ai pertinenté le premier message parce que j'ai apprécié le travail de recherche et aussi que tes commentaires deviennent progressivement trés interessant avec un bon travail de documentation.

                    Mais tu pars souvent de travers. J'ai l'impression que tu prend les commentaires trop à coeur. Tu surréagis.

              • [^] # Re: coquille

                Posté par (page perso) . Évalué à 8. Dernière modification le 05/02/19 à 17:07.

                Si tu donnes à manger à tes cochons de la même façon que tu nous abreuves de tes logorrhées, les pauvres bêtes doivent être mortes étouffées sous des monceaux de nourriture avariée :( – personnellement j'ai du mal à associer ça à de la confiture.

                Cette page te permets de relire tous tes commentaires, il semblerait qu'il y a une certaine corrélation entre la longueur de tes interventions et leur note.

                La connaissance libre : https://zestedesavoir.com

              • [^] # Re: coquille

                Posté par . Évalué à 1. Dernière modification le 08/02/19 à 21:01.

                Tout aussi bonne que puisse être la confiture que tu nous sers, tu veux à chaque fois nous en servir un conteneur entier. Forcément, c'est l'indigestion !

                Tes pavés sont illisibles pour la population de decideurs pressés de DLFP qui préfèrent moinsser plutôt que se taper ta logorrhée.

                Si tu arrivais à synthétiser en quelques phrases, tout le monde s'en porterait mieux…

                • [^] # Re: coquille

                  Posté par . Évalué à -10. Dernière modification le 09/02/19 à 11:22.

                  Ton commentaire me semble assez pondéré et juste. Je trouve qu'il y a une petite exagération avec l'expression « à chaque fois » : je concède que ça s'est produit régulièrement, mais pas systématiquement.

                  Ayant démarré la semaine proche de 0 et finissant avec -182 de karma à cette heure — sans avoir publié de journal, s'il te plait… — je trouve que j'ai tout de même fait un très bon score.
                  Non, je ne suis pas encore sorti. Pourquoi ? ┬┴┬┴┤ ͜ʖ ͡°) ├┬┴┬┴.
                  Bon, j'ai perdu kantien en cours de route mais j'espère qu'il s'en remettra (☉_☉)

  • # Compiler un compilateur... Avec une version antérieure?

    Posté par . Évalué à 3.

    Je ne suis absolument pas expert dans ce domaine, mais on m'avait expliqué il y a de nombreuses années, qu'il n'était pas possible de compiler un compilateur avec une version précédente, tout simplement parce que le compilateur 'V-1' ne pouvait pas, par construction, comprendre les nouvelles instructions du compilateur 'V' et donc ne pouvait pas les compiler.

    Un expert du domaine pourrait-il confirmer (ou pas) en termes simples ce fait? :-)

    Note : C'est peut-être expliqué dans la présentation (que je n'ai pas encore regardé), donc mes excuses dans ce cas pour le bruit.

    Il n'y a pas de mauvais outils, il n'y a que de mauvais ouvriers

    • [^] # Re: Compiler un compilateur... Avec une version antérieure?

      Posté par (page perso) . Évalué à 10.

      Le code d'un compilateur n'a pas nécessairement besoin lui-même des instructions qu'il va interpréter. Il est d'ailleurs classique d'écrire un compilateur dans un langage qui n'a rien à voir avec le langage cible.

    • [^] # Re: Compiler un compilateur... Avec une version antérieure?

      Posté par . Évalué à 4.

      Par exemple, dans la présentation au Fosdem rapportée dans le présent journal, en décrivant GNU Mes, l'auteur de la présentation explique dans son diaporama (dès la 3e diapo, et il revient dessus par la suite) qu'il s'agit notamment d'un interpréteur Scheme écrit en 5000 lignes de code en langage C, ainsi que d'un compilateur C écrit en Scheme. La syntaxe du C n'est pas directement comprise par un interpréteur Scheme, pour autant l'interpréteur Scheme peut exécuter un programme (écrit en langage Scheme) qui sait prendre en entrée du code source C et le compiler pour produire en sortie un fichier exécutable.

      La phrase que tu rapportes est une grosse ineptie. Pour t'aider à le comprendre, tu peux consulter la section Langages de programmation Turing-complets (de l'article Wikipédia titré « Turing-complet »). Je t'en cite un extrait significatif :

      De même qu'un modèle de calcul, un langage informatique est dit Turing-complet s'il permet de représenter toutes les fonctions calculables au sens de Turing et Church (nonobstant la finitude de la mémoire des ordinateurs). […]

      Les langages de programmation usuels (C, Java…) sont Turing-complets car ils possèdent tous les ingrédients nécessaires à la simulation d'une machine de Turing universelle (compter, comparer, lire, écrire, etc.).

  • # Boostrap everything

    Posté par . Évalué à 6. Dernière modification le 04/02/19 à 14:57.

    Le wiki donné en référence est impressionnant, on y trouve des CPU, des compilateurs et des OS de taille minimale. Extrêmement éducatif je suppose, faudrait trouver le temps pour s'y pencher dessus.

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # Le big bang L'oeuf la poule Adent et Eve

    Posté par . Évalué à -3.

    C'est toujours le même problème :

    L'oeuf ou la poule
    Adent et Eve
    Le big Bang

    Pour plus de renseignement contacter le service correspondant à votre croyance / culture ( curé prêtre pasteur imam rabin shamane sorcier stade de foot etc … )

    Pour le compilateur C l'équivalent de dieu sous Unix c'est Ken Thompson et Dennis Richie avec le langage B
    Avec des Archanges comme Linux Thorvalds

    Je vous laisse le soin de nommer les anges déchus :)

    • [^] # Re: Le big bang L'oeuf la poule Adent et Eve

      Posté par . Évalué à 6.

      Avec des Archanges comme Linux Thorvalds

      Tu me copieras 100x "Linus Torvalds" :)

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Le big bang L'oeuf la poule Adent et Eve

      Posté par . Évalué à 4.

      Pour le compilateur C l'équivalent de dieu sous Unix c'est Ken Thompson et Dennis Richie avec le langage B

      Wikipedia n'est pas d'accord :

      Le langage de programmation B est un langage obsolète qui a représenté la transition entre BCPL et le langage C

      BCPL (Basic Combined Programming Language) est un langage de programmation créé par Martin Richards (en) de l'université de Cambridge (1966) et une réponse aux difficultés rencontrées avec son prédécesseur le Combined Programming Language (CPL) durant les années 1960. Ce langage fut décrit la première fois dans un journal au 1969 Spring Joint Computer Conference. Dennis Ritchie développa plus tard le C à partir du BCPL.

      CPL (Combined Programming Language) […] a été grandement influencé par l'ALGOL 60

      Et ainsi de suite. Cette page Wikipedia résume mieux l'Histoire qui "commence" comme ça :

      Pendant neuf mois entre 1842 et 1843, Ada Lovelace a traduit le mémoire du mathématicien italien Luigi Menabrea

      Tout est construit sur quelque chose d'existant, tes dieux ont ajouté des pierres à un édifice.

    • [^] # Re: Le big bang L'oeuf la poule Adent et Eve

      Posté par (page perso) . Évalué à 7.

      Quand les poules auront Adent.

  • # Vidéo de la présentation

    Posté par . Évalué à 1. Dernière modification le 04/02/19 à 17:06.

    Elle devrait apparaître ici dans la journée ou demain au plus tard, vu la vitesse à laquelle le répertoire se remplit.

    Le nom du fichier devrait comprendre des expressions tirées du titre de la présentation, à savoir « GNU Mes » puis (en sous-titre) « Reduced Binary Seed bootstrap for GNU Guix ».

    J'ai lu entièrement le diaporama, mais des explications orales complémentaires seraient bienvenues (même si je connaissais ce problème soulevé par Ken Thompson).

    • [^] # Re: Vidéo de la présentation

      Posté par . Évalué à -10. Dernière modification le 10/02/19 à 12:52.

      Le fichier espéré n'a pas été posté jusqu'à maintenant. A partir de l'analyse que je fais (cf. liste à puces ci-après), je m'attends à ce qu'il ne soit pas posté. Il se pourrait que l'enregistrement vidéo n'ai pas été fait, ou qu'il y ait eu un problème technique.

      Voici ce que j'observe :

      • l'exposé dont nous espérions la vidéo a été fait dans la salle K.4.201 ;
      • la page dédiée aux évènements FOSDEM 2019 qui ont été produits dans cette salle permet d'y dénombrer 28 évènements ;
      • le lien que je fournis au commentaire parent est une vue sur le répertoire des enregistrements vidéos captés dans cette salle ;
      • il contient 26 paires de fichiers (MP4 et Webm pour chaque évènement), soit 26 évènements sur les 28 qui se sont produits dans cette salle K.4.201 ;
      • il a été alimenté régulièrement entre le dimanche 3 février et le jeudi 7 février à 7h35 (pour rappel, les 2 jours du FOSDEM 2019 étaient les samedi 2 et dimanche 3 février) ;
      • depuis, et jusqu'à maintenant (dimanche 10 février à 12h47), aucun fichier n'a été ajouté dans le répertoire !
  • # Attaque par le compilateur

    Posté par . Évalué à 3.

    une justification au délire, qui dit en gros que si on compromet le compilo, on compromet tout ce qu'il produit (c'est la Ken Thompson Attack)

    Ça demande à ce que la propriété soit maintenu dans les compilateurs générés. Hors de cas totalement triviaux qui sont pas forcément très compliqué à déceler, ça me paraît assez complexe.

    • [^] # Re: Attaque par le compilateur

      Posté par . Évalué à 3.

      Je pense que c'est plus une expérience de pensée qu'un risque réel, pour plein de raisons. Déja, il faut que le compilateur compromis ait été introduit il y a très longtemps, au début de la chaine, puisque la compromission ne peut plus être introduite en cours de route. D'autre part, il ne semble pas très compliqué de «nettoyer» une distribution une fois que la faille est identifiée (il suffit de compiler gcc avec un autre compilateur du marché, puis de recompiler gcc avec lui-même, et de recompiler tous les éléments du système : en quelques heures, pouf, la faille introduite 20 ans auparavant n'existe plus. Ça fait beaucoup d'efforts pour pas grand chose!

      Par contre, ce qui est intéressant, c'est la question autour de l'idée de prouver que les compilateurs ne sont pas compromis de cette manière. Si on analyse le binaire du compilo avec un outil compilé, qui prouve que le compilateur n'a pas fait en sorte que l'éditeur de binaire ne cache pas les bouts compromettants? Et si on utilise un autre compilo du marché, qui prouve qu'il n'a pas non plus lui aussi été affecté? C'est tellement improbable que ça ne représente pas un risque réel, mais c'est plus une question philosophique, et une attaque sur le principe souvent répété de la sûreté des logiciels libres par l'inspection du code.

      • [^] # Re: Attaque par le compilateur

        Posté par . Évalué à -10.

        arnaudus, je crois que tu es loin du compte. D'une part, le problème est bien théorique, mais bien plus grave (je vais expliquer en quoi) que tu ne l'envisages ici, d'autre part, tu n'as aucune garantie de l'absence de passage de la théorie à la pratique et le seul nettoyage du code tel que tu l'évoques dans ton premier paragraphe ne règle pas tout, tu vas le découvrir ci-dessous.

        Le problème est tellement sérieux et profond qu'il convient de réfuter la garantie de sureté de la seule procédure d'amorçage d'une graine binaire (1), tant que tu n'as pas du matériel intégralement en sources ouvertes et contrôlé (contrôlé, c'est à dire avec des audits redondants sur les spécifications intégrales, avec preuves formelles de code autant que possible, supervision de la fabrication et de la distribution).

        Et pourquoi faut-il réfuter la pertinence de cette procédure réputée valide tant qu'il n'y a pas la condition que j'ai ajoutée ?

        Non pas parce qu'il y aurait de la stéganographie — un contenu informatif (malveillant) non décelable — au niveau du code binaire (2), car si toute la chaîne de production des binaires est maitrisée depuis l'amorce d'un assembleur minimaliste écrit en binaire, alors la production d'une suite d'instructions binaires est toujours déterministe et sous contrôle du programmeur (si tant est qu'il vérifie la production (de tout binaire) faisant intervenir le… matériel).

        Alors, pourquoi ?

        Parce qu'il y a, ou au moins il y aura (à terme, quand les IA auront suffisamment évolué), la possibilité qu'un matériel malveillant analyse in situ (sans nécessité d'un calcul déporté) et dynamiquement le code qui s'exécute (ou bien a vocation à s'exécuter, car l'analyse peut porter sur tout le code exécutable d'un logiciel avant que chaque instruction en soit exécutée), pour en modifier le résultat au cas par cas. Dans cette configuration, peu importe que tous les fichiers binaires exécutables soient intègres, car ce qui en résulte à l'exécution est sous le contrôle d'un matériel potentiellement malveillant. Ce risque implique la nécessité d'une vérification du résultat de toute opération programmée (pas seulement une vérification définitive de l'intégrité de tous les binaires exécutables)…

        Cette modification au cas par cas peut éventuellement être sous le contrôle d'une intervention à distance, si le lien réseau est disponible et si le piratage est acquis… Par exemple, un matériel malveillant peut attendre une trame déterminée (passant pour anodine à l'analyse) pour déclencher une procédure malveillante.

        (1) La procédure d'amorçage d'une graine binaire — en anglais Bootstrap Binary seed — consiste en l'amorçage de l'écriture d'un compilateur par l'écriture d'un assembleur minimaliste directement en binaire, pour s'assurer in fine que le compilateur n'a pas de code malveillant injecté à l'insu du programmeur.

        (2) une partie de la sémantique d'un code malveillant — paraissant intègre à l'analyse détaillée par rétro-ingénierie— peut n'être connue que des concepteurs du matériel sur lequel il est exécuté ; il suffit pour cela de s'assurer de la présence de motifs (malveillants) de suites d'instructions qui soient signifiants pour le processeur (l'amenant à faire un traitement malveillant), sans que le traitement induit par la présence de ces motifs ne soit documenté.


        PS : le long texte ci-dessus, bien qu'a priori parfait du point de vue lexical, syntaxique, et de la détermination univoque du sens, n'a pas vocation à être lu par tous : les cochons auront cliqué sur "inutile" avant d'avoir lu deux lignes. Parmi eux, je compte les ignorants qui s'ignorent, les adversaires politiques qui n'ont pas supporté mes prises de positions antérieures, et les décérébrés considérant quasiment tous mes propos comment étant fumeux par principe.

        • [^] # Re: Attaque par le compilateur

          Posté par . Évalué à 10. Dernière modification le 05/02/19 à 23:06.

          les cochons auront cliqué sur "inutile"

          fait !

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: Attaque par le compilateur

          Posté par . Évalué à -8. Dernière modification le 06/02/19 à 07:42.

          Pour ceux qui goûteraient à l'importance stratégique du commentaire parent, cette équation en langage naturel, dans la lutte contre les dérives malveillantes (notamment de nature oligarchique), mais qui ne percevraient pas la portée du concept de contrôle du matériel en sources ouvertes, je renvoie à cet autre commentaire (je précise que dans son contexte — accessible en cliquant sur le # dans son en-tête — il comprend des commentaires enfants qui affinent un peu le propos, notamment celui-ci).

        • [^] # Re: Attaque par le compilateur

          Posté par . Évalué à 7. Dernière modification le 06/02/19 à 08:54.

          d'autre part, tu n'as aucune garantie de l'absence de passage de la théorie à la pratique et le seul nettoyage du code tel que tu l'évoques dans ton premier paragraphe ne règle pas tout, tu vas le découvrir ci-dessous.

          Sauf que tu parles d'un problème tellement différent que la discussion est carrément hors sujet, je trouve. Le problème que tu évoques n'a rien à voir avec le compilateur ; si tu veux juste dire que la confiance dans le compilateur n'est pas suffisante pour avoir confiance dans un ordinateur, alors oui, c'est trivialement vrai. Mais le nombre d'exemples qui pourraient poser de tels problèmes est quasiment illimité (noyau, bibliothèques externes, drivers, matériel, routeurs…).

          Sur le fond, les problèmes que tu évoques sont théoriquement possibles, mais ils sont détectables, et c'est ça qui est rassurant, dans une certaine mesure. Si un binaire, une fois exécuté, n'a pas le même comportement sur deux machines différentes (il envoie une trame réseau chiffrée quand il est exécuté sur une machine et pas sur l'autre, par exemple), alors tu as identifié un vrai problème. Le constructeur prend quand même un risque majeur en introduisant, de cette manière, «en dur», des protocoles espions. Il pourrait du jour au lendemain se faire interdire de vente, par exemple. D'autre part, un tel truc «en dur» dans le matériel peut difficilement être mis à jour, et il ne peut qu'être très sensible à toute modification de l'environnement logiciel. Enfin, il semble tellement plus facile d'introduire des backdoors dans le matériel que d'analyser les binaires et d'y introduire des instructions supplémentaires que ça me semble plutôt relever de la science fiction.

          Autrement, rien à voir, mais quand tu te retrouves à -50 avec 4 commentaires, c'est peut-être un signe qu'il est l'heure de prendre tes médicaments.

          • [^] # Re: Attaque par le compilateur

            Posté par . Évalué à -8. Dernière modification le 06/02/19 à 11:18.

            Je te donne raison sur le point que j'ai débordé du sujet, bien que le lien soit très fort :

            • d'un côté la prétention légitime (et accessible) à garantir l'intégrité du code binaire exécutable produit par compilation, au prix d'une procédure comportant l'amorçage d'une graine binaire exécutable garantie non malveillante intrinsèquement ;
            • de l'autre la reconnaissance que cette procédure ne suffit pas à garantir l'intégrité du code réellement exécuté (parce qu'il peut y avoir des modifications dynamiques et ponctuelles effectuées par du matériel malveillant, non nécessairement perceptibles à l'exécution, ou bien nécessairement perceptibles au prix d'un contrôle dynamique systématique qui peut être très laborieux à mettre en oeuvre).

            Sur la question de l'identification du comportement malveillant, si celui-là est déterminé in situ (sans nécessité d'échange réseau) et au cas par cas (c'est à dire ponctuellement, avec un caractère systématique limité), il peut être très difficile à détecter.

            Si une trame réseau est échangée, il peut y avoir stéganographie plutôt que du seul chiffrement, auquel cas la détection peut être très difficile. Dans ce cas, il faut voir qu'un large motif de bits peut porter un sens secret (voire jusqu'à plusieurs motifs successifs pour un signifié unitaire), connu seulement de l'émetteur distant et de la machine locale malveillante. Pour que le matériel malveillant puisse déterminer avec un haut degré de fiabilité si une trame reçue comporte un message stéganographique (et que ce n'est pas seulement le fruit de l'aléa), une procédure d'établissement d'une liaison peut être engagée, avec un jeu de questions/réponses (qui peut s'étaler dans le temps…). Intercepter ces messages et les identifier comme malveillants peut être très difficile, selon le contexte du piratage.

            un tel truc «en dur» dans le matériel peut difficilement être mis à jour, et il ne peut qu'être très sensible à toute modification de l'environnement logiciel.

            Le truc n'a pas à être nécessairement « en dur ». La partie malveillante d'un tel matériel peut comporter du micro-logiciel, éventuellement mis à jour lors d'un échange stéganographique s'il y a un lien réseau. La sensibilité à toute modification de l'environnement logiciel est plus ou moins nécessaire selon le périmètre de la malveillance. Il se peut qu'une sensibilité maximale soit nécessitée par conception d'une malveillance généraliste.

            Enfin, il semble tellement plus facile d'introduire des backdoors dans le matériel que d'analyser les binaires et d'y introduire des instructions supplémentaires que ça me semble plutôt relever de la science fiction.

            Dans la configuration d'une malveillance déclenchée au cas par cas, c'est à dire éventuellement très ponctuellement, par analyse in situ ne nécessitant pas d'échange réseau, on peut parler de fonction malveillante, éventuellement de cheval de Troie (injecté à la fabrication ou postérieurement), mais pas de porte dérobée.

            Dans la configuration d'une telle malveillance impliquant un échange réseau, il y a les deux : cheval de Troie et porte dérobée.

            Quand il y a porte dérobée, il y a au moins accès illégitime en lecture, voire y compris en écriture, ce qui implique toujours une logique malveillante sur la cible (câblée dans le silicium et/ou logicielle) ou bien une faille exploitée. Si la logique malveillante est très élaborée, elle peut comporter une IA. Ainsi, le cas d'une IA in situ, capable de modifier le flux des instructions légitimes d'une cible (par des décisions au moins pour partie autonomes), constitue simplement une extension au concept de porte dérobée.

            Il est vrai qu'une telle extension est plus compliquée à concevoir qu'une simple porte dérobée.

            Cependant, le coût peut en valoir la peine, et sur le temps long, le développement des IA peut faciliter la tache.

            Par exemple, considère le cas idéal — en matière de sécurité — du développement d'un fabriquant industriel d'ordinateur, comportant la partie gravure du silicium, sous contrôle communautaire :

            • l'installation matérielle/logicielle pourrait impliquer, dans un premier temps, non pas une procédure très pure d'amorçage depuis une graine binaire et une graine matérielle sous contrôle (permettant de concevoir et fabriquer les outils eux-mêmes de fabrication de l'ordinateur, avec un contrôle systématique, pour garantir leur intégrité), mais l'acquisition du matériel de fabrication propriétaire (sans sources ouvertes et non contrôlé), notamment du matériel pour graver le silicium ;
            • suppose maintenant que la partie fabrication de l'usine soit sans échange réseau direct non contrôlé avec l'extérieur, et même sous cage Faraday pour éviter l'exploitation d'une quelconque porte dérobée dans ce matériel via des échanges électro-magnétiques illégitimes ;
            • imagine que le matériel de gravure comporte une IA capable d'analyser le schéma à graver sur le silicium pour y injecter des fonctions malveillantes les plus furtives possibles (injection possiblement ponctuelle, plutôt que systématique, pour augmenter la furtivité) — il existe de telles technologies de fonctions matérielles malveillantes très furtives :
              • par exemple, des chevaux de Troie réalisés au niveau du dopage du substrat en silicium des circuits intégrés (par inversion intelligente du dopage N et P), cf. ce commentaire et les commentaires enfants ;
              • autre exemple avec l'attaque matérielle furtive à base de condensateurs au sein de la puce, permettant une escalade de privilège contrôlable à distance, cf. ce commentaire et les commentaires enfants.
            • même s'il est possible de détecter la présence de ces deux exemples de malveillances matérielles furtives sans processus destructif du silicium, l'opération augmente le coût de production, diminuant l'attractivité de la production concernée…

            Autrement, rien à voir, mais quand tu te retrouves à -50 avec 4 commentaires, c'est peut-être un signe qu'il est l'heure de prendre tes médicaments.

            Je ne me préoccupe pas nécessairement des notes largement négatives. L'attitude sérieuse que tu as manifestée ici par ton commentaire n'est visiblement pas la portée de chacun.

        • [^] # Re: Attaque par le compilateur

          Posté par (page perso) . Évalué à 8.

          Tout ton problème est dans l'inadéquation entre ton ressenti quant à la qualité de tes textes :

          le long texte ci-dessus, bien qu'a priori parfait du point de vue lexical, syntaxique, et de la détermination univoque du sens,

          Et le fait qu'ils sont très loin de la perfection. En particulier parce qu'on y trouve encore des phrases beaucoup trop longues et complexes, comme par exemple :

          Non pas parce qu'il y aurait de la stéganographie — un contenu informatif (malveillant) non décelable — au niveau du code binaire (2), car si toute la chaîne de production des binaires est maitrisée depuis l'amorce d'un assembleur minimaliste écrit en binaire, alors la production d'une suite d'instructions binaires est toujours déterministe et sous contrôle du programmeur (si tant est qu'il vérifie la production (de tout binaire) faisant intervenir le… matériel).

          Exemple qui contient quand même deux fois un double niveau d'inclusion (incise dans une incise) et un renvoi externe (lui-même trop long).

          C'est un problème soulevé depuis plusieurs mois et que tu ne sembles pas décidé à prendre en considération.

          Ne t'étonnes donc pas de l'accueil reçu par tes commentaires.

          La connaissance libre : https://zestedesavoir.com

          • [^] # Re: Attaque par le compilateur

            Posté par . Évalué à 6. Dernière modification le 06/02/19 à 15:23.

            Tout ton problème est dans l'inadéquation entre ton ressenti quant à la qualité de tes textes :

            Est-ce quelqu'un qui s'y connait un peu ne pourrait pas essayer de mettre un terme technique sur le problème de SamWang (manque total de lucidité sur son incapacité à communiquer ses idées de manière intelligible et logique)? Ça permettrait d'éviter les injures et d'être un peu plus constructifs.

            D'un autre côté, si SamWang tu es suivi pour un problème médical, ça ne coûte rien d'en glisser un mot (sans forcément donner des détails dont on se moque); d'expérience les gens sont bien plus bienveillants quand ils savent pourquoi leur interlocuteur ne respecte pas les codes sociaux. Dans tous les cas, il semble que tu n'es pas «cablé» comme le commun des mortels, ce qui fait qu'un texte qui te semble clair, aéré, et logique, nous semble confus, jargonnant, et maladroit. Mépriser tes interlocuteurs n'arrange pas ton cas, puisqu'il est évident pour tout le monde que le problème vient de toi. L'art de la communication, c'est avant tout l'humilité de faire l'effort de passer un message clair, surtout si en face on n'a rien demandé.

            Quand je contribuais à Wikipédia, j'ai dû gérer à plusieurs occasions ce genre de situations, et c'est très compliqué, parce que malgré tous les efforts faits des deux côtés, les contributions de la personne "dyscommunicante" ne sont pas constructives. Souvent, le dialogue et la participation à un projet collectif entrent dans une démarche thérapeutique dans l'esprit du contributeur, mais cette démarche finit par être contre-productive (exclusion, sentiment de paranoïa, tensions chez les contributeurs réguliers, dégradation de la qualité du projet parce qu'on s'est «forcés» à accepter quelques contributions de mauvaise qualité, etc).

            • [^] # Re: Attaque par le compilateur

              Posté par . Évalué à -7. Dernière modification le 06/02/19 à 16:13.

              Merci de ton attention. Il se trouve qu'avant de voir ton commentaire, je rédigeais une reformulation du passage critiqué par SpaceFox.

            • [^] # Re: Attaque par le compilateur

              Posté par (page perso) . Évalué à 2.

              Ça ressemble à de la logorrhée (terme qui a une vraie signification médicale) mais à l'écrit. Il semblerait que ce soit plus souvent classifié comme un symptôme d'autre chose plus que comme une maladie à part entière.

              La connaissance libre : https://zestedesavoir.com

            • [^] # Proposition pour corriger le problème de l'inadéquation d'un texte à un lectorat

              Posté par . Évalué à -10. Dernière modification le 07/02/19 à 10:44.

              Je formule une proposition pour corriger le problème de l'inadéquation d'un texte à un lectorat, y compris un lectorat hétérogène, y compris si la distribution des compétences n'est pas connue d'avance.

              Note : Le texte est un peu long et le lecteur pourra librement en déduire que je suis malade ou simplement atteint de logorrhée ;)

              [ Préambule ]

              Le contributeur a une responsabilité partielle dans la réceptivité du lecteur. Sa contribution peut présenter des défauts :

              • des expressions maladroites par manque de maîtrise de la langue ;
              • des coquilles par négligence ;
              • des lourdeurs de style (ex. : phrases trop longues, multiplicité de niveaux d'inclusion (incise dans une incise)) ;
              • des défauts de clarté (notamment par ambiguïté) et de justesse (présence d'inférences invalides, par exemple un contre-sens, un paralogisme, etc.) ;
              • une inadéquation aux connaissances du lecteur, lorsqu'il est connu ; dans le cas d'un lectorat, si la distribution des compétences est déterminée assez précisément, un choix possible est de s'adapter aux lecteurs de moindre compétence.

              Par ailleurs, la compétence du lecteur a également une influence sur sa réceptivité :

              • la connaissance de la langue :
                • le vocabulaire ;
                • les structures syntaxiques ;
                • la grammaire ;
              • la connaissance du sujet traité ;
              • la capacité à raisonner correctement.

              [ Proposition ]

              Voici le principe général dans sa forme étendue (une sous-partie du principe général peut être exploitée) :

              • 1) On exploite la capacité d'un langage formel (dit ici LFC) à exprimer le sens de façon univoque.

              Par exemple, on s'inspirera des travaux de Rudolph Carnap avec sa définition d'une langue résultant d'une convergence d'une langue naturelle et du formalisme mathématique, cf. ce commentaire au point B (hors objectif de traduction entre différentes langues naturelles). J'appelle ici LFC ce Langage Formel Carnapien.

              • 2) On permet au contributeur d'écrire en LFC :

                • 2.1) soit directement (peu intéressant, surtout si c'est sans contrôle de validité, et pénible) ;
                • 2.2) soit indirectement, via une interface de saisie prédictive du type ACEWiki (cf. ce commentaire), permettant de s'exprimer en LNC (langage naturel contrôlé), c'est à dire dans sa langue naturelle mais avec une contrainte de formulation pour tendre vers l'univocité ; l'expression résultante en LNC a vocation à être traduite vers le LFC ;
                • 2.3) soit indirectement, via du langage naturel, sans contrainte a priori quant à l'univocité du sens, suivi d'un processus de traduction vers le LFC, avec si besoin un traitement automatique de questions/réponses avec le contributeur, pour identifier le sens exact de sa contribution.

              Avec les contributions du type 2.2 et 2.3, on peut envisager un contrôle et une correction sur les expressions maladroites, les coquilles, certaines formes de lourdeur de style, les défauts de clarté par ambiguïté et certains défauts de justesse (notamment l'incohérence intrinsèque du texte, cf. par exemple la capacité d'ACEWiki à contrôler la cohérence de toute nouvelle assertion exprimée en LNC avec une liste d'assertions préalablement saisies, toutes cohérentes).

              • 3) On permet au lecteur de lire la contribution sous différentes formes :

                • 3.1) le texte source du contributeur, qu'il ait été produit directement en LFC, en LNC, ou en langage naturel ; cette option ne sera généralement pas la plus pertinente ;
                • 3.2) de paramétrer son niveau de compétence pour obtenir un texte en langage naturel en adéquation avec son niveau, le texte présenté étant issu d'une traduction depuis l'expression en LFC ; le niveau de compétence concerne notamment la connaissance de la langue (vocabulaire, structures syntaxiques, grammaire), la connaissance du sujet traité, et la capacité à raisonner correctement.

              Pour illustrer le point 3.2, voici quelques exemples de paramétrage du niveau de compétence et des exemples d'implication sur le texte résultant :

              • pour le vocabulaire et les structures syntaxiques, une liste noire gérée par le lecteur pourrait exclure les mots dont le sens n'est pas maitrisé et les structures syntaxiques non comprises, l'information pouvant être contenue dans un fichier associé à un compte de l'utilisateur (le respect de la vie privée est à prendre en considération, ça peut constituer un problème pour un traitement côté serveur à partir des paramètres du compte utilisateur) ;
              • selon le paramétrage de la connaissance du sujet traité (comment obtenir ce paramétrage n'est pas traité ici), le texte pourrait être adapté en terme d'explicitation des concepts, avec la possibilité d'inclusion de liens pour faciliter l'approfondissement ;
              • selon la capacité à raisonner correctement (comment obtenir ce paramétrage n'est pas traité ici), les exposés engageant des inférences logiques nombreuses, voire des démonstrations, pourraient être plus ou moins détaillés, avec la possibilité de présenter plusieurs niveaux d'approfondissement par pédagogie (éventuellement consultables par un parcours indexé, cf. plus bas).

              [ Deux principes optionnels : traductions multi-langues / parcours indexé à différents niveaux d'approfondissement ]

              Voici deux possibilités d'extension des principes décrits ci-avant :

              • la traduction vers toutes les langues, combinée à la mise en adéquation au niveau de compétence du lecteur.

              Pour la traduction automatisée, cf. les sources suivantes, dans l'ordre antichronologique : un commentaire présentant (au point 2 après le trait de séparation horizontal) un protocole autorisant l'écriture en langage naturel suivie d'un jeu de questions/réponses (c'est ce qui m'a inspiré le protocole 2.3 du présent commentaire), un commentaire (déjà cité) sur le logiciel libre Apertium puis les travaux de Rudopf Carnap, le journal titré « traduction automatisée de langage naturel contrôlé ».

              • la capacité d'effectuer un parcours indexé de texte par sélection d'un extrait sur lequel on veut un approfondissement (accentué, ou moindre), pour accéder à la consultation du passage (plus, ou moins) approfondi correspondant.

              Pour des sources sur cette forme de parcours indexé, cf. ce commentaire au dernier point avant le trait de séparation horizontal.

            • [^] # Re: Attaque par le compilateur

              Posté par . Évalué à -9.

              Après réflexion, et bien que tu n'y ailles pas avec le dos de la cuillère (« manque total de lucidité sur son incapacité à communiquer ses idées de manière intelligible et logique) », ha oui, quand même…), j'ai estimé qu'il y avait peut-être un problème d'ordre médical, du coup, j'ai sollicité la bienveillance d'un expert en science de la sagesse. Peut-être aura-t-on le bénéfice de son diagnostique (déjà moi, puisqu'il semble que je sois malade, et puis vous tous, par la réduction de la peine que je vous cause).

              « Ne t'inquiète pas, ça va bien se passer… bien se passer… ne t'inquiète pas ! »
              Maitre Yoda

              • [^] # Re: Attaque par le compilateur

                Posté par . Évalué à 9. Dernière modification le 08/02/19 à 13:13.

                j'ai sollicité la bienveillance d'un expert en science de la sagesse.

                Tout d'abord mon domaine d'expertise est avant tout les mathématiques pure et la logique formelle, mais j'ai néanmoins une connaissance approfondie de la philosophie kantienne et une certaine érudition au sujet de la pensée philosophique.

                Maintenant, je te le dis : tu es un parfait crétin doublé d'un malotru. Non, pour reprendre ton expression sur l'autre fil de discussion, qu'il n'est plus nécessaire de polluer, nous ne sommes pas en bonne compagnie ! On ne colle pas de quenelles pour sodomiser Kant à titre posthume ! Quand bien même on appelle cela de l'humour : ton sens de l'humour m'est parfaitement incompréhensible.

                Ton problème principal de longueur dans tes textes n'est pas une pathologie (comme la logorrhée) mais tout simplement de la micrologie : c'est-à-dire de l'inutile précision dans les détails.

                Pour le reste tu passes ton temps à essayer d'employer des notions et des concepts auxquels tu n'entends absolument rien, et cela face à des personnes qui, elles, les comprennent.

                Au sujet de ton projet de LFC, tu devrais t'associer à Mr BG est son projet de C-Cool. Quand vous en serez à la phase de bootstrap, vous nous ferez un journal…

                Vu que tu aimes Carnap, tu devrais lire ça : Carnap, Cassirer, and Heidegger: The Davos Disputation and Twentieth Century Philosophy, c'est incroyable à quel point Kant est omniprésent dans un article où son nom n'est même pas mentionné dans le titre.

                Et globalement sur tes délires de projets :

                Faire des plans, c'est bien souvent se laisser aller à une activité intellectuelle ostentatoire et fanfaronne : on se donne une apparence de génie créateur en demandant ce qu'on n'est pas capable d'exécuter soi-même, en dénigrant ce que l'on est cependant incapable de surpasser et en prônant ce dont on ne saurait dire où le trouver.

                Kant, prolégomènes à toute métaphysique future.

                À l'avenir, ne prends pas la peine de répondre à mes commentaires en espérant que j'y réponde, tu y trouveras systématiquement la porte fermée. Considère notre canal de communication comme définitivement clos : je ne donne pas à manger aux cochons sans aucune éducation.

                Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

                • [^] # Re: Attaque par le compilateur

                  Posté par . Évalué à -10. Dernière modification le 08/02/19 à 16:05.

                  j'ai néanmoins une connaissance approfondie de la philosophie kantienne

                  Je pense que c'est vrai, pour autant j'ai l'impression qu'il te reste à creuser, cf. ce commentaire auquel tu refuses donc de répondre, dans lequel je prétends démontrer avec détermination et la plus haute précision (inutile précision ? Hahahaha !) que Kant nous a pondu un paralogisme sur base d'une définition erronée. Tu m'as pourtant lu, puisque tu réagis à la conclusion humoristique que tu refuses de prendre pour telle…

                  Je me pose donc les questions suivantes publiquement

                  • Es-tu mis en défaut sur un sujet que tu es sensé maitriser profondément et cela t'est-il pénible au point que tu trouves une telle échappatoire ?

                  Je pense que si ça intervient, c'est marginal.

                  • Le fait que je maltraite Kant avec humour t'est-il insupportable à ce point ?

                  Si oui, j'en suis désolé et très surpris. Tu manquerais gravement d'humour et gagnerais à passer un moment en compagnie du soignant par le rire Dieudonné M'Bala M'Bala.

                  • Le fait que j'use du mot quenelle te renvoie-t-il aux HLPSDNH (heures les plus sombres de notre histoire), en mode Alain Jakubowicz, ce bouffon qui associait la quenelle de Dieudonné à la sodomisation des victimes de la Shoa ?

                  Ca me semble possible et regrettable, je ne saurais en juger.

                  J'envisage fort bien que le gros du problème soit pour toi une question d'exposition sociale à discuter avec moi, qui ose placer une quenelle, même humoristique, au cher Emmanuel Kant, bien qu'il ne fut pas juif mais protestant, semble-t-il… exposition sociale vis à vis des pires hyènes qui trainent sur Linuxfr.org et au-delà, dans les vastes Internets, jusque et y compris certainement dans les milieux scientifiques que tu fréquentes. Si l'humour à base de quenelle est clivant à ce point, tant pis, je resterai avec ma crétinerie alléguée et toi avec ta confiance désormais branlante, si tu sais lire, dans les égarements kantiens, ou au moins ceux de ses traducteurs de l'allemand au français (mais là, ça fait deux sources concordantes, c'est un point dur…).

                  Pour le reste tu passes ton temps à essayer d'employer des notions et des concepts auxquels tu n'entends absolument rien, et cela face à des personnes qui, elles, les comprennent.

                  Bing ! La formule magique, l'échappatoire à deux sous !

                  Vu que tu aimes Carnap, tu devrais lire ça : Carnap, Cassirer, and Heidegger: The Davos Disputation and Twentieth Century Philosophy, c'est incroyable à quel point Kant est omniprésent dans un article où son nom n'est même pas mentionné dans le titre.

                  Là tu aiguises ma curiosité. Merci.

                  Pour ta citation des prolégomènes, je comprends. Je te laisse libre de penser ce que tu veux. Tu n'as qu'une idée lointaine de ce qu'est ma vie.

                  Pour ta déclaration de fin de transmission, je la reçois, j'en suis fort aise. J'en ai conchié plus d'un pour moins que ton présent comportement. Cependant, par nature, je crois que je ne fermerai pas définitivement le canal de mon côté. Même avec le grand pitre Single, il n'est pas strictement fermé, c'est dire !

                  Bonne continuation, kantien. Que la sagesse guide tes pas !

                  • [^] # Re: Attaque par le compilateur

                    Posté par (page perso) . Évalué à 4.

                    Je t'ai demandé ce matin d'éviter tes propos sur la quenelle. Tu recommences. Tu te crois où ? Tu nous prend pour qui ?

                    Et descend de ton piédestal tu vas prendre froid.

                    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

                    • [^] # Re: Attaque par le compilateur

                      Posté par . Évalué à 6.

                      Sommaire

                      Et descend de ton piédestal tu vas prendre froid.

                      Je viens de voir que vous avez effacer son compte et supprimer certains de ses messages. Comme j'étais en train de rédiger un long commentaire pour exposer sa profonde ignorance au grand jour et que je ne veux pas avoir perdu du temps pour rien, je le mets quand même ici. Il pourra servir comme référence, au cas où il revienne avec un autre compte.

                      Voici une analyse de sa confiture que nous ne savons pas apprécier au sujet de l'article de Ken Thompson.

                      Le cas Ken Thompson

                      Alors que Ken Thompson reçoit le prix Turing en 1983 pour son œuvre, lors de son discours de remerciement, il présente le programme le plus malin (cutest)1 qu'il ait jamais écrit. Son discours est retranscrit sous forme d'article et publié dans un bulletin de l'ACM sous le titre Reflections on trusting trust.

                      Le programme en question est fortement lié au présent journal, puisqu'il consiste à corrompre un compilateur C dans la chaîne de bootstraping, de tel sorte que tout compilateur C qui lui succède introduise une porte dérobée dans le programme de login d'un système Unix.

                      Son exposé se décompose en trois étapes que nous présenterons brièvement dans ce qui suit.

                      Étape 1

                      La première étape consiste à écrire un programme qui, lorsqu'il s'exécute, reproduit son propre code source sur la sortie standard. Un tel programme est dit autoreproducteur. En voici un exemple minimal en OCaml :

                      (fun x -> Printf.printf "%s %S" x x) "(fun x -> Printf.printf \"%s %S\" x x)";;
                      (* ci-dessous le retour de l'exécution, identique au code source *)
                      (fun x -> Printf.printf "%s %S" x x) "(fun x -> Printf.printf \"%s %S\" x x)"

                      Étape 2

                      La seconde étape traite un problème posé dans un autre commentaire du journal par redo_fr : comment ajouter de nouvelles fonctionnalités à un langage en compilant le nouveau compilateur avec une version antérieure, qui ignore, donc, les nouvelles fonctionnalités ?

                      Il y traite un exemple simple avec l'interprétation des séquences d'échappement dans les chaînes de caractères. Il montre comment boostraper l'interprétation de la séquence \v comme une tabulation verticale. Ainsi, même si, à la génération N, la séquence \v n'est pas valide, à partir des générations N + 1 et suivantes, tous les compilateurs pourront l'utiliser dans leur propre code source.

                      Étape 3

                      C'est l'étape finale où il décrit comment introduire la porte dérobée sans laisser aucune trace dans le code source du compilateur.

                      Dans une représentation idéalisée du fonctionnement d'un compilateur, celui-ci lit le code source du programme puis applique une routine compile(s) sur les parties du code. Pour introduire une porte dérobée, on peut tester la correspondance de la fonction à compiler sur un motif donné et introduire dans ce cas compile(backdoor).

                      Le défaut de cette approche est que même une lecture superficielle du code source du compilateur risque de découvrir le pot aux roses, en voyant l'exécution conditionnelle de l'instruction compile(backdoor).

                      La solution consiste, alors, à combiner les techniques des deux premières étapes afin d'effacer la supercherie du code source du compilateur. À la génération N, on introduit la porte dérobée sous forme d'un programme autoreproducteur (étape 1), que l'on boostrape (étape 2), puis l'on distribue ce binaire comme compilateur C officiel qui reproduira son comportement dans toutes les générations successives.

                      Le lecteur intéressé par les détails de chaque étape pourra toujours se reporter à l'article de Ken Thompson.

                      Maintenant, chers lecteurs, attardons nous quelque peu sur l'analyse détaillée de cette succulente confiture gracieusement offerte par SamWang, que, nous autres, pauvres cochons, n'avons pas su éstimer à sa juste valeur. Ça vaut le détour ! :-)

                      La recension de SamWang

                      Lui, ô grand chasseurs devant l'éternel de coquilles, coquillages et autres crustacés, se propose de nous révéler quelques une de ses prises, suite à sa lecture du papier l'été dernier. Et quelles prises ! :-D

                      Avant cela, il tente un résumé de l'article qu'il semble n'avoir pas totalement saisi. Pour lui, l'article expose l'injection d'une porte dérobée dans la compilation du fichier login.c. Puis Ken Thompson mettrait ensuite « en garde contre le risque d'injection de code malveillant par un compilateur malveillant dans tout programme qu'il compile, y compris un compilateur ». J'espère que tout lecteur attentif de ma présentation aura compris que c'est un peu plus subtil que ça.

                      Passons, à présent, aux coquilles mineures relevées. Il en trouve deux :

                      • inversion de légendes entre deux figures du papier ;
                      • placement de figures dans la mauvaise section.

                      S'il y a bien inversion de légende entre deux figures (celles qui illustrent comment ajouter la séquence d'échappement \v au langage) et que tout lecteur attentif corrigera de lui-même, je suis au regret de lui apprendre que la seconde n'en est pas une.

                      SamWang ne devant pas être habitué à la lecture d'article académique, il a pris pour une coquille ce qui n'est rien d'autre qu'une mise en page, on ne peut plus classique, dans ce genre de papier. Les figures liées à la section 2 sont reportées en bas de page, qui, dans le cas présent où chaque page est en format deux colonnes, se trouve en bas de la seconde colonne. Cela lui donne l'illusion qu'elles sont insérées dans la section 3 dont le texte commence sur cette deuxième colonne.

                      C'est déjà quelque peu amusant, mais le plus beau reste à venir. Dans le fond, SamWang a une âme d'explorateur : il rêve d'une terre remplie de K-zino, avec son comparse zind dans sa logique LFC, inspirée des travaux de Rudolph Carnap, pour faire de la LNC. Malheureusement pour lui, depuis dix ans qu'il en parle, il ne navigue toujours par sur l'océan à la recherche de la terre promise. Nulle Santa Maria, ni même le moindre radeau, et tous ses bateaux semblent prendre l'eau. Alors, seul sur le rivage, admirant au loin l'horizon, il doit s'ennuyer un peu : il part donc à la pêche aux coquillages.

                      Et là, mazette, quelle récolte ! Ken Thompson ne sait même pas écrire correctement du C. Oui, vous avez bien lu : Ken Thompson est une bille en C, il ne sait pas écrire un programme de quelques lignes syntaxiquement valide, et en plus il propose ça en publication à l'ACM qui valide le tout. Mais dans quel monde vit-on ?

                      Voyons voir cette grossière erreur un peu plus à la loupe. Elle se trouve dans l'étape 1, lorsqu'il traite des programmes autoreproducteurs. Son code commence par la déclaration d'une chaîne de caractères :

                      char s[] = {'t', '0', '\n', '}', ';' ... }

                      Puis, dans la boucle principale, il parcourt cette chaîne pour l'imprimer caractère par caractère. Ni une, ni deux, SamWang arrive à la conclusion fatidique : si je commence par écrire cette séquence de caractère au tout début d'un fichier, je n'aurais pas un code source C valide. En conséquence, alors que le programme d'exemple devait afficher son propre code source, il affiche un texte qui n'est même pas valide en C. Quel escroc ce Ken Thompson ! encore un qui essaye de jouer au paralogisme, mais on n'échappe pas à la surveillance assidue du SamWang.

                      Rassurez vous, rien de tout cela dans le code de Ken Thompson, c'est juste que l'idiot de service à oublier de lire l'instruction qui précède la boucle for :

                      printf("char\ts[] = {\n");

                      C'est vrai que, finalement, il a un certain sens de l'humour notre SamWang : certes à ses dépends, mais c'est drôle quand même. :-)

                      Après, pour être tout a fait exact, son exemple n'est pas un programme autoreproducteur mais génère un tel programme. Il le précise lui même :

                      The purist will note that the programm is not precisly a self-reproducing programm, but will produce a self-reproducing programm

                      Ken Thompson

                      Ce qui est encore plus drôle (deuxième effet kiss cool) est que, à la toute fin de son commentaire, SamWang pointe un lien vers un vrai programme autoreproducteur « dans lequel le tableau de données est lu deux fois et interprété différemment les deux fois.[…] une solution bien astucieuse » (les mots sont de SamWang). Tout lecteur de bonne foi, comprenant le C, réalisera sans peine que cette solution astucieuse est identique, dans l'esprit, à celle de Ken Thompson.

                      Comme autre perle de sa pêche aux coquillages (heureusement que je sais ouvrir les huîtres), on trouvera celle-ci. S'interrogeant sur l'utilité de cette étape dans le corps de l'article, notre cher ami écrit, je cite :

                      Je suppose que s'il passe par cette étape, c'est pour justifier la possibilité, pour un compilateur malveillant, d'injecter sa malveillance en tant que code source ajouté au code source légitime qu'il compile. Bien que son propos manque d'articulation logique, je pense qu'on peut légitimement inférer ce que je viens de supposer.

                      SamWang au sommet de sa forme.

                      Je laisse le lecteur libre de juger à quel point l'étape 1 est cruciale pour l'étape 3 (d'après ma présentation), et si, dans son article, Ken Thompson ne le signale pas explicitement selon une articulation logique sans faille. Ce qui manque, assurément, d'articulation logique, ce sont les commentaires à ralonge de SamWang.

                      Arriver à ce stade, toute personne sensée, avec un minimum d'humilité, aurait du se dire : « j'ai du raté un truc » (en l'occurrence oui, à savoir, une ligne de code). Mais comme rien n'arrête notre SamWang, il va bien plus loin : par une réduction à l'infinie, il entend, dans un premier temps, nous convaincre que le problème que cherche à résoudre Ken Thompson n'a même pas de solution. Non seulement il ne peut toujours pas naviguer sur l'océan à la recherche de découverte pleine d'espérance, devant se contenter du rivage et de ses coquillages, mais le voilà maintenant chutant inexorablement dans le tonneau des danaïdes, ce puit sans fin dont il desespère de ne pas voir le fond.

                      Ce genre de problème de point fixe est on ne peut plus courant, mais il semble l'ignorer : étant donné une fonction f trouver une valeur x tel que f (x) = x ; où ici la fonction f, dont on cherche un point fixe, est la composée de deux autres f = run . compile, de telle sorte que l'on cherche source satisfaisant l'équation :

                      (run . compile) (source) = source
                      

                      Il se met alors à chercher des contournements au défi, en assouplissant les contraintes, afin d'y arriver. Il envisage, par exemple, un programme qui ouvre son fichier source puis l'affiche, ce qui nécessite d'avoir toujours à disposition le code source d'un tel programme. Là où l'on voit qu'il n'a rien compris à l'article, étant donné que le compilateur compromis ne sera distribué que sous forme binaire tout en ayant la capacité de « parasiter » tous les futurs compilateurs qui
                      l'auront comme ancêtre.

                      Incompréhension totale de l'article confirmée par ce qui conclut cette partie du commentaire (qui constitue la moitié, en volume, du commentaire complet) :

                      Tout ceci étant exprimé, est-il impératif d'avoir une solution viable au défi pour que l'exposé de Ken Thomson tienne la route par ailleurs ? Ma réponse est non.

                      SamWang dans sa chute ne voyant toujours pas le fond

                      Assurément que si, c'est impératif ! comme je viens de le rappeler.

                      Enfin, nous touchons au sublime avec la conclusion du commentaire, où, sautant du coq à l'âne, dans une articulation logique à toute épreuve, l'on apprend dans la foulée de cette question-réponse que, si, finalement, on peut écrire des programmes autoreproducteurs et que l'on appelle cela des quine (en l'honneur du philosophe analytique William Quine, je précise). SamWang a donc passé la moitié de son commentaire à nous expliquer que c'est pas possible, pour, finalement, nous dire que c'est possible. Effectivement, ça valait le coup ! :-D

                      Non vraiment, je ne vois pas ce qui a bien pu m'amener à écrire :

                      Pour le reste tu passes ton temps à essayer d'employer des notions et des concepts auxquels tu n'entends absolument rien, et cela face à des personnes qui, elles, les comprennent.

                      et le voir me répondre :

                      Bing ! La formule magique, l'échappatoire à deux sous !

                      Ce qui précède doit bien apporter la preuve irréfragable de ce que j'avançais. Pour ce qui est de l'autre fil de discussion, ce n'est guère mieux, mais j'ai déjà assez perdu de temps comme cela pour devoir le justifier.


                      1. l'adjectif anglais cut, outre sa signification de mignon, peut aussi caractérisé quelque chose d'habile et d'ingénieux. En choisissant la traduction « malin », on retrouve le côté ingénieux d'un hack, ainsi que celui malveillant (par un jeu de mot) d'une attack. ;-) 

                      Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

                • [^] # Re: Attaque par le compilateur

                  Posté par (page perso) . Évalué à 3.

                  Au sujet de ton projet de LFC, tu devrais t'associer à Mr BG est son projet de C-Cool. Quand vous en serez à la phase de bootstrap, vous nous ferez un journal…

                  Ah non, pitié ! Je pense que le compilateur C-Cool risque le dépassement de pile.

          • [^] # Re: Attaque par le compilateur

            Posté par . Évalué à -6. Dernière modification le 06/02/19 à 16:05.

            Je te donne raison et je vais reformuler ceci de façon plus lisible :

            Et pourquoi faut-il réfuter la pertinence de cette procédure réputée valide tant qu'il n'y a pas la condition que j'ai ajoutée ?

            Non pas parce qu'il y aurait de la stéganographie — un contenu informatif (malveillant) non décelable — au niveau du code binaire (2), car si toute la chaîne de production des binaires est maitrisée depuis l'amorce d'un assembleur minimaliste écrit en binaire, alors la production d'une suite d'instructions binaires est toujours déterministe et sous contrôle du programmeur (si tant est qu'il vérifie la production (de tout binaire) faisant intervenir le… matériel).

            (2) une partie de la sémantique d'un code malveillant — paraissant intègre à l'analyse détaillée par rétro-ingénierie — peut n'être connue que des concepteurs du matériel sur lequel il est exécuté ; il suffit pour cela de s'assurer de la présence de motifs (malveillants) de suites d'instructions qui soient signifiants pour le processeur (l'amenant à faire un traitement malveillant), sans que le traitement induit par la présence de ces motifs ne soit documenté.

            Voici la reformulation après la ligne horizontale :


            Et pourquoi faut-il réfuter la pertinence de cette procédure réputée valide tant qu'il n'y a pas la condition que j'ai ajoutée ?

            On peut concevoir une forme de malveillance intégrée par stéganographie au sein d'un code binaire exécutable. Il y a alors un contenu informatif malveillant et non décelable au sein du code : le code parait intègre à l'analyse détaillée par rétro-ingénierie, mais la présence de motifs spécifiques constitués de suites d'instructions constitue un signal déclencheur, non documenté, d'une action occulte et malveillante par le matériel. En ce cas, seuls les concepteurs du matériel ont la connaissance de ce fonctionnement. Sachant qu'il y a de multiples suites d'instructions qui mènent à réaliser une même tâche utile, il est concevable qu'un compilateur malveillant choisisse de produire une suite d'instructions comportant un ou des motifs déclencheurs d'actions occultes et malveillantes.

            Cependant, ce type d'attaque n'est pas réalisable si toute la chaîne de production des binaires est maitrisée depuis l'amorce d'un assembleur minimaliste écrit en binaire, car alors la production d'une suite d'instructions binaires est a priori toujours déterministe et sous contrôle du programmeur. Cette production peut ne pas être déterministe du point de vue du programmeur, si une malveillance matérielle modifie le résultat de l'exécution des instructions légitimes (on pense ici particulièrement au résultat de l'exécution des instructions légitimes d'un compilateur). Le risque d'une telle malveillance peut être écarté par une procédure systématique de vérification de l'intégrité de tout binaire exécutable produit.

            On voit ici qu'au prix d'un effort de vérification d'intégrité des exécutables produits, effort qui peut être assez lourd, le risque d'une malveillance intégrée par stéganographie au sein du code est écarté. Ainsi, ce risque n'est donc pas une raison suffisante pour justifier de réfuter la pertinence de la procédure garantissant l'intégrité des compilateurs via l'amorçage d'une graine binaire, réfutation qui serait faite au titre qu'il n'y aurait pas conjointement de garantie d'un matériel parfaitement contrôlé.

            • [^] # Re: Attaque par le compilateur

              Posté par (page perso) . Évalué à 4.

              Tu n'as pas compris : ma citation était un exemple de ce qui ne va pas, pas un point précis à éclaircir.

              De plus, je ne suis pas convaincu que ta nouvelle version soit réellement plus claire ; déjà elle est sensiblement plus longue.

              La connaissance libre : https://zestedesavoir.com

            • [^] # Re: Attaque par le compilateur

              Posté par . Évalué à 9.

              Je pense que tu n'as pas compris de quoi on parlait. Le but n'était pas d'éclaircir ce paragraphe confus, c'était de donner un exemple.

              Outre la taille gigantesque de tes blocs de texte, c'est avant tout un problème de clarté.

              Et pourquoi faut-il réfuter la pertinence de cette procédure réputée valide tant qu'il n'y a pas la condition que j'ai ajoutée ?

              Par exemple, pour moi, cette phrase m'apparait totalement vide de sens. Sa syntaxe est extrêmement ambigüe (est-ce que "tant qu'il n'y a pas" fait référence à "réputée valide" ou à "réfuter la pertinence"?), et les mots d'enchaînent sans signification, avec des références vagues à un contexte qui ne semble pas évoqué dans ton texte. Tu pourrais écrire :

              « Et pourquoi faut-il commanditer la perméabilité de cette orchidée réputée obscure tant qu'il n'y a pas la farine que j'ai ajoutée»

              que je ne verrais pas une différence en terme de sens.

              • [^] # Re: Attaque par le compilateur

                Posté par . Évalué à -8. Dernière modification le 06/02/19 à 19:04.

                Ok, j'ai reçu vos deux messages, le tien et celui de SpaceFox, à propos du problème de clarté et de longueur.

                Je prétends produire du texte désambiguïsé et j'estime que généralement c'est le cas, mais là… Je ne sais pas ce que tu as déniché comme autre ambiguïté, mais celle que tu cites ici est magistrale et inadmissible au vu de ma prétention. Merci de l'avoir relevée et je m'empresse donc de la corriger.

                Version originale ambigüe :

                Et pourquoi faut-il réfuter la pertinence de cette procédure réputée valide tant qu'il n'y a pas la condition que j'ai ajoutée ?

                Avant correction, note que le paragraphe qui précède cette phrase, dans le commentaire originel, est très éclairant (la phrase ambigüe qui le suit prétend en reprendre le sens partiellement, en résumant) :

                Le problème est tellement sérieux et profond qu'il convient de réfuter la garantie de sureté de la seule procédure d'amorçage d'une graine binaire (1), tant que tu n'as pas du matériel intégralement en sources ouvertes et contrôlé (contrôlé, c'est à dire avec des audits redondants sur les spécifications intégrales, avec preuves formelles de code autant que possible, supervision de la fabrication et de la distribution).

                Maintenant, voici une première version désambiguïsée de la phrase incriminée :

                « Et pourquoi faut-il réfuter la pertinence de cette procédure (réputée valide) tant qu'il n'y a pas la condition que j'ai ajoutée ? »

                Là, j'ai juste ajouté une paire de parenthèses, pour permettre de rattacher correctement et sans ambiguïté l'expression « tant qu'il n'y a pas la condition […] » à l'action de « réfuter […] ».

                Voici une autre formulation, qui reprend plus précisément les termes du paragraphe qui précède la phrase incriminée :

                « Et pourquoi faut-il réfuter la pertinence de la garantie de sureté de la seule procédure d'amorçage d'une graine binaire (réputée valide), tant qu'il n'y a pas du matériel intégralement en sources ouvertes et contrôlé ».

                Tu noteras que cette dernière formulation est lourde dans son contexte originel, dans la mesure où elle reprend les termes du paragraphe qui la précède. Ceci dit, j'ai tendance à privilégier cette formulation qui, bien que redondante, à le mérite de pouvoir être copiée/collée hors de son contexte sans perte de clarté (ou une perte minimisée). Note qu'une telle formulation lourde, voire bien grasse, déclencherait volontiers des quolibets… N'est-ce pas ;) ?

                Je finirai en te disant que l'effort que tu as fait sur mon texte, je ne l'ai pas fait jusqu'au bout sur le tien, dans la mesure où ton premier commentaire sous ce journal comportait pour moi quelques ambiguïtés que je n'ai pas relevées publiquement, ce que j'aurais pu faire en te sollicitant pour accéder au sens que tu voulais transmettre. Hormis quelques pseudos que j'ai bien identifiés, je suis tellement habitué sur Linuxfr.org à des propos approximatifs écrits sans scrupule (et si souvent à de la mauvaise foi dans les échanges avec moi, même si moins qu'il y a quelques années) que j'ai tendance à négliger la recherche du sens exact en tout point. Pardon pour cette négligence, arnaudus, que je corrigerai peut-être en te relisant plus tard si je l'estime important.

                • [^] # Re: Attaque par le compilateur

                  Posté par . Évalué à -9.

                  Grumpf… [ correction ]

                  J'ai écrit ceci au commentaire parent :

                  Voici une autre formulation, qui reprend plus précisément les termes du paragraphe qui précède la phrase incriminée :

                  « Et pourquoi faut-il réfuter la pertinence de la garantie de sureté de la seule procédure d'amorçage d'une graine binaire (réputée valide), tant qu'il n'y a pas du matériel intégralement en sources ouvertes et contrôlé ».

                  Dans cette reformulation détaillée, l'expression « la pertinence de » est en trop. Désolé pour le bruit.

                  • [^] # Re: Attaque par le compilateur

                    Posté par (page perso) . Évalué à 1. Dernière modification le 10/03/19 à 22:22.

                    Je débarque un mois après la conversation, mais je suis obligé de l'admettre : quels progrès depuis Luc2 !

                    Intendant, donc méchant, mais libre !

  • # Imbitable

    Posté par (page perso) . Évalué à 3.

    J'ai regardé les slide du FOSDEM et j'ai trouvé que c'était complètement incompréhensible… Au final je trouve que sa présentation aurait été plus efficace si elle avait contenu un seul slide comme la phrase que tu as écrite : « On commence par un petit bout de binaire écit à la main (il faut bien !) pour aller vers un langage de macro simplissime, puis un assembleur simpliste et enfin un assembleur correct, une mini-VM etc. »

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.