Martin Peres a écrit 413 commentaires

Singularity a une architecture tres speciale, il n'y a pas de separation logique (au sens des rings sur x86 par exemple) entre le kernel et le user-mode, tout tourne en ring-0, les controles d'acces se font d'autres manieres.

Epic Fail... Pourquoi se passer de la sécurité presque gratuite apportée par la mmu? Éviter le coût du context switch userspace/kernelspace? C'est vraiment n'importe quoi! Et il se passe quoi si j'écris un programme non managé sur cet "OS"? J'ai accès à toute la ram, aux périphériques, etc...?

S'ils arrivent à le fournir de base dans Qt, on pourra effectivement imaginer avoir un Qt5 qui repose sur du QML.

Ils seront inclus dans Qt5, c'est marqué sur le blog post.

Je suis vraiment curieux de voir des benchmarks pour voir si scenegraph apporte des perfs même dans le rendu d'interfaces graphiques classiques. J'ai pas envie de sacrifier des performances...

Sinon, QML va permettre d'apporter des interfaces organiques? (transitions douces) et KDE va pouvoir faire son propre set the widget QML comme ça, on aura un comportement unifié et cohérent entre les applis KDE :)

Est-ce qu'il y a un truc dans QML pour réutiliser le style des widgets actuels, ou bien on doit réinventer le bouton à chaque fois? Est-ce que tous les widgets de Qt sont implémenté dans QML, ou bien on doit tout se retaper?

https://www.youtube.com/watch?v=nj5jzv6njKg et http://labs.qt.nokia.com/2011/03/10/qml-components-for-desktop/ sont tes amis ;)

Do what you want because Google is free, you are a pirate !

Hey, t'as pas honte de me remettre une chanson comme ça dans la tête sans même prévenir ?
http://www.youtube.com/watch?v=ZLsJyfN0ICU

Bon, ben je sens que je suis reparti pour 1 mois durant lequel on va me prendre pour un fou ;)

1/ 80% des exploits proviennent de failles bidons (genre "jai laissé ma clée ssh trainer avec un pass bidon")

Mouais, pas convaincu mais je vois très bien d'où tu veux en venir et on y peut rien :s. Cela dit, le premier vecteur d'attaque dépend de la cible. Les attaques sur les serveurs, c'est plus des failles dans les services que les clés ssh qui trainent :)

2/ qui sont transformé en "full exploit" via une faille kernel (100% des kernels ont des failes "instant root")

Escalade des privilèges, en effet. Les failles à ce niveau là ne viennent pas forcement que des modules, elles peuvent venir du matériel aussi (DMA). Il n'y a pas que les NULL pointer dereference comme failles dans le kernel. Singularity ne peut rien faire contre les exploitations abusives du matériel.

Singularity palie à ca et au manque de rigueur du code (qui est impossible en C).

Je dirai qu'ils prétendent y palier, on a pas de code à tester que je sache, si?

Si ca parce que c'est Microsoft, il y a d'autre OS du même type, simplement moins connus.

Ça serait le kernel Linux qui voudrait faire ça, j'aurai la même réaction en plus violente :D Je suis au contraire bien content que Microsoft dépense un peu de son argent dans la recherche plutôt que la pub ou autre.

Singularity contrôle aussi les accès mémoire des applis et appels système.

Pour les appels systèmes, ok.
Pour les accès mémoire des processus, Singularity base sa décision d'accepter ou non l'accès sur quoi?

C'est exactement mon sujet de mémoire de master, abuser la MMU pour récupérer des page_fault sur les pages mémoires "protégées" et vérifier ou non que l'accès soit valide ou non. Le moteur de décision de l'autorisation ou non venait du moteur du moteur d'SELinux (AVC).

Perso, je pense pas de bien de Singularity car le managé donne un faux sentiment de sécurité et demande la ré-écriture d'un OS pour empêcher quoi? Une ou deux types de failles en laissant les autres totalement ouvertes...

D'où tu sors les 35 devs? Je pensais que Singularity était juste un projet de recherche des laboratoires Microsoft?
Pour autant que je sache il n'est pas développé du tout: as-tu plus d'infos ou confonds-tu avec autre chose?

