James Kanze wrote on 28/02/2008 22:12:
>
> À la mise sous tension, la mémoire contient effectivement
> n'importe quoi. (Aussi, la plupart des contrôleurs dont je me
> suis servi dans le temps prévoyaient bien une commande pour
> écrire des valeurs erronées. Pour des motifs de test, si rien
> d'autre. Mais le problème réel, c'est que jusqu'à la première
> écriture, le contenu n'est pas défini, et il y a des chances
> qu'il soit invalid.)

certes mais ce n'est pas le cas décrit ici.
évidemment toute la mémoire n'est pas vérifié à chaque tic d'horloge
(lorsqu'elle est rafraichie), elle l'est uniquement lorsqu'elle est lue,
or pour que le code: "int x; cout << x;" soit lu en mémoire et fourni au
CPU, il faut qu'il ait été écrit dans cette mémoire, lors de cette
écriture la valeur int32 (pas 33, ni 36, ni autre) non initialisée (en
supposant que le compilo n'est pas utilisé un registre) est écrite en
mémoire et son CRC est correctement calculé.

>> j'aurais même penser qu'une telle situation ne pouvait pas
>> durer plus de quelques nanosecondes (temps de "refresh"
>> moyen), à moins que la mémoire "qui n'a jamais été écrite" ne
>> soit pas rafraichie...
>
> Dans le cas où je l'ai rencontré, il s'agissait des mémoires
> statiques, sans refraiche. Mais je conçois bien aussi des cas où
> des mémoires dynamiques ne font pas jouer la détection d'erreurs
> lors des cycles de refraiche.

yep, à la lecture uniquement.

>>>> même dans ce cas je n'arrive pas à imaginer une valeur
>>>> spéciale faisant traper l'injecteur.
>
>>> Qu'est-ce qui se passe s'il y a une erreur de parité, alors ?
>
>> en ECC ? le controleur l'a déjà corrigé.
>
> Il ne peut pas en corriger toutes les erreurs possibles. Que des
> erreurs d'un seul bit, et certaines de deux bits.

en effet, mais ici encore l'amalgame est erroné.

le chargement de la valeur non prédictible a copié tels-quels tous les
bits et a calculé le ou les bits de contrôle, si une particule cosmique
vient basculer un ou 2 bits, le CRC le(s) corrigera.

il n'a pas à corriger "toutes les valeurs possibles" d'une variable non
initialisée car cela ne veux strictement rien donne - elle est. elle n'a
pas beson de correction, n'étant pas erronée.

>> avec bit de parité simple, ça dépends du BIOS, mais cela ne
>> regarde nullement le code - avec variables non initialisées -
>> chargé; lorsqu'il est chargé, tous ces octets ont une parité
>> correcte ou le système (le hard!) était déjà défaillant.
>
> Tu parles comme si on chargeait la mémoire à partir d'un disque.
> (Dans un système classique, évidemment, il n'y a pas de chances
> que ça se produisent, parce que le système écrit toute la
> mémoire avant de te la donner.) Moi, j'ai rencontré le problème
> dans des systèmes embarqués, avec le programme en PROM, et pas
> de disque.

oui je me plaçais en effet dans ce cas qui me semblait pas trop
anecdotique, un contrôleur [E[E]]PROM utilise toujours un contrôle de
parité (en premier lieu pour se défendre comme les attaques) mais ici
encore il ne détecte que les modifications ayant pu intervenir de
manière ciblée (attaque lumière) ou globale (micro-ondes) sur la PROM.
il ne se demande pas si un int8 particulier contient tel valeur parce
que c'est le bruit du compilo ou parce que le source contenait une
valeur intentionelle.

en résumé, estimer qu'il peut exister des compilos suffisamment malin
pour insérer un trap (une assertion) lorsqu'une variable non initialisée
est utilisée - tout en étant assez bête pour ne pas en faire une erreur
de compilo - est recevable. (un compilo C51 - embarqué - n'insère pas de
tel code).

dire qu'une variable n bits non initialisée peut faire traper le système
parce qu'elle contient une valeur n+m bits qu'elle ne peut pas
contenir est une erreur.

Sylvain.