• # Points 1) et 2)

    Posté par (site web personnel) . En réponse au journal "Improved Memory Allocation" dans OpenBSD 3.8. É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.