Allocation/desallocation de RAM sur PC

On Aug 29, 4:59 pm, "A. Caspis" :

Je comprends, neanmoins j'ai poste ce que tu as demande.

:-)

Oui, et c'est pour cela que je ne vois pas ce que je peux faire de mieux que de passer la priorite de la thread en 'realtime' pendant le processus, puis d'effacer la memoire avant de la liberer.

Oui, mais comment veux-tu qu'un systeme puisse interpreter si ce qui a ete ecrit en memoire avant qu'elle soit liberee soit de l'information sensible ou pas ? C'est le programmeur seul qui le sait, donc d'apres moi c'est au programmeur d'effacer la RAM avant de la liberer. Dans le cas contraire, se serait au systeme d'effacer la memoire juste avant de servir un malloc() ou juste apres un free()

Mais c'est peut-etre deja le cas (?)

Tout a fait.

Et si il y a plusieurs threads "realtime" ?

C'est évidemment ce que font les OS sérieux, avec quelques optimisations. Par exemple sous Linux, quand malloc() a besoin de mémoire, il va la chercher dans /dev/zero avec mmap(). Chaque page est effacée par le noyau lorsque la MMU détecte que le processus y accède pour la première fois.

Un bloc libéré par free() reste attaché à l'espace mémoire du processus et peut lui être réalloué par malloc(); dans ce cas il n'y a pas besoin d'effacer.

Avec ce mode de fonctionnement le coût de la mise à zéro est parfaitement raisonnable. Je ne peux pas croire que XP fasse les choses très différemment.

AC

On Aug 29, 5:50 pm, "A. Caspis" :

C'est le niveau de priorite le plus eleve, le scheduler ne bascule pas une thread 'realtime' qui est en cours d'execution au profit d'une autre thread en attente. En principe une thread passe en mode 'realtime' seulement pour un temps court (puisque ca bloque les autres threads) puis une fois fini son boulot elle se re-assigne une priorite plus basse. Donc, un programme *bien ecrit* ne doit pas rester des plombes en priorite 'realtime'.

Alors je peux le faire moi-meme avec un memset(ptr,0,size) juste avant d'appeler free(ptr);

Okay, merci pour ces precisions.

Je n'en ai aucune idee (pour l'instant)

Si c'était utile, toutes les librairies C contiendraient une fonction cfree() pour faire ça, par analogie à calloc(). Or il n'y en a pas, ce qui confirme que personne ne s'est jamais soucié que l'OS réalloue de la mémoire contenant des données privées à un autre processus.

Il est vrai que les programmes qui manipulent temporairement des mots de passe prennent souvent la peine de les effacer après usage, mais c'est pour limiter la période pendant laquelle on peut les intercepter, et pas par crainte qu'un autre processus les reçoive par hasard longtemps après.

P.S. Après vérification mes détails sur Linux et sa libc sont un peu obsolètes, mais en gros c'est bien l'OS qui efface la mémoire quand c'est nécessaire.

AC

Doublehp se fendait de cette prose :

Ah bon ? Les Bios modernes n'effacent plus la Ram en la testant ???

Dire ça sur un forum sérieux d'électronique, c'est vous qui allez prêter à rire. Vous ne saviez pas que *tous* les transistors et autres semi- conducteurs étaient photosensibles ?

Vous racontez n'importe quoi si bien... :)

--
LeLapin

On Aug 29, 6:22=A0pm, "A. Caspis" :

Juste pour info, voici un extrait d'un dump d'une zone memoire allouee sous XP, on y voit que la RAM n'a pas ete effacee :

[Data: ] 256 bytes at 0x0014:EB88 - 0x0014:EC88 00000000 78 01 14 00 F8 C9 14 00 D0 F1 C7 28 25 DE D2 11 x.......... (%... 00000010 AF DD 00 10 5A 27 99 B5 0A 00 00 00 01 00 00 00 ....Z'.......... 00000020 00 00 00 00 48 08 00 00 3C 09 00 00 0C 00 00 00 ....H...

Ce n'est pas suffisant pour conclure qu'il y a eu une fuite d'information d'un processus à un autre. Il est tout à fait possible que le code généré par le compilateur alloue de la mémoire, y écrive des choses puis la libère, le tout avant de passer le contrôle à la fonction main(). Il est possible que le malloc() qui est dumpé réutilise cette mémoire là sans l'effacer, conformément à la documentation de malloc.

Si vous y reconnaissez des mots de passe ou des fragments de texte qui n'ont rien à y faire, évidemment, c'est une autre histoire.

AC

On Aug 29, 6:22 pm, "A. Caspis" :

Juste pour info voici un extrait d'un dump d'une zone memoire allouee sous XP : on voit bien que la RAM n'a pas ete effacee.

78 01 14 00 F8 C9 14 00 D0 F1 C7 28 25 DE D2 11 AF DD 00 10 5A 27 99 B5 0A 00 00 00 01 00 00 00 00 00 00 00 48 08 00 00 3C 09 00 00 0C 00 00 00 8F 10 3C 25 8F 10 3C 25 00 00 00 00 48 00 00 00 58 00 00 00 60 00 00 00 10 05 00 00 02 00 80 00 01 00 00 00 57 04 02 13 01 00 00 00 08 00 00 00 08 00 00 00 3F 02 05 22 FE 0B 05 07 00 00 00 00 01 00 00 00 FE 0B 05 07 01 00 00 00 3F 02 05 22 00 04 00 00 6A 24 0A 00 00 00 00 00 10 00 00 00 10 00 00 00 40 00 00 00 01 00 20 00 6A 24 0A 00 00 00 00 00 00 00 00 00 20 00 00 00 6A 24 0A 00 00 00 00 00 10 00 00 00 10 00 00 00 02 00 00 00 01 00 01 00 6A 24 0A 00 00 00 00 00 00 00 00 00

On Aug 30, 2:06=A0pm, "A. Caspis" :

| > Juste pour info, voici un extrait d'un dump d'une zone memoire | > allouee sous XP, on y voit que la RAM n'a pas ete effacee :

Oui, effectivement.

Et c'est aussi beaucoup plus dur a tester !

J'ai 256 Mb de RAM sur mon PC, je fais un malloc de 100 Mb et j'y ecris des sequences precises, puis je libere cette memoire, et immediatement avec un *autre* programme je realloue 100 Mb dans lesquels je recherche des fragments significatifs de la sequence initiale ... et jusqu'ici je n'ai rien trouve !

Bien que ce test ne soit pas assez rigoureux pour etre concluant, pour l'instant cela te donne raison.

et c'est comme ça que quand t'a pas de phototransitor tu peux en faire un en ouvrant un transibut en TO18 avec une lime

bnjour =E0 tous,

rien de rien? ...cad des cases m=E9moires =E0 0... ou bien non-correspondantes =E0 l'original?

vede ;O]

On Sep 1, 5:30=A0am, vede :

|> rien de rien? ...cad des cases m=E9moires =E0 0... |> ou bien non-correspondantes =E0 l'original?

Tout n'est pas a zero, il y a bien des donnees, mais je n'en retouve aucune du buffer d'origine.

Le 1er sept a 12:40=A0am Max :

MOS

pr=EAter

Alors qu'en ouvrant la cervelle de Doublehp on ne risque pas d'y appercevoir de la lumiere !