Oui, c'est la même idée car faire du pattern-matching entre deux images pour vérifier qu'une appli est pas en train de se faire passer pour la fenêtre de mot de passe, c'est pas facile ;)
Une autre possibilité, c'est d'animer la fenêtre différemment. Avec Wayland, les applications peuvent pas se bouger seules si je me souviens bien (elles disent juste au compositeur "à partir de maintenant, tout mouvement de souris et jusqu'à ce que le clic soit laché, tu bougeras ma fenêtre"). Du coup, on peut faire apparaitre la fenêtre différemment tant qu'on tape pas son mot de passe.
En tout cas, c'est encore clairement un problème ouvert!
J'ai vu ça, oui, mais dans les faits, tu as un exemple utile à part pour empêcher qu'une appli contrôle les inputs de la fenêtre de l'UAC?
Un programme est lancé par défaut en IL medium (si je me souviens bien) avec possibilité de le descendre (ce que fait IE, adobe reader et chrome). Du coup, un programme non privilégié classique a le droit de modifier les autres applications non privilégiées. Donc, au final, c'est maigre comme sécurité.
Ok ! Ça commence à devenir plus clair dans ma tête. C'est de la que venait mon commentaire : "Est que l'on est pas en train de dire que comme les utilisateurs n'installent pas tous un système de sécurité avancé alors on en impose un dans le processus pour leur propre bien".
Non, tu avais raison, ce sera la politique par défaut des compositeurs Wayland et elle sera paramétrable automatiquement par les packageurs des distros.
Je pensais que c'était un module forcé par défaut dans le système alors que ça serait plus un exemple d'implémentation.
Non, c'est pas une politique d'exemple non et oui, ça sera vraisemblablement forcé sur le système de la même façon que X a sa/ses politique(s) de sécurité forcée. Tu devrais être content car la politique que je propose est bien plus configurable que celle de X qui est compilée dans le binaire et qui n'est pas paramétrable.
La dernière chose que je veux, c'est une politique open bar par défaut pour les utilisateurs qui ne veulent pas accepter qu'ils sont différents des autres et qui ne veulent pas prendre 2 secondes pour cliquer sur "j'accepte" ou 2 minutes pour "écrire la politique de 5 lignes" si la distro ne lui a pas fourni.
Je prend la sécurité du serveur graphique très au sérieux car c'est le point le plus délicat pour sécuriser un OS avec interaction utilisateur. Pour te donner une petite idée, j'ai commencé à bosser sur ce sujet il y a 5 ans, avec une équipe de recherche à l'ENSI de Bourges et ça a donné ces résultats (PIGA-SYSTRANS et PIGA-OS).
Ok, mon incompréhension vient peut être tout simplement de la, l'article étant long j'ai du mal comprendre une partie.
C'est compréhensible, en effet ;)
Pour mieux comprendre, dans l'article il est proposé des fichiers de configuration pour le module de sécurité (comme /etc/wayland/…). Qui se chargerait d'évaluer et interpréter ces fichiers ?
Ce cas là, c'est quand on utilise aucun moteur de décision externe. Du coup, ça sera simplement un .so référencé par la bibliothèque d'abstraction de prise de décision.
Effectivement il faut prévenir. Mais je ne suis pas sur que ça justifie que wayland doit être le module décisionnaire la dedans.
Oh, tu as mal lu la fin de l'article. L'idée, c'est de déléguer la prise de décision à une bibliothèque qui permettra d'abstraire le moteur de décision. Comme ça, tous les compositeurs devront juste demander à la bibliothèque quelle décision prendre ce qui devrait pas impacter les compositeurs en terme de volume de code. De plus, si un nouveau modèle de prise de décision apparaît, pas besoin de modifier tous les compositeurs ;)
Est que l'on est pas en train de dire que comme les utilisateurs n'installent pas tous un système de sécurité avancé alors on en impose un dans le processus pour leur propre bien ?
Non. Ces systèmes avancés couvrent d'autres choses et complètent la sécurité nécessaire dans Wayland (notamment pour contrer les attaques proposées par pasBillpasGate). Aucun de ces outils ne sait contrôler les actions utilisateur directement, c'est au compositeur de remonter ces informations.
Avez-vous regardé ce qui se fait sur Windows ou MacOS par ex ?
Je ne sais pas si c'est sécurisé chez eux, mais ils se sont peut-être déjà posé les mêmes questions.
C'est en effet une bonne suggestion et c'est pas super beau à voir non plus ;)
Je suis d'accord sur le fait qu'il y a un problème et que c'est une solution. Je me demande juste si c'est la meilleure façon de faire.
Je suis convaincu que c'est le seul choix qui ait un sens.
Ce qu'il me semble important c'est que ce processus donne des outils pour détecter les utilisations avec risque pour la sécurité.
Détecter, c'est bien. Prévenir, c'est mieux. Comme je le disais plus haut, les anti virus et pare feu sont plus des rustines que des solutions de sécurité. Bon, c'est surtout les AV qui sont par natures pratiquement inutile, les pare feu sont très justifiables aussi dans pas mal de cas.
Ce que je veux dire, c'est que c'est au programme qui exporte un service de faire le contrôle d'accès, pas à quiconque d'autre. Oui, ça demande à réfléchir quand on fait le service mais bon, c'est la vie.
Pour information, je suis un vrai néophyte dans ces domaines (server graphique/sécurité) donc c'est un point de vue naïf que j'ai. Mes remarques sont faite dans le but de m'instruire, non de critiquer gratuitement le travail de réflexion que vous avez fait ;)
Fait une analogie à une organisation qui fourni un service, genre demande de passeport. Ce que tu proposes, c'est qu'on donne un passeport à chaque personne qui le demande, sans contrôle d'identité, puis d'avoir la douane juste derrière pour vérifier. Si tout va bien, la personne arrivera pas à faire sortir le passeport par une voie cachée, mais rien n'est garanti à partir du moment où tu le lui donne. Si tu fais les vérifications avant de lui donner, il y aura accès uniquement si il y a droit et y'a moins de risques de fraude.
Cela me semble pas du ressort de ce composant système. Autant permettre l'identification des programmes utilisant une fonctionnalité de capture est quelque chose de bénéfique pouvant servir a détecter des programmes malicieux, autant en contrôler directement l'accès me semble être un pas trop loin.
Si un service ne fait pas de contrôle d'accès avant de fournir son service, qui doit le faire? Un "parefeu" système? Faut pas confondre un hack avec une solution.
Il y a un seul process sur la machine qui a autant de vision sur la volonté de l'utilisateur, ne pas faire le contrôle d'accès dans ce process (qui est en plus le producteur du service), c'est se tirer dans les pieds à coup de bazooka!
Je ne dis pas que Wayland n'apporte rien, je dis que les objectifs cites dans ce papier sont un peu illusoire car leur realisation depend de bcp plus que Wayland.
Tu as totalement raison, mais je ne parle ici QUE de la sécurité liée à Wayland. Tant qu'on pourra injected du code dans les applis à coup de LD_PRELOAD, la sécurité des desktops sera nulle. Cependant, avec du contrôle d'accès mandataire, tu peux limiter un processus au chargement de bibliothèques depuis /usr/lib/. Ça suffirait pour fixer la majorité des cas. Il reste ensuite le fait que tous les fichiers sont visibles par tous les processes et il faudra un daemon brocker pour résoudre ce problème là et on sera bon.
Qu'on se comprenne, l'objectif est louable et serrer les boulons est tres bien, mais il faut etre realiste quand a ce qui est possible. Bloquer les methodes courantes c'est bien, mais ca ne changera absolument rien si je peux toujours mettre ma librairie dans LD_PRELOAD et lancer Firefox, injecter mon code a travers ptrace, …
Comme dit un autre commentaire, on ne fait que fermer une fenêtre, les autres sont toujours ouvertes par défaut … pour l'instant (le MAC suffit à les résoudre). Ne rien faire, c'est recommencer les conneries de X et c'est pas acceptable. Un pas après l'autre, on peut pas révolutionner le desktop tout d'un coup.
Pense par exemple que tu as un pager qui affiche une miniature d'une fenetre ouverte sur un desktop virtuel que tu ne vois pas autrement, a quoi cela sert-il de rafraichir son contenu en haute resolution a 60fps ?
Oui, c'est une remarque valable, il me semble que ça a déjà été proposé. La solution proposée était de faire du throttling coté compositeur. Le compositeur pourrait aussi envoyer un signal quand l'appli est ou n'est plus visible. L'appli pourra ensuite choisir de faire ce qu'elle veut (continuer à rendre à 60 fps ou se limiter à 1 fps).
Pourquoi une liste serait dans un plan différent, ça apporte quoi? Ne pas avoir à re-rendre la liste?
Tu decoupes la liste en 3 morceaux de chacun 2/3 de la taille de la liste a l'ecran. Tu remplis chaque morceau en avance, puis tu ne fais que deplacer les elements. Quand tu depasses les 1/3 de la liste dans une direction ou dans l'autre, tu ne redessines en asynchrone qu'un des trois buffers. Ca limite grandement les chances de frame drop et tu as une tres faible utilisation CPU et GPU, donc basse consomation et fonctionne sur une plus grande gamme de materiel.
C'est sûr que si la liste est gigantesque, vaut mieux faire ça :) On est d'accord!
Je sais pas à quel vitesse on peut allouer un plan, mais ça devrait pas être trop lent.
En general, c'est tres lent et on est oblige (en tout cas sous X) de faire des caches pour ne pas en allouer trop souvent. Il ne faut pas obliger que entre deux images, on n'a que 16ms pour tout faire…
Ce sera à tester, mais c'est en effet une raisonnement valide ;)
L'exemple le plus simple, c'est une application qui n'a plus le focus et donc n'a plus d'activiter. En forcant l'utilisation permanente de buffer, tu augmentes la consomation de memoire de tes applications en tache de fond. Certe on pourrait juste eviter la negociation et se dire que des qu'une application est en tache de fond, alors on peut juste droper les buffers et faire un rendu flat.
Avec le compositing, une appli ne sait jamais si elle est visible ou pas, et c'est très bien comme ça sinon ça pose d'autres problèmes.
Autre exemple, ou on aurait un benefice, tu as une application avec deux listes qui necessites donc normalement 2+3*2 plans.
Pourquoi une liste serait dans un plan différent, ça apporte quoi? Ne pas avoir à re-rendre la liste? Typiquement, les plans doivent être utilisés quand tu as des sources de données de format différent. Par exemple, un lecteur vidéo: Un plan pour la vidéo et un plan pour les overlays. Ensuite, si une appli n'a plus besoin d'une sub-surface, alors elle n'a qu'à la libérer. Je vois vraiment pas en quoi le fait de savoir quels plans sont disponibles va aider les applis, elle peuvent utiliser les sub-surface qui sont une abstraction des plans qui seront rendus en matériel ou en shader, suivant le matos.
Je sais pas à quel vitesse on peut allouer un plan, mais ça devrait pas être trop lent.
La question du test n'est pas un vrai probleme, car la logique de gestion des plans cote toolkit est quelque chose de similaire quelque soit le backend (software ou GL). Il est donc envisageable de simuler le fonctionnement sans dependre du protocol Wayland (Et rendre le debuggage tout a fait jouable). Pour ce qui de l'avantage, plus tu demandes de travail au serveur alors que ce n'est pas necessaire. Tu augmentes la charge de travail et donc la consomation d'energie. Probablement aussi reduit les performances du systeme. Mais il est vrai qu'il faudra faire le test pour en etre certain.
Au final, si une application a différentes surfaces, elle n'a qu'à les envoyer en suivant le protocole des sub-surfaces et le compositer dispatchera sur les planes dispo et compositera le reste avec des shaders. C'est exactement ce que je disais avant et pas besoin de négociation. Ça n'apporte rien et au contraire, le toolkit fera une décision merdique quoi qu'il arrive car le compositeur peut à chaque image choisir comment dispatcher les surfaces alors qu'avec ta négociation, il sera bloqué (les applis n'ont pas à savoir quelle partie de leur fenêtre est présentement visible et ne peuvent donc pas "libérer" des planes). Je ne parle même pas du cas du screenshot/screen capture.
Cite moi des cas pratiques où la négociation apporte des avantages et on verra si ça a vraiment un sens (je suis vraiment sceptique).
Nop, il faut une "négociations", sinon tu te retrouve a devoir gérer plus d'information côté compositer que nécessaire ! De plus les sub surface ne gèrent pas le clipping de manière suffisante si je me souviens bien pour cette tâche. Il sera nécessaire d'étendre le protocole.
Euh, même si tu faisais de la négociation, tu seras toujours obligé de supporter l'upload des BO sur planes et le compositing GL du reste. Du coup, je vois pas ce que ça t'apporte en terme de complexité si ce n'est de rendre l'exécution des applications plus complexe (imagine les cas où 3 planes seront dispo, ça marche et quand y'en a 4 ou 6, ça marche plus, va debugger ça!).
Pour les subsurfaces qui supportent mal le clipping, faut étendre le protocole.
Je ne vois pas pourquoi. Tu as de toute façon accès a tous les buffer. Mais je n'ai pas regarder cette aspect plus que de manière théorique pour l'instant.
Au final, ce que tu proposes, c'est de faire exactement ce que je propose avec en plus une phase de négociation pour le nombre de plane. Ça n'a de sens que si tu veux garantir des performances GL. Ça me semble vraiment pas utile vu le coup du compositing.
C'est pas à moi ce code. On me l'a donné sur #nouveau mais je me souviens plus qui l'a écrit. Enfin, c'est juste une lecture de l'indicateur de batterie et c'est super dépendant du matériel.
Regarde dans /sys/class/power_supply/BAT0/, tu devrais trouver ton bonheur :)
Tu sais, écrire direct dans la VRAM, c'est faire une copie d'un registre à une adresse mémoire. Là, je te parle pas de faire une copie de tout l'écran, je te parle de copier les différences. Que ce soit le CPU qui fasse ça ou le GPU, c'est pareil.
Pour gagner un peu de temps, tu peux me décrire comment activer le rendu CPU ?
Ctrl + alt + F12
XRender est tjs accéléré par le GPU, donc c'est pas la solution.
Ah, mais si, c'est au toolkit de gérer ça !
Et comment tu fais ton protocole de réservation de plane? Si tu veux utiliser plusieurs planes dans Wayland, tu utilises les subsurfaces. Les fenêtres et les sub-surfaces seront mappées sur les différents planes sans que l'application ait besoin de connaitre quoi que ce soit. Donne moi un cas où ça ne marcherait pas?
Comme je disais, l'application doit donner ses buffers graphiques et indiquer comment faire la composition interne de ses subsurfaces. Ensuite, c'est au compositeur de faire de son mieux.
Un exemple de cas qui marcherait pas si on faisait comme tu le dis, les screenshots. Quand on fait un screenshot, les planes sont pas visibles, donc il faut temporairement faire le rendu totalement en GL. Tu proposes de gérer ça comment si c'est les applications qui font le travail?
Au final, le compositing doit être fait dans le compositeur. Ça sonne bien et ça un sens ;)
Ouais, c'est vrai qu'il manque certains aspects liés à l'intégration. Mais sinon, je voulais dire que c'était déjà possible de faire un client sans trop de modifs coté toolkits ;)
Tu voudrais faire un format de sortie SVG au niveau de Qt? Ça me semble pas déconnant dans certains cas ;) Et les images peuvent être embedded dans du SVG, donc devrait pas y avoir trop de suchis!
Si tu le fais, tu te retrouves avec un buffer cote GPU qui n'est pas dans son format interne et tu perds en performance (Cela se sent pas mal sur les GPU ARM, moins sur Intel). De plus dans toutes les implementations que j'ai vu sur ARM, celui-ci forcait un stall du pipeline cote GPU (Theoriquement non necessaire, si on a des texture double bufferises mais je n'ai jamais vu d'implementation qui faisait cela (je n'ai pas regarder ce que faisait mon intel)). Il ne faut pas oublier qu'un compositeur a la difference d'un jeu, va updater ses textures quasiment a chaque frame. Ceux sont donc des problemes que seul les compositeurs voient. Le fait est que les drivers sont pour l'instant optimise pour les jeux pleines ecran lorsque le compositeur est desactive et qu'il y a encore beaucoup de boulot de ce cote la.
Je suppose que tu parles de perdre le tiling sur le BO. T'es pas obligé de le perdre si tu le refais avec ton CPU. Mais bon, tu peux tjs rendre la différence sur ton CPU et demander à la carte de faire le blit sur le buffer actuel. Pas besoin de faire un accès direct ni de re-rendre toute l'image.
Je referais le test dimanche, mais tu as teste avec quoi ?
J'étais sous KDE. Yakuake de lancé et qui prenait le quart haut de l'écran. Dedans y'avais une appli qui me donne la conso toute les secondes (qui avait été dev par un pote, c'est pas public).
Pour le test idle, je ne faisais rien de plus que regarder la conso une fois qu'elle s'était stabilisée.
Pour le test en bougeant une fenêtre, je faisais juste bouger une fenêtre dans les 3/4 d'écran qu'il reste.
Clairement la standardisation de l'API pour manipuler les plans ouvrent un certain nombre de chose tres interressante cote toolkit, mais il y a du boulot !
C'est pas au toolkit de gérer ça. Y'a que le compositeur qui peut les utiliser ou, au moins, les attribuer à des clients graphiques. Ces clients n'ont jamais à gérer l'affichage dans Wayland, ils ne font que rendre des buffers. C'est pour ça qu'à terme, ils devront uniquement utiliser des render nodes.
[^] # Re: Boite de dialogue pour les mots de passe
Posté par Martin Peres (site web personnel) . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 2.
Oh yeah, retour des boites de dialogues/boutons qui bougeaient quand on essayait de cliquer dessus!
[^] # Re: Boite de dialogue pour les mots de passe
Posté par Martin Peres (site web personnel) . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 2.
Oui, c'est la même idée car faire du pattern-matching entre deux images pour vérifier qu'une appli est pas en train de se faire passer pour la fenêtre de mot de passe, c'est pas facile ;)
Une autre possibilité, c'est d'animer la fenêtre différemment. Avec Wayland, les applications peuvent pas se bouger seules si je me souviens bien (elles disent juste au compositeur "à partir de maintenant, tout mouvement de souris et jusqu'à ce que le clic soit laché, tu bougeras ma fenêtre"). Du coup, on peut faire apparaitre la fenêtre différemment tant qu'on tape pas son mot de passe.
En tout cas, c'est encore clairement un problème ouvert!
[^] # Re: Tu en as de la chance
Posté par Martin Peres (site web personnel) . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 3.
J'ai vu ça, oui, merci ;)
C'est aussi parti sur reddit, si j'en crois analytics.
[^] # Re: Et sur les autres systèmes ?
Posté par Martin Peres (site web personnel) . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 4.
Cool, je savais pas pour Metro!
[^] # Re: Et sur les autres systèmes ?
Posté par Martin Peres (site web personnel) . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 7.
J'ai vu ça, oui, mais dans les faits, tu as un exemple utile à part pour empêcher qu'une appli contrôle les inputs de la fenêtre de l'UAC?
Un programme est lancé par défaut en IL medium (si je me souviens bien) avec possibilité de le descendre (ce que fait IE, adobe reader et chrome). Du coup, un programme non privilégié classique a le droit de modifier les autres applications non privilégiées. Donc, au final, c'est maigre comme sécurité.
[^] # Re: Tu en as de la chance
Posté par Martin Peres (site web personnel) . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 7.
Ah ah, je sais pas si ça va être productif, mais en tout cas ça génère du trafic!
[^] # Re: Capture d'écran
Posté par Martin Peres (site web personnel) . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 6.
Non, tu avais raison, ce sera la politique par défaut des compositeurs Wayland et elle sera paramétrable automatiquement par les packageurs des distros.
Non, c'est pas une politique d'exemple non et oui, ça sera vraisemblablement forcé sur le système de la même façon que X a sa/ses politique(s) de sécurité forcée. Tu devrais être content car la politique que je propose est bien plus configurable que celle de X qui est compilée dans le binaire et qui n'est pas paramétrable.
La dernière chose que je veux, c'est une politique open bar par défaut pour les utilisateurs qui ne veulent pas accepter qu'ils sont différents des autres et qui ne veulent pas prendre 2 secondes pour cliquer sur "j'accepte" ou 2 minutes pour "écrire la politique de 5 lignes" si la distro ne lui a pas fourni.
Je prend la sécurité du serveur graphique très au sérieux car c'est le point le plus délicat pour sécuriser un OS avec interaction utilisateur. Pour te donner une petite idée, j'ai commencé à bosser sur ce sujet il y a 5 ans, avec une équipe de recherche à l'ENSI de Bourges et ça a donné ces résultats (PIGA-SYSTRANS et PIGA-OS).
[^] # Re: Capture d'écran
Posté par Martin Peres (site web personnel) . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 3.
C'est compréhensible, en effet ;)
Ce cas là, c'est quand on utilise aucun moteur de décision externe. Du coup, ça sera simplement un .so référencé par la bibliothèque d'abstraction de prise de décision.
[^] # Re: Capture d'écran
Posté par Martin Peres (site web personnel) . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 3.
Oh, tu as mal lu la fin de l'article. L'idée, c'est de déléguer la prise de décision à une bibliothèque qui permettra d'abstraire le moteur de décision. Comme ça, tous les compositeurs devront juste demander à la bibliothèque quelle décision prendre ce qui devrait pas impacter les compositeurs en terme de volume de code. De plus, si un nouveau modèle de prise de décision apparaît, pas besoin de modifier tous les compositeurs ;)
Non. Ces systèmes avancés couvrent d'autres choses et complètent la sécurité nécessaire dans Wayland (notamment pour contrer les attaques proposées par pasBillpasGate). Aucun de ces outils ne sait contrôler les actions utilisateur directement, c'est au compositeur de remonter ces informations.
[^] # Re: Et sur les autres systèmes ?
Posté par Martin Peres (site web personnel) . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 10.
C'est en effet une bonne suggestion et c'est pas super beau à voir non plus ;)
Input
Confidentialité
Mac OS X
Clavier: Ça a l'air bloqué, sauf si on active un passe droit: https://github.com/dannvix/keylogger-osx/blob/master/keylogger.c
Souris: Pas de sécu. http://stackoverflow.com/questions/2262516/getting-global-mouse-position-in-mac-os-x
Windows
Clavier/Souris: J'ai pas trouvé de keylogger qui utilise la pile graphique (SetWindowsHookEx ou pilote noyau)
Intégrité
Mac OS X
Clavier: À priori, c'est pas possible avec Quartz direct
Souris: Pas de sécu: https://developer.apple.com/library/mac/documentation/GraphicsImaging/Reference/Quartz_Services_Ref/Reference/reference.html#//apple_ref/c/func/CGDisplayMoveCursorToPoint
Windows
Clavier/Souris: Pas d'intégrité: http://michaelsync.net/2006/07/04/sendmessage-c
Output
Confidentialité
Mac OS X
Capture d'écran possible: https://developer.apple.com/library/mac/samplecode/ScreenSnapshot/Introduction/Intro.html
Windows
Capture d'écran possible: http://stackoverflow.com/questions/4751750/automatically-taking-screenshots-of-program-window
Intégrité
Mac OS X
Pas de modification de fenêtre possible autre que la sienne possible. Du moins, je trouve rien.
Windows
C'est possible, dans certains cas: http://stackoverflow.com/questions/15440710/win32-how-to-post-message-to-a-process-run-by-a-different-user-in-windows
[^] # Re: Capture d'écran
Posté par Martin Peres (site web personnel) . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 10.
Je suis convaincu que c'est le seul choix qui ait un sens.
Détecter, c'est bien. Prévenir, c'est mieux. Comme je le disais plus haut, les anti virus et pare feu sont plus des rustines que des solutions de sécurité. Bon, c'est surtout les AV qui sont par natures pratiquement inutile, les pare feu sont très justifiables aussi dans pas mal de cas.
Ce que je veux dire, c'est que c'est au programme qui exporte un service de faire le contrôle d'accès, pas à quiconque d'autre. Oui, ça demande à réfléchir quand on fait le service mais bon, c'est la vie.
Fait une analogie à une organisation qui fourni un service, genre demande de passeport. Ce que tu proposes, c'est qu'on donne un passeport à chaque personne qui le demande, sans contrôle d'identité, puis d'avoir la douane juste derrière pour vérifier. Si tout va bien, la personne arrivera pas à faire sortir le passeport par une voie cachée, mais rien n'est garanti à partir du moment où tu le lui donne. Si tu fais les vérifications avant de lui donner, il y aura accès uniquement si il y a droit et y'a moins de risques de fraude.
[^] # Re: Capture d'écran
Posté par Martin Peres (site web personnel) . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 10.
Si un service ne fait pas de contrôle d'accès avant de fournir son service, qui doit le faire? Un "parefeu" système? Faut pas confondre un hack avec une solution.
Il y a un seul process sur la machine qui a autant de vision sur la volonté de l'utilisateur, ne pas faire le contrôle d'accès dans ce process (qui est en plus le producteur du service), c'est se tirer dans les pieds à coup de bazooka!
[^] # Re: Problematique...
Posté par Martin Peres (site web personnel) . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 10.
Tu as totalement raison, mais je ne parle ici QUE de la sécurité liée à Wayland. Tant qu'on pourra injected du code dans les applis à coup de LD_PRELOAD, la sécurité des desktops sera nulle. Cependant, avec du contrôle d'accès mandataire, tu peux limiter un processus au chargement de bibliothèques depuis /usr/lib/. Ça suffirait pour fixer la majorité des cas. Il reste ensuite le fait que tous les fichiers sont visibles par tous les processes et il faudra un daemon brocker pour résoudre ce problème là et on sera bon.
Comme dit un autre commentaire, on ne fait que fermer une fenêtre, les autres sont toujours ouvertes par défaut … pour l'instant (le MAC suffit à les résoudre). Ne rien faire, c'est recommencer les conneries de X et c'est pas acceptable. Un pas après l'autre, on peut pas révolutionner le desktop tout d'un coup.
[^] # Re: Gestionnaire de fenêtres léger
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 2.
Oui, c'est une remarque valable, il me semble que ça a déjà été proposé. La solution proposée était de faire du throttling coté compositeur. Le compositeur pourrait aussi envoyer un signal quand l'appli est ou n'est plus visible. L'appli pourra ensuite choisir de faire ce qu'elle veut (continuer à rendre à 60 fps ou se limiter à 1 fps).
C'est sûr que si la liste est gigantesque, vaut mieux faire ça :) On est d'accord!
Ce sera à tester, mais c'est en effet une raisonnement valide ;)
[^] # Re: Gestionnaire de fenêtres léger
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 2.
Avec le compositing, une appli ne sait jamais si elle est visible ou pas, et c'est très bien comme ça sinon ça pose d'autres problèmes.
Pourquoi une liste serait dans un plan différent, ça apporte quoi? Ne pas avoir à re-rendre la liste? Typiquement, les plans doivent être utilisés quand tu as des sources de données de format différent. Par exemple, un lecteur vidéo: Un plan pour la vidéo et un plan pour les overlays. Ensuite, si une appli n'a plus besoin d'une sub-surface, alors elle n'a qu'à la libérer. Je vois vraiment pas en quoi le fait de savoir quels plans sont disponibles va aider les applis, elle peuvent utiliser les sub-surface qui sont une abstraction des plans qui seront rendus en matériel ou en shader, suivant le matos.
Je sais pas à quel vitesse on peut allouer un plan, mais ça devrait pas être trop lent.
[^] # Re: Gestionnaire de fenêtres léger
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 5.
Au final, si une application a différentes surfaces, elle n'a qu'à les envoyer en suivant le protocole des sub-surfaces et le compositer dispatchera sur les planes dispo et compositera le reste avec des shaders. C'est exactement ce que je disais avant et pas besoin de négociation. Ça n'apporte rien et au contraire, le toolkit fera une décision merdique quoi qu'il arrive car le compositeur peut à chaque image choisir comment dispatcher les surfaces alors qu'avec ta négociation, il sera bloqué (les applis n'ont pas à savoir quelle partie de leur fenêtre est présentement visible et ne peuvent donc pas "libérer" des planes). Je ne parle même pas du cas du screenshot/screen capture.
Cite moi des cas pratiques où la négociation apporte des avantages et on verra si ça a vraiment un sens (je suis vraiment sceptique).
[^] # Re: Gestionnaire de fenêtres léger
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 2.
Ok, merci pour les résultats. Quelle carte graphique as-tu dans ton ordi?
[^] # Re: Gestionnaire de fenêtres léger
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 3.
Damn, j'y étais presque, à une touche près ;) Merci pour la correction!
[^] # Re: Gestionnaire de fenêtres léger
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 4.
Euh, même si tu faisais de la négociation, tu seras toujours obligé de supporter l'upload des BO sur planes et le compositing GL du reste. Du coup, je vois pas ce que ça t'apporte en terme de complexité si ce n'est de rendre l'exécution des applications plus complexe (imagine les cas où 3 planes seront dispo, ça marche et quand y'en a 4 ou 6, ça marche plus, va debugger ça!).
Pour les subsurfaces qui supportent mal le clipping, faut étendre le protocole.
Au final, ce que tu proposes, c'est de faire exactement ce que je propose avec en plus une phase de négociation pour le nombre de plane. Ça n'a de sens que si tu veux garantir des performances GL. Ça me semble vraiment pas utile vu le coup du compositing.
[^] # Re: Gestionnaire de fenêtres léger
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 5.
C'est pas à moi ce code. On me l'a donné sur #nouveau mais je me souviens plus qui l'a écrit. Enfin, c'est juste une lecture de l'indicateur de batterie et c'est super dépendant du matériel.
Regarde dans /sys/class/power_supply/BAT0/, tu devrais trouver ton bonheur :)
[^] # Re: Gestionnaire de fenêtres léger
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 7.
Tu sais, écrire direct dans la VRAM, c'est faire une copie d'un registre à une adresse mémoire. Là, je te parle pas de faire une copie de tout l'écran, je te parle de copier les différences. Que ce soit le CPU qui fasse ça ou le GPU, c'est pareil.
Ctrl + alt + F12
XRender est tjs accéléré par le GPU, donc c'est pas la solution.
Et comment tu fais ton protocole de réservation de plane? Si tu veux utiliser plusieurs planes dans Wayland, tu utilises les subsurfaces. Les fenêtres et les sub-surfaces seront mappées sur les différents planes sans que l'application ait besoin de connaitre quoi que ce soit. Donne moi un cas où ça ne marcherait pas?
Comme je disais, l'application doit donner ses buffers graphiques et indiquer comment faire la composition interne de ses subsurfaces. Ensuite, c'est au compositeur de faire de son mieux.
Un exemple de cas qui marcherait pas si on faisait comme tu le dis, les screenshots. Quand on fait un screenshot, les planes sont pas visibles, donc il faut temporairement faire le rendu totalement en GL. Tu proposes de gérer ça comment si c'est les applications qui font le travail?
Au final, le compositing doit être fait dans le compositeur. Ça sonne bien et ça un sens ;)
[^] # Re: Grosse fatigue
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 3.
Ouais, c'est vrai qu'il manque certains aspects liés à l'intégration. Mais sinon, je voulais dire que c'était déjà possible de faire un client sans trop de modifs coté toolkits ;)
[^] # Re: Grosse fatigue
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 2.
Un truc comme ça? https://www.youtube.com/watch?v=qDyWjNju1yU
[^] # Re: Grosse fatigue
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 2.
Tu voudrais faire un format de sortie SVG au niveau de Qt? Ça me semble pas déconnant dans certains cas ;) Et les images peuvent être embedded dans du SVG, donc devrait pas y avoir trop de suchis!
[^] # Re: Gestionnaire de fenêtres léger
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 3.
Je suppose que tu parles de perdre le tiling sur le BO. T'es pas obligé de le perdre si tu le refais avec ton CPU. Mais bon, tu peux tjs rendre la différence sur ton CPU et demander à la carte de faire le blit sur le buffer actuel. Pas besoin de faire un accès direct ni de re-rendre toute l'image.
J'étais sous KDE. Yakuake de lancé et qui prenait le quart haut de l'écran. Dedans y'avais une appli qui me donne la conso toute les secondes (qui avait été dev par un pote, c'est pas public).
Pour le test idle, je ne faisais rien de plus que regarder la conso une fois qu'elle s'était stabilisée.
Pour le test en bougeant une fenêtre, je faisais juste bouger une fenêtre dans les 3/4 d'écran qu'il reste.
C'est pas au toolkit de gérer ça. Y'a que le compositeur qui peut les utiliser ou, au moins, les attribuer à des clients graphiques. Ces clients n'ont jamais à gérer l'affichage dans Wayland, ils ne font que rendre des buffers. C'est pour ça qu'à terme, ils devront uniquement utiliser des render nodes.