Journal Supervisor Mode Execution Protection

Posté par .
Tags :
11
20
mai
2011

Après NX les processeurs intel se mettent à supporter le SMEP [1].

Qu'est ce que c'est ?

C'est un NX un peu particulier : la mémoire taggé (via la mmu) avec ce flag ne pourra pas être exécuté en mode superviseur (ie en mode kernel).
Ca devrait empêcher certains exploits.

Ce qui est marrant c'est que l'on se rapproche de plus en plus de ce qu'offrait la segmentation sur les premiers processeur intel (une zone mémoire pour les data/stack/code en user et superviseur).

A quand le flag mmu pour la stack ?

[1].
https://lkml.org/lkml/2011/5/16/500

PS : ca n'aurait pas été plus propre de faire un "SMP" (Supervisor Mode Protection), ie une protection a la fois sur l'exécution et les data ?

  • # Accés kernel

    Posté par (page perso) . Évalué à 4.

    Pour la dernière question, non, le kernel a besoin d'avoir accès aux pages des applications !

    Les appels read/write/... passent l'adresse dans le contexte de l'application et le kernel doit le remapper et y accéder.
    L'avantage du SMEP est que ces mappages applicatifs ne seront pas exécutables si le kernel est corrompu (exemple: code malicieux qui suit un buffer qui a la mauvaise taille, driver buggé qui ne vérifie pas la taille du buffer et écrase ses propres pointeurs par des adresses contenue en user space, le SMEP stoppera l'exécution !).

    • [^] # Re: Accés kernel

      Posté par . Évalué à 2.

      Pour la dernière question, non, le kernel a besoin d'avoir accès aux pages des applications !

      oui mais dans le cas de linux, l'accès ce fait par un autre mapping (direct mapping).

      De plus on parle de page exécutable, je vois pas ce que le kernel ferais dedans.

  • # Segmentation: les SE en faute ?

    Posté par (page perso) . Évalué à 4.

    Ce qui est marrant c'est que l'on se rapproche de plus en plus de ce qu'offrait la segmentation sur les premiers processeur intel (une zone mémoire pour les data/stack/code en user et superviseur).

    Ce mode existe toujours (à ma connaissance), mais ce sont les SE, Linux par exemple, qui ne l'utilisent pas. La cause à "pas pratique" malgré le fait que les pages étaient censées palier le problème.

    • [^] # Re: Segmentation: les SE en faute ?

      Posté par . Évalué à 2.

      Je vais peut être dire une grosse ânerie mais la segmentation dont on parle elle est a taille fixe si je me souviens bien. Au démarrage le noyau crée le ou les segments et ce n'est plus modifiable, non ?

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Segmentation: les SE en faute ?

        Posté par . Évalué à 1.

        Linux n'utilise pas (plus) la segmentation ; c'est un concept trop peu répandu, du coup le MM n'utilise que la pagination qui est disponible dans quasiment toutes les MMU, ce qui rend le code de gestion de la mémoire portable.

        Linux met juste en place un flat memory model au démarrage sur IA32, mais il me semble que fs et gs sont quand même utilisés en particulier pour le stack protector. Au passage, la segmentation disparaît dans EMT64. En effet, il est nécessaire de passer en flat memory model avant de pouvoir basculer en 64 bit.

        • [^] # Re: Segmentation: les SE en faute ?

          Posté par . Évalué à 3.

          il me semble que fs et gs sont quand même utilisés en particulier pour le stack protector.

          fs et gs sont utilisé comme des registres (read_mostly) supplémentaire qui pointe sur des données. Ils servent pour implémenter les TLS (user/kernel) et le stack protector.

          Au passage, la segmentation disparaît dans EMT64.
          Sauf pour fs et gs : http://en.wikipedia.org/wiki/Memory_management_unit#x86-64

          C'est dommage qu'ils n'aient pas fournie une meilleur alternative...

      • [^] # Re: Segmentation: les SE en faute ?

        Posté par (page perso) . Évalué à 2.

        Les segments sont modifiables sans problème. Ca reste moins souple que d'utiliser les pages, mais c'est plus performant côté sécurité. Enfin historiquement, puisque maintenant le mécanisme des pages va avoir les mêmes avantages.

        Je me demande quel SE utilise les segments. Je crois qu'OS/2 Warp le faisait.

  • # Encore un journal imbitable

    Posté par . Évalué à 2.

    C'est un NX un peu particulier : la mémoire taggé (via la mmu) avec ce flag...

    J'ai pas été plus loin…

    • [^] # Re: Encore un journal imbitable

      Posté par (page perso) . Évalué à 3.

      J'avoue qu'une petite explication de ce qu'est un NX (sur le moment, j'ai pensé à Star Treck), et ce qu'est la mémoire tagguée, ca n'aurait pas été de trop pour rendre ce journal accessible aux néophytes.

      Opera le fait depuis 10 ans.

    • [^] # Re: Encore un journal imbitable

      Posté par . Évalué à 4.

      Faut quand même admettre que c'est plutot un journal d'hommes...

      ( http://www.youtube.com/watch?v=XqtH3n3QgYU )

    • [^] # Re: Encore un journal imbitable

      Posté par . Évalué à 6.

      Traduction: chaque page mémoire est marquée avec différents tags dont le plus récemment introduit (sur architecture x86) est le bit NX.
      Les tags sont en général R, W, X : la page est accessible en lecture, en écriture, ou en exécution.
      AMD a introduit le bit NX sur architecture x86 afin que les noyaux puissent rendre diverses zones mémoire non exécutable pour éviter certaines attaques (nom marketing : protection matérielle contre les virus). L'idée est qu'une page accessible en écriture ne soit pas exécutable, afin qu'un attaquant ne puisse pas insérer directement son code : toute donnée écrite par un programme n'est que des données, pas du code du programme lui-même.

      Cette saine pratique empêche également celle, malsaine en terme de sécurité, du code auto-modifiant (malsaine également pour les performances, les processeurs n'ayant pas dans l'idée que le code puisse être modifié, le cache instruction écronomise de la logique). La rumeur voudrait que ce soit cette raison qui ait rendu l'implémentation du bit NX tardive sous windows (à cause de Microsoft Office, pour les macros).

      • [^] # Re: Encore un journal imbitable

        Posté par . Évalué à 3.

        à cause de Microsoft Office, pour les macros

        wtf???

        • [^] # Re: Encore un journal imbitable

          Posté par . Évalué à 2.

          à cause de Microsoft Office, pour les macros

          wtf???

          Je ne sais pas si cette assertion est vraie ou non. Cependant, il serait envisageable qu'un interpréteur de macros génère des datas qui soient en fait des opcodes x86, qu'il exécute ensuite. Ca nécessite des pages W, pour y mettre les opcodes, et X pour exécuter ces opcodes. Un espèce de JIT, en gros.

          Attention, je n'ai pas dit que c'est ce que l'interpréteur de macros MSOffice faisait.

          Hop,
          Moi.

        • [^] # Re: Encore un journal imbitable

          Posté par . Évalué à 4.

          Il raconte n'importe quoi. l'OS fournit des APIs pour rendre des pages executables, ce qui permet aux VMs JIT de fonctionner sans probleme, creer ces APIs n'a certainement pas pris plus de quelque heures et les revoir/tester plus de quelques jours...

          Le support a ete ajoute dans XP SP2, sorti en Aout 2004, et elles sont apparues dans le kernel 2.6.8, sorti en Aout 2004... Il y avait bien les patchs Exec-Shield & PaX, mais PaX n'a jamais ete accepte car bcp trop invasif, et Exec-shield est sorti en 2003, mais n'a ete integre qu'a partir de RHEL 3 update 3, aux alentours d'Aout 2004...

          • [^] # Re: Encore un journal imbitable

            Posté par . Évalué à 7.

            Il n'y a pas que linux vs MS dans la vie :p
            «OpenBSD 3.3 shipped May 1, 2003, and was the first operating system to include W^X
            «W^X makes use of the NX bit on Alpha, AMD64, HPPA, and SPARC processors.»
            Avec en prime une émulation utilisant aussi les registres de segmentation pour les IA-32 n'ayant pas de bit NX; ce que Windows ne fait pas (ce n'est pas encore clair pour moi de savoir si linux sans PaX le fait). [source wikipedia]

      • [^] # Re: Encore un journal imbitable

        Posté par . Évalué à 2.

        Merci infiniment. C'est beaucoup plus clair.

      • [^] # Re: Encore un journal imbitable

        Posté par (page perso) . Évalué à 3.

        Euh .... On a pas NX = !X ?
        Si c'est le cas.... pourquoi rajouter un bit ?

  • # Quelques questions

    Posté par (page perso) . Évalué à 3.

    Apparemment tu en connais bien plus que moi sur la machine, aussi j'ai une question: des vagues souvenirs que je garde de mon expérience de programmeur asssembleur, il me semble qu'en mode protégé les tables LDT et GDT décrivent des pages (assoicées à une tâche pour la LDT) qui sont effectivement marquées avec des attributs de type R/W, un niveau de sécurité et si elles offrent une «trappe» permettant de gagner un niveau de sécurité.

    Comme tu le vois, je ne comprends pas ce qu'apporte le SMEP: je coryais que le code superviseur devait se marquer lui-même en déclarant qu'une intrerruption ou une adresse de procédure devait s'effectuer en mode superviseur. Ce serait super sympa si tu pouvais expliquer un peu la différence entre le SMEP et ce qui est déjà disponible sur les i386 via les LDT/GDT.

    • [^] # Re: Quelques questions

      Posté par . Évalué à 4.

      LDT et GDT décrivent des segments. La majorité de la protection sur x86 se situait dans les segments, mes ces derniers n'étaient pas utilisés. Il a donc fallu introduire plus de protection dans les pages (surtout maintenant que l'amd64 supprime encore plus les segments)

Suivre le flux des commentaires

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