Journal "Improved Memory Allocation" dans OpenBSD 3.8

Posté par  (site web personnel) .
Étiquettes :
0
24
août
2005
La prochaine release d'OpenBSD (la 3.8) contiendra une nouvelle façon de gérer les allocations de mémoire. En gros ce sera plus sécurisé et plus strict qu'avant.
Theo de Raadt a lancé un appel aux tests car cette nouveauté risque de casser les logiciels qui sont mal codés.

Questions pour ceux qui savent :
1) En quoi cette "amélioration de l'allocation mémoire" est elle différente des patchs PaX ou GRSecurity qui existent déja pour Linux (et qui sont je crois inclus dans la Fedora non ?)
2) Quel sera la pénalité au point de vue vitesse ?
3) est-ce prudent/logique/normal/risqué/aberrant de changer ainsi le fonctionnement de routines aussi importantes que malloc ou mmap ?

Vu sur http://kerneltrap.org/node/5584(...)

  • # Choix cornélien

    Posté par  . Évalué à 5.

    Je ne commenterai pas les points 1 et 2, ne m'étant pas plongé dans les méandres du code.

    Concernant le point 3, c'est effectivement un problème crucial et général. Il arrive malheureusement que des programmes dépendent, volontairement ou non, de détails d'implémentation qui sont suceptibles de changer à tout moment (effets de bord, fonctions non documentées, etc.).

    Je pense qu'on ne devrait pas se retenir de changer (et améliorer) une implémentation sous prétexte que des programmes bogués en dépendent. Comme le dit Theo, c'est un peu dur au début, le temps de corriger les programmes, mais au final tout le monde y gagne : le système étant moins laxiste, il laisse passer moins de bugs.

    Mais c'est parfois plus facile à dire qu'à faire. Microsoft, garant de la sacro-sainte compatibilité, a souvent préféré faire l'inverse. Le blog « The Old New Thing » de l'un des programmeurs du noyau de Windows regorge d'histoires croustillantes expliquant certains choix techniques pris historiquement par Microsoft (au hasard http://blogs.msdn.com/oldnewthing/archive/2003/12/24/45779.aspx(...) ). Je me rappelle notamment qu'une faille avait dû être insérée dans le noyau de Windows 95 uniquement car Sim City en dépendait, et sortir un nouveau Windows incompatible avec l'un des jeux phares du moment aurait été impensable (invendable).

    • [^] # Re: Choix cornélien

      Posté par  (site web personnel) . Évalué à 2.

      j'espère surtout que les devs d'OpenBSD ont bien calculé leur coup car cela fait penser aux problème de VM des Linux 2.4...bouger un gros truc d'un coup c'est risqué pour les applis user mais aussi pour la stabilité du kernel lui même.

      • [^] # Re: Choix cornélien

        Posté par  (site web personnel) . Évalué à 1.

        d'un autre coté, on est encore assez loin de la release d'openBSD 3.8 donc il y a du temps pour tester.

      • [^] # Re: Choix cornélien

        Posté par  (site web personnel) . Évalué à 5.

        Ca s'est pas fait en un coup, d'après l'email de de Raadt ils y travaillent depuis presque 3 ans. Et c'est bien pour voir les problèmes que ça pose qu'ils font une béta avant de mettre ça dans la release stable (en novembre normalement). Vu les changements je pense qu'on trouvera quand même plus de bugs dans les applications tiers que dans le noyau.

        À plus ou moins long terme ça ne peut être qu'une bonne chose: ça va permettre de découvrir et corriger beaucoup de bugs dans beaucoup de programmes (il suffit de voir l'exemple de X qui est cité).

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: Choix cornélien

        Posté par  . Évalué à 4.

        1) Si la nouvelle implantation introduit des bugs (de jeunesse) dans les biblios et/ou le kernel, effectivement c'est génant (peu probable car ils bossent dessus depuis longtemps).

        2) Si la nouvelle implantation met à jour des bugs dans des applis codées avec les pieds c'est en revanche bénéfique (car les bugs des applis seront corrigés, ce qui d'ailleurs profitera à tout le monde utilisant les applis en question).

        Un bug qu'on ne voit pas est infiniment plus dangereux qu'un bug qu'on repere et qu'on corrige.
        Un bug d'allocation mémoire qui ne se repere pas à cause d'un fonctionnement particulier d'une implantation de malloc/free est on ne peut plus pernitieux (nuit à la compabilité, nuit à la sécurité, nuit à la maintenance, etc...) .

        • [^] # Re: Choix cornélien

          Posté par  . Évalué à -10.

          En fait, OpenBSD, l'OS dont la base d'utilisateurs se résume à 3 intégristes en tout et pour tout dans le monde entier, euh, on s'en fout un peu.

          Mon code ne tourne pas sous OpenBSD ? Mince alors, je perds 3 utilisateurs potentiels. De toute façon, s'il est sous GPL, ils ne s'en seraient pas servi de peur d'être contaminés.

          • [^] # Re: Choix cornélien

            Posté par  (site web personnel) . Évalué à 7.

            Compte créé le mercredi 24 août à 20:24
            On voit que certaines personnes ont les c***ll*s pour dire des conneries et les assumer.
            En lisant ton post, j'ai hésité entre très mauvais humour ou personne à temps de latence élevé dans la tête.

            J'avoue qu'à l'heure actuelle j'hésite toujours.

            (et désolé pour ceux qui liront ma "pseudo" réponse, mais voir ce genre de post me...)

  • # Points 1) et 2)

    Posté par  (site web personnel) . Évalué à 2.

    D'après ce qu'on peut lire sur le kerneltrap, il y a essentiellement trois modifications :
    La mémoire est allouée en un emplacement aléatoire, ce qui rend plus difficile la création de shellcodes (existe dans Grsec, faible impact sur les perfs je pense).
    Mais en plus, on évite d'allouer deux zones adjacentes, histoire d'éviter qu'elle finisse par se recouvrir (ça je crois pas que ça existe sous GNU/Linux, mais c'est possible).

    Idée de "guard page", allouée aux extrémités des plages mémoires légitimes et qui risquent d'être un peu comme les canaris du compilateur de windows : des zones qui si elles sont altérées provoqueront l'arrêt brutal du programme. Ça a été implanté dans GCC sous le nom de SSP, justement par les gars d'OpenBSD je crois, donc à priori c'est la même chose que sous Linux. Par compte je crois que ça a des effets sur les perfs, au point que microsoft interdit de diffuser des benchs de windows 2003 (qui y a recours).

    Et apparement free() libère de suite la mémoire, je suppose qu'avant la libc5 la gardait sous le code pour limiter les appels système.

    Et pour le 3)... à priori les problème de compatiblité ont déjà être du bien balayés par la disponibilité sous Linux depuis un certain temps d'un grand nombre des techniques présentée.

    • [^] # Re: Points 1) et 2)

      Posté par  (site web personnel) . Évalué à 2.

      Les "guard pages" n'ont rien à voir avec les canaris/SSP, le canari est une valeur bien précise qui se place sur le stack entre l'adresse de retour et les paramètres. Ca se fait au niveau du compilateur. Alors que la page de garde (si j'ai bien compris) est une page "vide" entre deux autres pages mémoires et ça ça se fait au niveau de la gestion de la mémoire par l'OS/la libc.

      SSP/ProPolice est bien utilisé dans OBSD (et DFBSD d'après Wikipédia) et j'ai cru comprendre que les développeurs OBSD ont passé pas mal de temps à bidouiller dessus mais c'est pas eux qui l'ont crée.

      La plupart de ces mesures de sécurité ont effectivement des impacts plus ou moins grands sur les performances mais au final ça ne peut être que bénéfique.

      AFAIK, aucune des ces mesures de sécurité (guard page, malloc randomisation, free(3) qui munmap(2) à tous les coups ou presque) n'est implémentée dans le noyau Linux normal.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: Points 1) et 2)

        Posté par  (site web personnel) . Évalué à 3.

        Pour le free qui munmap, l'intérêt c'est plutôt que malloc utilise systématiquement mmap (qui est randomisé) au lieu de (s)brk(2) je pense. Et évidemment c'est pas une feature du kernel, contrairement à ce que peut faire penser mon commentaire précédent. Mais la glibc utilise bien (s)brk(2).

        Tout ça pour dire que ça c'est certainement pas dans PaX/grsec et donc que des bugs on va en trouver.

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Suivre le flux des commentaires

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