Désolé, de ne pas avoir mis de référence, c'est que l'article de wikipedia(http://fr.wikipedia.org/wiki/Singularity) en manquait aussi. Au final, que ce soit 5, 10, 50 ou 100 développeurs, ce que je voulais dire tiens toujours.

Non, je n'ai pas d'infos sur Singularity, mais le problème de créer un nouvel OS actuellement est l'implémentation des drivers. De plus, dans le cas de Singularity, masquer la gestion de la mémoire (le managé) dans le kernel, ça revient pas à faire une approche hybride entre les micro-noyaux et les noyaux monolithiques? Je suis pas convaincu de la pertinence.

Sauf que Linux n'est pas non plus bien situer de ce coté: les développeurs de Chrome, une des rare application a faire justement ce contrôle des appels systèmes, se plaignaient que Linux n'offraient pas de moyen "standard" d'implémenter leur 'bac à sable'..

Je pense que ça a déjà été répondu :)

C'est une évidence ;) Mais rendre plus visible les attaques, c'est important.

C'est ce qu'essaye de faire microsoft avec son UAC mais y'a trop de programmes qui requièrent les droits administrateurs pour s'installer que finalement, ça perd son intérêt.

Pour le contrôle des appels les appels système sous Linux il y a RSBAC/SeLinux/...

Yap, je sais, mais ça suffit pas et c'est super lourd à mettre en place. C'est sur ce sujet de recherche que j'ai travaillé en tant qu'étudiant de master à l'ENSI de Bourges.

Y'a quelques papiers de recherche sur le sujet. Il y a notamment la thèse de Jonathan Rouzaud-Cornabas (http://www.arrouan.be/perso/?page_id=42) qui traite du problème d'empêcher les flux d'informations.

Avec le système décrit dans la thèse, il devient possible d'écrire en moins de 5 lignes une règle qui empêche qu'un utilisateur exécute un binaire qu'il aurait lui même téléchargé. Il est aussi possible d'empêcher des flux indirect de transfert d'information quand le flux direct n'est pas lui même possible. Cela permet d'éviter que le fichier des mots de passes de firefox soit accessible par le client mail même si firefox ouvre le fichier et le ré-enregistre dans /tmp (endroit où le client mail a normalement le droit de lire).

Avant de parler de la sécurité de Singularity, j'attend de voir un OS qui marche. Avec 35 devs, on est pas prêt de le voir arriver cet OS.

Perso, je dirai qu'avant de parler de la sécu du kernel, faudrait mieux contrôler ce que font les applications en userspace (contrôle des appels systèmes et des accès mémoire). Je peux t'assurer que si tu fais ça bien, tu auras déjà une sécu bien béton!

Des solutions existent pour faire ça, mais elles ne sont pas connues. J'espère que ça va changer.

ça marche plutôt pas mal pour moi, mais je suis déjà bien familier avec la crypto (a)symétrique, le chiffrement et la signature donc ...

Exactement :)

C'est pour ça qu'nVidia ne peut pas nous empêcher d'essayer de comprendre leurs GPU. La rétro-ingénierie n'est pas attaquable en Europe.

De toute façon, ils en ont rien à faire/sont contents qu'on fasse un driver libre pour eux. Eux, ils ne font que respecter les contrats de licence des "technologies" qu'ils achètent/intègrent à leurs GPU ... je suppose.

Je doute qu'il soit interdit de faire du Reverse Engineering dessus. C'est totalement légal en Europe et j'ai même été invité par Alex Deutcher à le faire pour qu'ils n'aient plus ces problèmes de firmware.

Excellente question Gabin,

Je pensais exactement comme toi jusqu'à ce que mon école d'ingé de la région centre me donne (je déconne pas) un lenovo avec une quadro nvs 140m.

Comme j'aime tester tout et n'importe quoi, j'aime faire joujou avec des kernels rc1 si j'en ai envie sans que le blob nvidia m'en empêche. J'ai tenu une semaine mais finalement le blob était buggé, lent en 2D et avait un support de la mise en veille douteux.

J'ai donc testé nouveau et j'ai bien aimé. Même si la mise en veille, c'était pas toujours ça, la 2D était très rapide, surtout sur kde. Puis il y a eu la fameuse démangeaison qui fait qu'un utilisateur enthousiaste devient développeur. Je voulais corriger un problème de corruption graphique. C'est à ce moment là que le CTO de PathScale m'a approché sur IRC et demandé si je serai intéressé par bosser sur PSCNV, un fork de nouveau pour le GPGPU. J'ai accepté et ça m'a ouvert l'esprit!

