...

• [^]Re: ...

  Posté par j () le 14/10/2005 à 08:30. (lien). Évalué à 10.

  Il y a plus de détails ici :
  
  http://www.securityfocus.com/columnists/359/2(...)
  
  et ici :
  
  http://undeadly.org/cgi?action=article&sid=20050824190317(...)
  
  Tu y trouveras la réponse à ta question concernant les performances :)

  • [^]Re: ...

    Posté par Victor STINNER (page perso, ) le 14/10/2005 à 09:51. (lien). Évalué à 10.

    Email de Theo de Raadt :
    

    To some of you, this will sound like what the Electric Fence toolkit used to be for. But these features are enabled by default. Electric Fence was also very slow. It took nearly 3 years to write these OpenBSD changes since performance was a serious consideration. (Early versions caused a nearly 50% slowdown).

    
    Pas de chiffre, mais apparement le patch malloc=>mmap a été pensé de telle manière à ne pas être trop couteux. Je trouve ça normal que OpenBSD tourne "un peu moins vite" que Linux vu la quantité de tests fait en plus. J'avais d'ailleurs vu un benchmark bête et méchant où OpenBSD était vraiment mauvais. Il faut en comprendre que OpenBSD utilise des algorithmes moins avancés (p-e O(n²) plutôt que O(n) par exemple) mais sûrement plus sécurisés. La sécurité a un prix, maintenant à vous de savoir si vous êtes prêt à vous faire voler vos données ou non (ou simplement que votre serveur soit pénétré) :-)
    
    Haypo

    • [^]Re: ...

      Posté par Sylvain Briole (page perso, ) le 14/10/2005 à 10:31. (lien). Évalué à 2.

      J'avais d'ailleurs vu un benchmark bête et méchant où OpenBSD était vraiment mauvais.
      
      Personnellement je me souviens de ceux là :
      http://bulk.fefe.de/scalability/(...)
      
      Je ne sais pas trop mais j'espère qu'OpenBSD s'est amélioré depuis, parce qu'il avait certaines lacunes à l'époque.

      • [^]Re: ...

        Posté par Krunch (Jabber id, page perso, ) le 14/10/2005 à 12:35. (lien). Évalué à 6.

        D'après des gens sur la mailing list OBSD, fefe est partial et son benchmark n'est pas représentatif d'une utilisation réelle mais il soulève quand même quelques problèmes. Mais apparement ça a été corrigé depuis http://diehard.n-r-g.com/stuff/openbsd/benchmark/(...)

        --
        Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
        pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.

      [^]Re: ...

      Posté par Vanhu () le 16/10/2005 à 12:14. (lien). Évalué à 10.

      La conclusion "algorithme moins optimal mais plus sécurisé" me parait un peu hative et douteuse, quand meme !!!
      
      Je n'ai plus en tete les algos exacts qui étaient en cause lors de ce test (qui n'est au passage PAS un test de conditions réeles d'utilisation), mais il me semble que, sur certains points, il a effecftivement mis en évidence certains algos pas du tout optimaux utilisés dans OpenBSD, et qui n'apportaient rien en terme de sécurité par rapport a d'autres algos plus performants.
      
      C'est un peu comme si quelqu'un disait qu'il utilise un bubblesort au lieu d'un quicksort (voire au lieu d'un algo encore plus efficace en fonction du contexte) pour des raisons de sécurité, c'est n'importe quoi !!!
      
      Maintenant, effectivement, ca arrive que des algos plus performants soient plus complexes a mettre en oeuvre, ou necessitent des "approximations", et que le tout puisse avoir un impact en terme de sécurité, mais faut pas non plus toujours tout excuser derriere le "securite avant tout" !!!
      
      Je dirais meme que, dans certains cas, le fait d'utiliser un algo vraiment pas optimal peut faciliter les possibilités de DoS, et génère donc des problèmes de sécurité !!!
      
      A +
      
      VANHU.

      • [^]Re: ...

        Posté par lasher () le 16/10/2005 à 21:30. (lien). Évalué à 3.

        D'ailleurs c'est tellement vrai que l'équipe de NetBSD en a profité pour corriger certains des défauts mis en valeur par le test, là où certains dév. d'OpenBSD ont grogné et prétexté la mauvaise foi de fefe.
        
        Cela dit, ils n'avaient pas totalement tort, vu que dans le test, ce dernier disait qu'il n'avait eu que des problèmes à l'install (si ça arrive, on peut dire que c'est la faute de l'OS, mais on peut aussi se demander si ce n'était pas un problème situé entre la chaise et le clavier).

    [^]Re: ...

    Posté par zero heure (Jabber id, page perso, ) le 14/10/2005 à 14:04. (lien). Évalué à 1.

    Tiens Jedi ça fait longtemps...
    J'ai encore dans mes petites docs 5 _longs_ posts de toi, absolument limpides, expliquant le fonctionnement de Reiserfs 3. Tu devrais venir plus souvent par ici!

    --
    J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm

  [^]Re: ...

  Posté par iouri () le 14/10/2005 à 20:48. (lien). Évalué à 5.

  > une nouvelle implémentation de malloc utilisant mmap permettant
  > de mitiger encore plus efficacement les buffer overflow et les
  > erreurs de programmation
  > C'est surtout la randomisation de la stack, du mmap et le fait que la
  > memoire soit directement munmapé apres le free qui permettent de
  > detecter plus facilement les erreurs de programmation : le
  > programme devrait segdefaulter des qu'il accede a une zone
  > memoire non alloué.
  
  Suis-je le seul à trouver ce post hilarant ? Au début, j'ai cru que c'était une blague, façon tRoU dU cULz hiDEoUt.
  Mais non, y a même des gens qui comprennent !

  • [^]Re: ...

    Posté par Sylvain Sauvage () le 14/10/2005 à 22:19. (lien). Évalué à 9.

    À la seconde lecture, effectivement. Le pire, c'est quand on se rend compte que :
    1. on le comprend ;
    2. on ne s'était pas aperçu de son côté, euh, cryptique.

    • [+] [^]Re: ...

      Posté par spotty () le 15/10/2005 à 18:30. (lien). Évalué à -2.

      eh oui encore une victime du pipotron :-)
      
      http://www.w3perl.com/fun/management/pipotron.html :-)
      
      a. ceux qui parle pour ne pas être compris ne font que du bruit.
      b. si on maîtrise vraiment un sujet, on peut l'expliquer simplement.