Re: Faille critique découverte dans GLIBC
mrr a écrit :
>
>> Dans ce cas, il me semble (et je peux donc me tromper, dans ce cas, il faudra me
>> corriger) que la bibliothèque dynamique est chargée au démarrage du programme.
>> Chacun des appels système sera donc fait selon la version installée à ce
>> moment-là. Si on met à jour la bibliothèque en cours d'exécution, le programme
>> ne profitera donc pas des corrections.
Et c'est bien pour cela qu'il faut redémarrer les processus utilisant un
exécutable (bibliothèque ou autre) mis à jour.
> Je vois, au 1er appel la librairie serait mappée en mémoire puis en
Oui.
> quelque sorte détachée de sa source, à savoir le fichier sur le disque.
Non, elle reste liée au fichier. C'est le principe du mapping. Même
chose pour l'exécutable d'un programme qui tourne.
> Par contre, ce qui me gène un peu c'est que cela signifierait que chaque
> processus en cours d'exécution aurait sa propre copie en mémoire.
Non, pas forcément, tant que la copie n'est pas modifiée. Ensuite seules
les pages éventuellement modifiées par un processus font l'objet d'une
copie séparée dans la mémoire virtuelle de ce processus.
> Ou il y a une autre possibilité de comprendre ta phrase qui me convient
> mieux, c'est qu'à chaque fois qu'une bibliothèque partagée est appelée
> pour la *1ère* fois, elle serait mappée dans l'espace virtuel pour tout
> le monde jusqu'à ce qu'il n'y ait plus aucun processus qui l'utilise et
> alors elle serait "déchargée".
Il y a de ça. Chaque ouverture d'un fichier compte pour un lien vers
l'inode correspondant, au même titre que les liens durs dans les
répertoires. La mise à jour fait pointer le nom du fichier vers un
nouvel inode qui contient la nouvelle version du fichier, mais l'inode
originel reste présent tant qu'il reste des liens, donc tant qu'il n'est
pas fermé par les processus qui l'ont ouvert.
Reply to: