Discussion :

[Trankille]

Bonjour ! Je suis actuellement en stage de fin d'étude.. et il est vrai que pendant les études, on prend pas soin de maitriser la compilation pour des projets "importants" mais surtout pour améliorer la "sécurité" du code.
J'ai vu les magnifiques options d'Emmanuel Delahaye mais j'aimerais avoir confirmation sur ma compréhension de certaines choses.


1)

-Wpacked
Warn if a structure is given the packed attribute, but the packed attribute has no effect on the layout or size of the structure

-> il y a warning seulement si le packed attribute -__attribute__((packed))- est utilisé alors qu'il n'y aura aucun effet sur la taille de la structure (pas d'ajout de padding).
-> par contre si l'utilisation du packed permet de ne pas ajouter du padding, alors aucun warning.

2) Si je veux un code "safe", je réduis l'optimisation.
C'est à dire que je compile avec -O1 voir -O0 (qui est le mode par défaut je crois)
et non -O2 ou -O3 ? ou alors "c'est complétement faux, va relire la doc" ?


3) Il faut utiliser différentes options de compilation selon le stade du projet.
En dev, on compile avec les options qui permettent de débugger, en prod on optimise.

4) Si vous avez de bons conseils, des précisions à apporter, n'hésitez pas

edit: Le but de ce topic n'est pas de connaitre vos lignes d'options,
mais plutôt de savoir à quel moment vous utilisez certaines options.

[souviron34]

1)

-> il y a warning seulement si le packed attribute -__attribute__((packed))- est utilisé alors qu'il n'y aura aucun effet sur la taille de la structure (pas d'ajout de padding).
-> par contre si l'utilisation du packed permet de ne pas ajouter du padding, alors aucun warning.

oui et non..

ça t'averti que c'est inutile

Ta 2ième ligne est fausse : l'utilisation de l'attribut, si elle permet un padding, est donc OK donc pas de warning.

1)
2) Si je veux un code "safe", je réduis l'optimisation.
C'est à dire que je compile avec -O1 voir -O0 (qui est le mode par défaut je crois)
et non -O2 ou -O3 ? ou alors "c'est complétement faux, va relire la doc" ?

oui, mais disons que il suffit de laisser le défaut..

Et même -O2 est correct..

-O3 est dangereux..

1)
3) Il faut utiliser différentes options de compilation selon le stade du projet.
En dev, on compile avec les options qui permettent de débugger, en prod on optimise.

oui et non..

ça dépend si tu veux pouvoir par exemple récupérer des coredumps de prod..

Mais en général oui tu compiles en dev avec -g et tu l'enlèves pour la prod. Plus ajouter de l'optimisation - jusqu'au niveau tolérable..

De plus, avant d'envoyer un binaire en prod, tu peux aussi faire "strip prog", qui enlève les chaînes ...et réduit la taille du binaire..

1)
4) Si vous avez de bons conseils, des précisions à apporter, n'hésitez pas

Ajouter dans tous les cas les flags correspondant à la bonne architecture/machine

[Trankille]

oui et non..

ça t'averti que c'est inutile

Ta 2ième ligne est fausse : l'utilisation de l'attribut, si elle permet un padding, est donc OK donc pas de warning.

voila ce que j'ai pu trouver.

GCC allows specifying attributes of variables and structures using the keyword __attribute__((__packed__)).

This means that that GCC will not add any padding bytes (for memory alignment) and make variables or fields immediately next to each other.

Donc ça veut bien dire qu'avec l'attribut, gcc ne rajoute pas de padding ?! et Que dans ce cas, l'attribut sert..
Je dois comprendre les choses à l'envers...

[souviron34]

voila ce que j'ai pu trouver.


Donc ça veut bien dire qu'avec l'attribut, gcc ne rajoute pas de padding ?! et Que dans ce cas, l'attribut sert..
Je dois comprendre les choses à l'envers...

non, t'as raison, c'est moi qui ai "mix" "padding" et "packing".

Ce que je voulais dire plus haut était :

l'utilisation de l'attribut, si elle permet un packing, est donc OK donc pas de warning

[Trankille]

En regardant (oui.. pas en lisant chaque option parce que sinon je dors ) la documentation de gcc,
je vois des options qui permettent de diminuer la sécurité apporté par le compilateur (comme par exemple -fno-stack-protector).
Mais est ce qu'il existe des options qui permettent au contraire, d'augmenter la sécurité du code ? de le rendre moins vulnérable ?

Si ce n'est pas le cas, ça veut donc dire que tout l'apport de sécurité
(gestion de la mémoire, accès mémoire etc..) réalisé par le compilo est activé par défaut ?

oui, mais disons que il suffit de laisser le défaut..

Et même -O2 est correct..

-O3 est dangereux..

Lors d'un projet , il me semble qu'on nous avait conseillé de passer l'option -O2 pour que la faille soit plus facilement exploitable.

[souviron34]

Lors d'un projet , il me semble qu'on nous avait conseillé de passer l'option -O2 pour que la faille soit plus facilement exploitable.

ne sois pas obsédé par les "failles"..

Je ne parlais pas en termes de dangerosité par rapport à des "failles", mais parce que l'optimisation très poussée (-O3) amène des problèmes très souvent si le code est complexe (plusieurs niveaux de pointeurs, sockets, interrupts, ..)


Pour le reste je n'en sais strictement rien..

[Trankille]

ne sois pas obsédé par les "failles"..

le problème c'est que je "travaille" (stage) sur le développement sécurisé ^^