Re: optimisation vs securite
[ Nouvelle discussion
| Répondre au groupe
|
fr.comp.lang.c ]
Sujet: Re: optimisation vs securite
De: vincent+n...@vinc17.org (Vincent Lefevre)
Groupes: fr.comp.lang.c
Organisation: a training zoo
Date: 13. May 2008, 11:31:55
References: 1 2 3 4 5
|
Dans l'article <g005i1$1jgj$1@biggoron.nerim.net>,
Marc Espie <espie@lain.home> écrit:
> In article <20080508232434$05bf@prunille.vinc17.org>,
> Vincent Lefevre <vincent+news@vinc17.org> wrote:
> >En fait, je ne vois pas le problème dont parle Marc concernant la mise
> >à 0 de la mémoire: il suffit de mettre le code dans une fonction avec
> >le pointeur passé à cette fonction, et de compiler cette fonction
> >séparément du reste: le compilateur ne peut pas deviner ce que va faire
> >le reste du programme et ne pourra donc pas optimiser (i.e. il sera
> >forcé de mettre à 0 la mémoire comme voulu).
> Effectivement, tu passes completement a cote du vrai probleme.
> Dans le temps, gcc n'optimisait pas le memset en question.
> Qui te dit que bientot, il n'optimisera pas ce qui se passe entre
> unites de compilation ? certains compilos le font bien...
C'est un bug. Un compilateur ne doit pas supposer plus de choses qu'on
lui fournit (à moins que ce soit documenté), et une telle optimisation
ne pourrait intervenir qu'au niveau du linkeur, et il faudrait que les
fichiers objets contiennent suffisamment d'information pour indiquer
que l'optimisation est valide (en effet, actuellement les fichiers
objets ne dépendent pas du langage et une optimisation valide en C ne
l'est pas forcément dans un autre langage).
Mais de toute façon, là, on sort complètement de la norme C, et le
programmeur doit un minimum se baser sur la doc de son compilateur
quand celui-ci outrepasse ce qu'il est censé faire (qui est de
compiler une unité en un fichier objet), et plus généralement de
son environnement (OS, etc.); les normes liées aux langages n'y
changeront rien. Un des problèmes connus concernant la sécurité est
d'ailleurs le swap, d'où la nécessité probablement d'utiliser mlock
sous système POSIX...
Un SIGSTOP qui intervient juste avant la mise à zéro de la mémoire
peut aussi être un problème...
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

|
 cette fonctionnalité est reservée aux membres ayant une session active !
|