Je respecte AMD pour son ouverture et surtout, les ingénieurs que la boite emploie. J'ai eu l'occasion de rencontrer Alex Deutcher et Jerome Glisse à l'XDS2010 à Toulouse. Ils sont passionnés et prêt à répondre à toutes les questions que tu pourrais avoir. C'est super motivant!
La raison pour laquelle je ne travaille pas dessus est simplement que ...... ça marche trop bien chez moi. Sérieusement, mon ordi fixe tourne avec une HD4770. Ça a pas été agréable au début, j'ai pas mal reporté de bugs, ça bougeait pas trop puis d'un coup, tout à été résolu et depuis décembre 2009 je teste chaque nouveau kernel et ça marche de mieux en mieux.
D'un autre coté, nouveau, c'est une tonne de support qui manque et notamment la gestion d'énergie. Je travaille dessus depuis septembre 2010. L'avantage de bosser dessus, c'est qu'on est que quelques personnes à travailler dessus, c'est en grande partie indépendant du reste du driver/kernel et on apprend à notre rythme.
Sérieusement, AMD est une boite chez qui je serai intéressé de bosser dans un futur proche même si je bosse actuellement sur nouveau.

Dernier point, ma formation ne s'est jamais concentrée sur le hardware. J'ai fait un IUT d'info spécialisé en génie logiciel. Maintenant, j'étudie et recherche en sécurité Informatique, spécialité informatique mobile. Mon parcours est donc à des années lumières du développement kernel. Je connaissais l'électronique numérique, l'espace utilisateur mais trop rien entre les 2. Du coup, j'ai énormément de choses à apprendre et Nouveau a une communauté d'auto-didactes. On trouve des gens de tous niveaux prêts à nous aider.

Au final, les raisons qui me poussent à bosser sur nouveau plutôt que le driver radeon:

• Je commence à comprendre le hardware après presque un an, pourquoi en apprendre un autre alors que j'ai pas fini
• J'ai pas fini ma mission "gestion énergétique"
• Je travaille avec des amis que j'ai appris à connaitre, c'est fun :)
• On est clairement pas assez et rare sont les nouveaux venus (c'est pareil coté radeon, mais ils sont tellement compétents que ça fait peur :))
• J'aimerai avoir un niveau minimum de support sur tout le hardware en Open Source et nVidia n'est pas prêt à nous aider à faire ça (doc avant la sortie de la carte).
• Le challenge de faire pareil/mieux que le driver propriétaire qui n'est pas mauvais mais clairement pas parfait :)

Ah oui, je l'ai vu celui là mais j'ai aucune compétence pour résoudre ça.

Je peux redemander à Pekka Paalanen(pq sur IRC) voir si il a pas des idées.

Jerome: Comme d'habitude Jérome, excellente explication.

C'est moi qui ait plus ou moins lancé le troll même si ce que je voulais montrer était plus que le troll "gallium is slow" n'était pas fondé, au moins pour les cartes nVidia.

Je pensais, à tord, que Michael de Phoronix aurait compris mais c'est vraiment pas le cas.

Info générale sur nouveau:
On fait de notre mieux pour nouveau, mais on souffre de l'absence de documentation. La partie 3D ne change pratiquement pas entre les différentes révisions d'une architecture par contre certaines choses changent drastiquement sans qu'on sache vraiment pourquoi :o
On est clairement pas assez et on a accès à seulement une vingtaine de carte ce qui fait qu'on a pas mal de problème de regression. C'est pour cette raison qu'on demande aux utilisateurs de tester souvent la branche nouveau (http://cgit.freedesktop.org/nouveau/linux-2.6/log/)

Pour info, 90% du dev est fait par 3 personnes:

• drm: Ben Skeggs de Red Hat
• mesa: Christoph Bumiller, un étudiant Autrichien en master de physique
• Reverse engineering: Marcin Kościelnicki, un étudiant Roumain d'à peine 19 ans

Le reste du dev est effectué par des utilisateurs de Nouveau, enthousiastes et étudiants . J'en fait partie mais on avance très doucement. On bosse majoritairement sur la gestion d'énergie (4 personnes, chacun son domaine de compétence).

Yeah! Les commentaires en markup, c'est super!

Sinon, y'a des petits problèmes d'affichages avec la css /stylesheets/contrib/RonRonnement-Vert.css sous chromium (l'image de l'article se retrouve en bas de l'article et déborde sur les commentaires).

Bien joué!

PS: C'est vrai que c'est bizarre d'avoir un gravatar d'afficher, m'enfin, on va s'y faire ;)

Remarque très pertinente.

En l'état la question se pose, mais on peut imaginer que les distributions fassent des groupes pour les applications graphiques gourmandes (telles que les outils de recherche sur disque dur). Dans ce cas là, tout le monde aura intérêt à utiliser les cgroups.

Ça serait cool d'avoir des outils en CLI et en GUI pour gérer ça facilement, oui !

Mouais, dans un sens, tu as raison, mais bonne chance si tu veux émuler ça avec nice car y'a pas toujours 64 threads de compilations, des fois, tu en auras 3 et des fois 25.

C'est plus propre comme ça je trouve!

Le .37 apportait déjà pas mal car on gagnait vraiment en fluidité sous forte charge mais là, avec ce patch en plus, c'est une tuerie :)

Sur mon liveusb, c'est étonnamment fluide ;)

== Explications (théorie) ==
Pour l'explication technique, c'est pas bien compliqué (c'est une supposition qui correspond bien au nom du patch).

Soit X le nombre de processus sur le système.
Sans le patch, chaque processus recevra un minimum de 100/X % du processeur.

Le problème, c'est que quand on compile avec 64 gcc, on diminue vachement le temps processeur restant pour les autres applications (qui ont besoin d'un pic de CPU, mais pas longtemps).

Donc, plutôt que d'allouer le temps processeur en fonction du nombre de processus, ce temps processeur est alloué en fonction des groupes.

Si on a un groupe GUI et un groupe compilation, 50% du temps processeur ira à la GUI et 50% ira à la compilation. Comme le groupe GUI n'a pas besoin de tout ça, l’excédant part dans les groupes qui en ont besoin :)

Et voilà comment on augmente la réactivité générale sans vraiment perdre en performance :)

