Intégration de propolice dans OpenBSD-current

Posté par Jean-Yves B. le 03 décembre 2002 à 20:01. Modéré par Fabien Penso.

Étiquettes :

déc.

2002

propolice, une extension à gcc pour détecter et empêcher les attaques par débordement de tampon (« buffer overflow »), est en cours d'intégration à OpenBSD.
Il n'y a pas encore de mesure précise du coût en terme de performances mais les tests déjà opérés sur d'autres systèmes sont encourageants.
propolice est fondé sur les même idées que StackGuard. Microsoft® Visual C++® .Net propose également un service du même type.

Bien entendu, ce genre de produit n'est qu'un rempart de plus, avec ses propres failles, cela n'empêche pas d'apprendre à écrire du code sûr. La version de gcc utilisée par OpenBSD est la 2.95.3, la version 3.2.x présente dans les ports ne possède pas encore cette extension, ça ne saurait tarder.
Si vous voulez tester, il vaut mieux utiliser un snapshot car la recompilation du système avec propolice depuis une version -stable ou 3.2 est un peu sportive. Et recompiler les packages aussi, pour qu'ils utilisent la version propolice des librairies telles que la libc ou autre.

Aller plus loin

Annonce deadly (4 clics)
propolice (9 clics)
Overhead propolice (8 clics)
StackGuard (3 clics)
Ça n'est pas toujours parfait (3 clics)
Ça existe aussi dans Visual C++® .Net (4 clics)

# Re: Intégration de propolice dans OpenBSD-current

Posté par Benoît Sibaud (site web personnel) le 03 décembre 2002 à 20:15. Évalué à 0.

Question plus ou moins hors-sujet : est possible (et si oui quelqu'un l'a-t-il essayé) de remplacer init par valgrind init pour déboguer les erreurs mémoire et de threads de tout ce qui tourne sur une distrib GNU/Linux donnée ?

Valgrind : http://developer.kde.org/~sewardj/(...)

Les perfs globales seront divisées par 20, mais bon avec vu la puissance des machines actuelles... Et puis le but c'est de déboguer, pas de faire du RC5-72.
- [^] # Re: Intégration de propolice dans OpenBSD-current
  
  Posté par Misc (site web personnel) le 03 décembre 2002 à 20:28. Évalué à 1.
  
  Les perfs globales seront divisées par 20,
  Ca fait quand meme beaucoup.
  Si on suit la loi de Moore, ca nous ramene 6 ou 7 ans en arriere.. ( 6 / 1.5 = 4 , 2 ^ 4 = 16 , donc en en 6ans, les perf multiplies par 16 ).
  je ne pense pas que ce soit si bon.
  passer de 2 Ghz a 100 Mhz, ca fait mal...
  
  mais, l idee est quand meme vachement fun.
  - [^] # Re: Intégration de propolice dans OpenBSD-current
    
    Posté par Benoît Sibaud (site web personnel) le 03 décembre 2002 à 21:02. Évalué à 1.
    
    Partant d'un P2-375 (bi pro certes mais bon), je peux compter sur un 486 SX 25. Bon autant utiliser carrément ma passerelle (DX2-66) pour voir si mon CPC 6128 peut faire tourner GNU/Linux :)
    - [^] # Re: Intégration de propolice dans OpenBSD-current
      
      Posté par Moby-Dik le 03 décembre 2002 à 21:06. Évalué à 1.
      
      gcc étant prévu pour du 32 bits ainsi que Linux, t'auras du mal.
      
      Autrement y a des émulateurs qui existent, tu peux essayer...
- [^] # Ca a pas l'air de marcher terrible
  
  Posté par kadreg le 03 décembre 2002 à 21:10. Évalué à 2.
  
  A lilo je tape :
  
  linux init=/usr/bin/valgrind /sbin/init
  
  Et j'obtient ça :
  
  http://kadreg.free.fr/perso/linux/valgrind-init.gif(...)
  - [^] # Re: Ca a pas l'air de marcher terrible
    
    Posté par Benoît Sibaud (site web personnel) le 03 décembre 2002 à 22:15. Évalué à 1.
    
    J'ai essayé ça comme shell (à part init je voyais pas où chopper un processus et tous ces fils)
    8<----------------------------------------------
    valgrind> log_valgrind
    8<----------------------------------------------
    
    Apparemment ça marche. Faut juste prévoir de la place pour le fichier de log, et être patient pour le résultat des commandes.
    - [^] # Re: Ca a pas l'air de marcher terrible
      
      Posté par Benoît Sibaud (site web personnel) le 03 décembre 2002 à 22:25. Évalué à 1.
      
      /backup/valgrind-1.0.4/bin/valgrind --trace-children=yes --logfile-fd=3 /bin/bash - 3< /backup/log_valgrind
      
      où le inférieur est un supérieur...
- [^] # Re: Intégration de propolice dans OpenBSD-current
  
  Posté par Stephane Marchesin (site web personnel) le 03 décembre 2002 à 22:11. Évalué à 1.
  
  Je n'ai pas essayé mais ce n'est pas possible. En effet, valgrind ne supporte pas un tas de choses vitales pour faire tourner un système linux, dont l'appel système clone(), ni les instructions MMX/SSE/3dnow/ (ça c'est pas vital mais c'est un des problèmes que j'ai eus)
  Il y a toute une liste de limitations ici :
  http://developer.kde.org/~sewardj/docs/manual.html#limits(...)
  
  En fait valgrind ne fait que se substituer aux librairies (libpthread, glibc...), donc utiliser valgrind pour tous les progs équivaudrait à tourner des glibc et libpthread modifiées.
# des goodies

Posté par falbala le 03 décembre 2002 à 22:06. Évalué à 2.

Pour completer les nouveautés, saluons également l'arrivé de pf5.

http://www.benzedrine.cx/pf/msg00634(...)

ça permettera, après la 3.3 selon l'auteur, de faire du HA comme il était question dans ce thread :
https://linuxfr.org/2002/11/26/10429.html(...)

Je vais commander de ce pas un câble ethernet en Y pour tester ça ;)
- [^] # petite correction
  
  Posté par Jean-Yves B. le 03 décembre 2002 à 22:30. Évalué à 1.
  
  C'est http://www.benzedrine.cx/pf/msg00634.html(...) en fait.
  C'est un premier pas vers le failover : un device pour récupérer les modifs sur la table d'états.
  
  Sinon, pour les cables ethernet en Y je suis preneur, j'en ai juste un en T qui ne marche pas en 100baseTX :)
# Effet de bord amusant ...

Posté par Jean-Yves B. le 06 décembre 2002 à 10:50. Évalué à 1.

Je suis un peu idiot donc je n'y avais pas pensé mais du coup ça va permettre de trouver plus facilement des bugs dans les logiciels portés (je n'avais vu que l'aspect sécurité de la chose).

En revanche je me demande comment démeler les faux positifs des vrais ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.