Re: optimisation vs securite

Dans l'article <fvuhhm$aj2$1@biggoron.nerim.net>,
  Marc Espie <espie@lain.home> écrit:

> Ca fait un moment que le zele des constructeurs de compilateurs a faire
> des trucs qui vont le plus vite possible aux benchmarks posent quelques
> problemes aux programmes reels.

Il n'y a pas que les benchmarks, il y a aussi des programmes réels.
Même si certaines optimisations peuvent sembler inutiles pour certains
programmes, elles peuvent être importantes pour d'autres.

> Le chiendent, c'est que certains tests et certaines instructions, rajoutees
> pour securiser du code, ne font pas forcement partie des `defined behavior'.

Dans la mesure où un programme se base sur un undefined behavior,
il ne peut y avoir aucune sécurité. Un compilateur peut toujours
décrire comment ça se comporte ou avoir des options du style -fwrap,
mais alors ce n'est plus portable.

Note: j'ai déjà vu du code supposer que toutes les variables (y compris
automatiques) étaient initialisées à 0. Ça risque de poser des problèmes
de performance si GCC doit supposer cela.

> Ou alors, la capacite des gcc recents a faire disparaitre des memset a 0,
> s'ils touchent des variables non utilisees ensuite (pratique commune pour
> virer des mot de passe en clair avant de poursuivre le programme), sachant
> qu'il n'y a PAS de construction raisonnable permettant d'avoir la
> semantique voulue (volatile n'en est pas une, puisqu'elle va generalement
> plomber le temps de calcul lie au mot de passe en question).

Et tu acceptes de plomber de temps de calcul d'autres programmes parce
que certains codes sont mal écrits?

Est-ce qu'avec des casts avec volatile seulement dans certains cas,
cela serait une solution acceptable?

Et puis le volatile ne garantit pas tout: par exemple, une partie du
mot de passe pourrait être conservé dans un registre. Bref, c'est à
la norme C de définir un moyen d'effacer toute info relative à telle
ou telle donnée (ce qui ne doit pas être si simple à spécifier).

-- 
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)