PS: Il semblerait que les groupes soient définis en fonction du TTY depuis lequel il a été lancé. Comme la GUI est sur le TTY7 et que les consoles sont dans /dev/pts/, les 2 sont dans 2 groupes séparés, et on a donc un ordonnancement plus juste.

Je me demande comment le système réagira en cas de bomb fork avec ce patch, faudra que je teste à l'occaz.

Wayland n'est pas incompatible avec ça, mais le passage par le réseau n'est pas obligatoire.

Il va falloir écrire un greffon pour le compositeur de wayland qui permettrait d'exporter les fenêtres sur le réseau. C'est en cours d'étude.

Faut pas oublier que Wayland permet de lancer plusieurs serveur X dans les cas où Wayland ne gérerai pas un truc. Wayland = système minimaliste qui ne garde que le coeur important de X et qui se concentre sur la vitesse (pensez embarqué).

Hein?

Au contraire, une des caractéristiques de Wayland, c'est l'abandon de la couche réseau.
--> Les clients (comprendre programmes) rendent eux même dans un buffer leur fenêtre et l'envoient au compositeur.

Au final, ça permet aux applications d'utiliser le système le mieux adapté au rendu de leurs fenêtre (typiquement, opengl ou cairo-gl) et pas utiliser les fonctions à la con de la XLib genre dessine moi une ligne. Au final, y'a un max de performance ;).

Wayland, j'ai testé, c'est extrêmement fluide!

non mais il me fait mentir ce truc !

J'avais essayé et le filtre ne m'autorisais que l'ouverture de projet kdev4. Cela dit, j'ai rebooté entre temps, c'est peut-être la raison du pourquoi ça marche maintenant.

Merci en tout cas

Ça doit être moi mais je n'arrive pas à importer mes projets qmake ou cmake :s Quelqu'un à compris comment ce truc marche ?

Sinon, ArchLinux a le paquet kdevelop 4.0-1 de dispo depuis hier, c'est cool :)

hey hey, c'est sûr. Mais j'écris une dépêche à chaque nouvelle beta :)

Je peux pas faire mieux sur LinuxFR je crois.