Journal X11 sans droit root

Posté par  .
Étiquettes : aucune
1
13
mai
2008
Un des points faibles de X11 pour la sécurité est qu'il s'exécute avec les droits root.
Avec kernel mode-setting (+ un petit patch), il est possible de faire tourner X11 comme une appli "normale" :
http://airlied.livejournal.com/59521.html

Ça concerne le long terme car il faut utiliser kernel mode-setting (il n'y a que les puces Intel actuellement).

Vu sur http://www.osnews.com/

  • # ...

    Posté par  . Évalué à 10.

    Un des points faibles de X11 pour la sécurité est qu'il s'exécute avec les droits root.
    Et maintenant on fait tourner une partie des drivers video (avec potentiellement des interpréteurs pour parser les tables du bios) en mode kernel.

    • [^] # Re: ...

      Posté par  . Évalué à 2.

      Pour AMD les scripts interprété ne font pas grand chose et on peut facilement les restreindre à des parties non sensible des cartes ie leur interdire le DMA. Bref je doute fortement que cela soit une vecteur d'attaque pour compromettre la sécurité d'un système.

  • # Le futur ?

    Posté par  . Évalué à 4.

    # ps aux | grep X
    _x11 15199 4.6 3.2 9692 33180 ?? S 11:44PM 1:05.09 X -br -nolisten tcp (Xorg)
    root 3455 0.0 0.1 1768 1060 ?? I 11:44PM 0:04.13 X: [priv] (Xorg)

    Wow. Et sans faire tourner de cochonneries supplémentaires en mode kernel.

    • [^] # Re: Le futur ?

      Posté par  . Évalué à 10.

      Exact, le xorg d'OpenBSD est patché pour révoquer ses privilèges très tôt, et depuis longtemps (mais le - petit - processus root restant continue à accéder à l'espace mémoire global, d'où le machdep.allowaperture sur x86).

      Ce que viens de faire David Airlie, si j'ai bien compris, est nouveau : il s'agit d'un X11 avec le DRI etc, qui n'a pas besoin de deviser directement d'un accès direct au périphérique PCI / à l'espace dma, ce travail naturellement noyau étant délégué au TTM. C'est un superbe progrès.

      Pour le "Ça concerne le long terme" du journal : peut-être, mais surement pas à cause du modsetting : ce dernier est vraiment en voie d'intégration imminente parrait-il.

      • [^] # Re: Le futur ?

        Posté par  . Évalué à 1.

        Le modesetting ? Ce n'est pas déjà intégré, du moins pour le module intel ? Ça fait quelque temps que la ML ne parle plus de la fameuse "branche modesetting" de ce pilote (c'est-à-dire qu'elle a fusionné avec le tronc) !

        • [^] # Re: Le futur ?

          Posté par  . Évalué à 6.

          Non ce n'est pas intégré et je pense qu'il faudra attendre la fin de l'année avant que cela le sois, 2.6.27 dans le meilleur des cas ou 2.6.28. Une fois que c'est intégré on peut plus changer l'API avec le monde extérieur donc il vaut mieux être prudent.

          • [^] # Re: Le futur ?

            Posté par  . Évalué à 1.

            Ah mais tu parles d'intégration au noyau. Au temps pour moi !

  • # Y a encore du chemin...

    Posté par  . Évalué à 3.

    En effet, il y a toute une batterie de composants à déplacer dans le kernel pour avoir un X11 sans les droits root et un suspend/resume sans hack tout moche.
    D'abord, il y a le video mode setting. Il s'agit ici de programmer les modes video. La grande nouveauté n'étant pas seulement son déplacement dans Linux mais surtout un nouveau modèle de programmation aussi, voir plus, flexible que ce qu'on peut trouver en mode utilisateur (l'extension RANDR 1.2 et la 1.3 est en brainstorming). En terme de support matériel, et bien on a Intel qui est loin devant et AMD(ATI) qui rattrape son retard et NVIDIA qui dort (et y a VIA qui semble commencer à bouger). Intel et AMD(ATI) fournissent code et les manuels de programmation de leurs GPUs, et ils les améliorent régulièrement. Les interfaces pour la programmation des modes vidéo semblent assez stables mais il y a des discussions pour ajouter/modifier/renomer de nouveaux objets dans le modèle. Tout n'est pas rose, il y a beaucoup de code de plomberie et ce code s'intègre maladroitement dans le driver model de Linux. Il serait préférable de faire une couche de plomberie minimale bien intégrée au driver model de Linux.
    Mais programmer un mode vidéo signifie qu'il faut fournir à toute cette machinerie un frame buffer. Donc, les interfaces de programmation d'un mode vidéo sont dépendantes des interfaces de mise en place d'un frame buffer, et c'est là qu'intervient le TTM. Et aujourd'hui programmer la mémoire vidéo est en train de rattraper la complexité de nos chers CPUs avec leur RAM.
    Donc la modernisation de la pile graphique de Linux est en cours.

    • [^] # Re: Y a encore du chemin...

      Posté par  . Évalué à 7.

      De mon point de vue, et je code principalement pour le matos AMD, nouveau est plus avancé que le code pour radeon donc mon classement ça serait Intel, Nouveau, AMD.

      Ensuite TTM est un memory manager c'est complétement orthogonale au modesetting. Pour faire une caricature grossière et pas tout à fait exacte aujourd'hui le memory manager estime que le contenu de la mémoire video est perdu à chaque changement de client (programme) et à chaque fois que ca arrive on retransmet l'ensemble des objets (textures, ...) évidement c'est débile mais ce schéma était tout à fait satisfaissant quand les carte video avaient 4 ou 8 Mo de ram :)

      Aujourd'hui on perd énormement de temps à copier depuis ou vers la ram video et on a donc besoin d'un gestionnaire de mémoire. Et c'est le rôle de TTM (qui n'est qu'une partie d'un gestionnaire de mémoire). Pour le moment rien n'est arrété sur le choix du memory manager.

      Donc le modesetting peut fonctionner sans TTM.

      • [^] # Re: Y a encore du chemin...

        Posté par  . Évalué à 3.

        Donc le modesetting peut fonctionner sans TTM.
        Alors comment on fait pour mettre en place les frames buffers que le mode setting va devoir utiliser? Il me semble que nouveau utilise des BOs (buffer objects) à ces fins (du moins je crois l'avoir aperçu). L'objet framebuffer du kernel modesetting actuel semble être là uniquement pour assurer la compatibilité avec les anciens drivers fb. Il me semble aussi que le mode setting le plus fonctionnel pour les GPUs nvidia est celui du user space avec RANDR 1.2 et non le kernel mode (mais j'ai pas vérifié). Perso, je focalise uniquement sur le mode setting des NV50 et au-dessus mais, en ce moment, surtout sur une plomberie kernel plus "Linux driver model" et GPL.

        • [^] # Re: Y a encore du chemin...

          Posté par  . Évalué à 2.

          Quand je dis que c'est orthogonale ca veut dire qu'il a une intersection, je suis balaise en math moi ;d, et l'intersection c'est le fait que le modesetting a besoin d'allouer de la mémoire. Mais le modesetting il s'en fout du gestoinnaire de mémoire sous jacent et c'est le point auquel je voulais en venir en disant que c'est orthogonale (expression souvant utilisé sur lkml d'ailleurs :)) Donc le modesetting il peut fonctionner avec ttm ou toto ou brouzouf tant que ca lui permet d'allouer la mémoire qu'il veut.

          Ensuite le modesetting pour moi c'est une part importante du travaille mais pas l'essentiel et pas la plus grosse. Et sur le reste gallium et userspace nouveau est plus avancé que radeon. Ok pour les nv50 et après c'est pas ça mais sur AMD on en est pas plus loin sur r600 & compagnie.

          C'est dingue ça je défends nouveau :o) marcheu t'es ou ?

          • [^] # Re: Y a encore du chemin...

            Posté par  . Évalué à 2.

            Quand je dis que c'est orthogonale ca veut dire qu'il a une intersection
            Ok ok ok, au temps pour moi. On est donc d'accord que le mode setting utilisera les services d'un memory manager pour ses frame buffers.

            Ensuite le modesetting pour moi c'est une part importante du travaille mais pas l'essentiel et pas la plus grosse.
            En effet, c'est loin d'être la partie la plus amusante, loin d'être la plus compliquée. Le tout est que le user y trouve suffisament de flexibilité avec un suspend/resume propre.

            Et sur le reste gallium et userspace nouveau est plus avancé que radeon.
            Il me semble que marcheu bosse sur une implémentation 100% software de Gallium3D. Je ne sais pas si il a fait des fallbacks soft de nouveau sur cette implémentation 100% soft.

            C'est dingue ça je défends nouveau :o) marcheu t'es ou ?
            Muh??? Mais je n'attaque pas nouveau! Pour ma part, c'est avant tout un projet de reverse engineering. Je tique personnellement sur le DRM et la licence. Mais j'assume mes choix: je fais du code à côté mais le savoir sur les GPUs nvidia est centralisé dans nouveau.
            :-p

          • [^] # Re: Y a encore du chemin...

            Posté par  . Évalué à 2.

            Quand je dis que c'est orthogonale ca veut dire qu'il a une intersection, je suis balaise en math moi

            Il me semble que quand on parle d'orthogonalité de deux concepts, on fait justement référence au fait qu'ils n'ont rien de commun (dans un repère orthogonal, le fait de te déplacer selon un axe ne change en rien ta position par rapport à l'autre).

            • [^] # Re: Y a encore du chemin...

              Posté par  . Évalué à 1.

              > dans un repère orthogonal, le fait de te déplacer selon un axe ne change en rien ta position par rapport à l'autre

              Je ne suis pas pointu en math, mais il me semble que c'est comme ça pour tout repère.

              • [^] # Re: Y a encore du chemin...

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

                Non justement, c'est seulement si le repère est orthogonal ;)

              • [^] # Re: Y a encore du chemin...

                Posté par  . Évalué à 2.

                non.
                Un repère peut etre fait avec une base non orthonormal.

                Il faut juste pouvoir définir tous les points de l'espace grace au repere :
                exemple con, soit un espace 3D de repère orthonormal X,Y,Z (je fais pas les flèches toussa).
                si je fait une base
                A=X
                B=Y+X
                C=Z+X
                il est possible de trouver n'importe quel point dans le repère formé par (A,B,C), mais B n'est pas orthogonal ni à C, ni à A., et B et C n'ont pas le même cardinal que A (c'est bien ça non ?)

                • [^] # Re: Y a encore du chemin...

                  Posté par  . Évalué à 1.

                  Je ne vois pas le rapport.
                  Dans tout repère (et un seul), si tu changes, par exemple, l'ordonnée d'un point, ben tu ne changes pas les autres coordonnée (par définition).
                  Ceci pour un même repère.
                  Pour différentes repères, qu'il soient orthonormé ou autre c'est faux (pas forcément vrai).

                  • [^] # Re: Y a encore du chemin...

                    Posté par  . Évalué à 2.

                    > c'est faux (pas forcément vrai).

                    Sauf si les repères ont les mêmes axes (quelque soit la norme). La passage d'un repère à un autre est alors une translation suivant qu'un axe.
                    Deux repères orthogonaux n'ont pas forcément les mêmes directions. On peut passer de l'un à un autre avec une translation, une rotation, etc.

            • [^] # Re: Y a encore du chemin...

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

              Quand je dis que c'est orthogonale ca veut dire qu'il a une intersection, je suis balaise en math moi
              effectivement ...

              Il me semble que quand on parle d'orthogonalité de deux concepts, on fait justement référence au fait qu'ils n'ont rien de commun
              J'aurai dit pareil, mais je n'ai pas de dico sous la main. D'ailleurs, je cherche encore l'intersection de mes vecteurs orthogonaux !

              dans un repère orthogonal, le fait de te déplacer selon un axe ne change en rien ta position par rapport à l'autre
              Pour la position, pas besoin de l'orthogonalité, mais par contre, si le repère n'est pas orthogonal, les produits scalaires avec les vecteurs de base peuvent changer, même pour les vecteurs autres que celui du déplacement.

              • [^] # Re: Y a encore du chemin...

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

                Il me semble qu'orthogonal se définit en étant le contraire de parallèle. Après en ce qui conerne l'intersection, cela dépend de tes objets et de ton espace.

                deux droites orthogonales dans le plan sont perpandiculaires et ont pour intersecton un point.

                deux droites orthogonales dans l'espace n'ont pas forcément d'intersection. Elles n'en ont une que si elles sont perpandiculaires.

                une droite orthogonale a un plan dans l'espace coupe le plan en un point

                ...

                Et:
                perpandiculaire => orthogonal
                mais l'inverse n'est pas vrai

                en tout cas c'est ce que j'avais appris au lycée.

Suivre le flux des commentaires

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