Arg, c'est le genre de bug qu'il y a uniquement avec certains matos. Et bien sûr, les PCs des développeurs n'ont pas tous les bugs possible (et c'est bien dommage au final)...
Si tu veux aider sur ce point, on peut te donner des directions :)
La situation n'est pas perdue. J'ai le code pour changer les clocks de ta carte aussi souvent que tu veux, même quand tu joues. Je suis en train de faire merger ça dans le kernel.
J'espère que ça sera dans le 3.3. Je vais presser le mainteneur.
Utiliser mesa compilé depuis git ou au moins la dernière version stable. Dans ton cas, ça peut ne pas être bon car plus personne ne maintient le driver pour les geforces 5, 6 et 7.
Vérifier les logs kernel pour voir les fréquences de la carte
Les geforce inférieures à 8 sont, en général, réputées pour leur performance. C'est dû au fait qu'elles sont pour la plupart toutes clockée à leurs fréquence maximale ou presque au boot. De plus, la fréquence de la mémoire (qui influe énormément sur les performances, presque linéairement) était la plupart du temps fixée à son maximum.
Pour info, je travaille sur la gestion d'énergie dans Nouveau depuis un peu plus d'un an.
Suivant les cartes, on arrive à avoir entre 60 et 80% des performances du driver propriétaire quand la carte tourne à la même fréquence que Nouveau.
Il faut savoir que par défaut, la carte boote avec des fréquences de fonctionnement inférieures à leur maximum. C'est cette limitation qui fait que Nouveau peut être extrêmement lent ou assez rapide. Ces informations sont accessibles dans les logs kernel:
[drm] nouveau 0000:02:00.0: 4 available performance level(s)
[drm] nouveau 0000:02:00.0: 0: core 50MHz shader 101MHz memory 135MHz timing 2 voltage 875mV
[drm] nouveau 0000:02:00.0: 1: core 405MHz shader 810MHz memory 324MHz timing 1 voltage 912mV
[drm] nouveau 0000:02:00.0: 2: core 405MHz shader 810MHz memory 1800MHz timing 0 voltage 937mV-1075mV
[drm] nouveau 0000:02:00.0: 3: core 715MHz shader 1430MHz memory 1800MHz timing 0 voltage 937mV-1075mV
[drm] nouveau 0000:02:00.0: c: core 50MHz shader 101MHz memory 135MHz voltage 875mV fanspeed 40%
Cet example est celui de ma carte Fermi nvc4. La dernière ligne (c:) indique les fréquences actuelles. Les lignes d'avant définissent les niveaux de performance tels qu'on peut les lire dans le bios de la carte.
On voit que la vitesse de ma ram est inférieure à 1/10 de sa fréquence maximale. Les performances seront vraiment ridicules comparées au driver propriétaire.
J'essaye de faire fusionner mes modifications pour pouvoir changer les fréquences sans crasher la carte. Cependant, ça demande de pouvoir monitorer à la fois la température et gérer la vitesse du ventilateur, 2 choses qui sont très mal normalisées et qui rate assez souvent. On a encore du boulot avant d'être sûr qu'on ne va pas cramer votre carte en l'upclockant...
J'ai réussi à faire plus ou moins marcher le changement automatique de fréquence en fonction du taux d'utilisation de la carte. Quand j'aurai un truc qui marche bien sur toutes les nv50-a3, je demanderai à inclure ce code. En attendant, je travaille avec Ben Skeggs, le mainteneur nouveau, pour faire entrer mes patchs et optimisations de la consommation.
De rien. Au dernier noyau, je m'étais promis de venir prêter main forte ici pour vérifier et compléter le travail sur Nouveau. Il semblerait que j'ai encore oublié.
les patches de Ben Skeggs remplacent ce micro‐code par un FµC (Fermi microcontroller) complètement libre, qui devrait fonctionner sur les cartes de type NVC0, NVC1, NVC3, NVC4, NVC8, et NVCE.
Petites corrections:
Fµc: Flexible microcode. On l'appelait Fermi microcode avant, mais il se trouve que les premiers moteurs à l'utiliser ont été introduis sur les nv98. On l'a donc renommé pour montrer à quel point cette ISA et le moteur d’exécution qui lui est associé sont génériques. Pour information, Fµc est utilisé pour définir les interfaces entre l'OS et le hardware (command submission) dans certains moteurs tel que PGRAPH (rendu 2D/3D), PCRYPT, PDAEMON (une sorte de RTOS qui tourne dans la carte graphique), video decoding et plein d'autres.
Avant, le rendu ne nécessitait pas l'écriture de microcode en Fµc. La situation a changée avec Fermi ce qui a empêché d'avoir une accélération graphique totalement libre pendant un long moment.
L'utilisation de Fµc est encore plus générale dans Keppler, la prochaine architecture de NVidia dont on a un aperçu avec les nvd9. En effet, une bonne partie des moteurs d'exécution ont été convertis à Fµc. Pour l'instant, seul le modesetting marche sur ces cartes (je vous écris un message avec là). Dans ce cas là, l'accélération graphique est effectuée par le driver gallium llvm.
Le microcode de PGRAPH ne marche pas sur les nvc1. Le problème est en cours d'analyse.
J'appelle le mien Terton même si c'est un femelle. Même si c'est pas son nom de baptême (Phoebe, en rapport avec 2 series américaines hautement intellectuelles), elle se reconnait, c'est le principal!
Oui, mais non. Kerberos c'est tout simplement une usine à gaz incompréhensible, entre le serveur d'identification, le serveur de tickets, le serveur de clefs de tickets ou je ne sais quoi.
Tu n'exagères pas un petit peu? C'est pas incompréhensible, c'est juste pas adapté à tous les cas d'utilisations (besoin d'un temps partagé) ;) Et puis, si même microsoft l'a mis en place (dans Active Directory), c'est que ça doit pas être si dur que ça de le faire comprendre aux admins (bonne journée à eux).
Perso, je vois pas comment quelqu'un pourrait garantir autant de propriétés de sécurité avec un protocole plus simple. C'est élégant d'un point de vue sécu, beaucoup moins d'un point de vue conso énergétique et latence d'accès aux services.
Ceci est une implémentation initiale. Le but final est bien sûr d'utiliser le hw dédié.
Pour Nouveau (je bosse que sur ce driver), on sait décoder du mpeg 2 en hardware pour les geforce 7 jusqu'aux geforce 9. Pour AMD, pas de docs. Peut être Jérome Glisse pourra nous dire plus :)
Quelqu'un est en train de voir de notre coté comment gallium pourrait se servir du circuit de décodage mpeg2. Ça sera la première implémentation libre qui utiliserait un décodage totalement hardware :).
C'est typiquement ce que j'aimerai qu'il explique dans "X vs Wayland".
Mais je ne sais pas si c'est très pertinent de poser ce genre de questions car c'est peut être un peu trop technique/spécifique. Cela dit, je suis probablement mal placé pour préparer des questions, c'est pour ça que j'ai proposé quelque chose de vague pour laisser une grande liberté à la personne interviewée.
Cela dit, y'aurai peut-être moyen que je fasse une vidéo-interview lors du projet XDS (Septembre) si vous me fournissez les questions.
En effet, une interview de Kristian Høgsberg, ce serait cool.
Idées de questions:
Origine du projet?
Qu'a permis son changement d'employeur (Red Hat -> Intel)?
X vs Wayland: Ce que permet de faire l'un et pas l'autre.
Les fallbacks de Wayland?
Wayland, la communauté?
Ses objectifs actuels
Pour information, j'ai discuté avec Kristian lors de l'XDS2010 qui s'est déroulé à Toulouse. C'est une personne très sympathique mais avec de fortes convictions (comme tous et c'est normal). Il répond généralement quand on lui pose une question sur IRC, même basique. Je suppose donc qu'il ne dira pas non pour se soumettre au jeu de l'interview :)
Exact, la pile graphique de Vista/7 est vraiment pas mauvaise!
Autre truc excellent que l'on est loin de pouvoir faire, c'est la migration à chaud d'un GPU à l'autre (optimus et consors). Dave Airlie travaille à ce qu'une carte nvidia puisse écrire dans le scanout buffer d'un IGP intel. C'est un premier pas pour pouvoir choisir la carte qu'on veut utiliser au démarrage de X dans le cas où il n'y aurait pas de multiplexer hardware sur la sortie vidéo. Pour la migration à chaud, faudra probablement attendre Wayland (ça suffirait pour utiliser la carte que l'on veut utiliser au démarrage d'une application) et quelques modifications dans les toolkits (pour se re-créer un contexte graphique sur la nouvelle carte et faire son rendu si l'on veut switcher tout le système).
Cela dit, comme souvent chez doz, je suppose que les drivers doivent y être pour énormément. N'empêche que sur ce point là, ils ont fait fort chez crosoft.
Bon, on va dire que j'ai peur de voir un modèle comme ça appliqué parce que le système de vérification de code est complexe.
En tous cas, bonne explication! Cela dit, pourquoi ne pas simplement vérifier le code en userspace, pourquoi ré-écrire le code du kernel. Je trouve vraiment pas ça pertinent. Qu'on le veuille où non, les drivers utiliseront toujours des pointeurs et c'est dans les drivers que les failles seront trouvées.
On retombe donc sur un problème de vitesse de résolution de la faille et sur ce terrain, le libre a son intérêt. Même si le kernel n'est pas prouvé, le temps entre la découverte d'une faille et l'arrivée du patch est généralement de quelques heures. Il suffit d'appliquer le correctif sur son kernel et tout est bon. Cela dit, quid des failles pas publiques? Là, on est obligé de limiter l'exécution de code à des binaires plus ou moins prouvés par l'expérience. Sur ce point, l'aspect centralisateur des dépôts est un bon point car les vérifications de l'un participe aux autres. Et puis il est toujours possible de faire tourner tous les analyseurs statiques qu'on veut sur les sources.
Au final, je dirai que l'idée a le mérite d'exister. Comme tu dis, on verra si ça marche en pratique.
En même temps c'est tout aussi scandaleux de faire confiance aux ring qui s'appuie sur du matos tout aussi potentiellement buggé... sans être patchable. Tu fais quoi demain si tu te retrouves avec une faille de sécu énorme dans une génération de proc grand public ? Le rôle de base d'un OS c'est de faire abstraction du matos, l'idée d'une sécurité qui fait abstraction de mécanisme hardware est donc tout à fait pertinente.
Sur le fond tu as pas tord, mais faut pas exagérer non plus. Le concept de ring est assez simple à implémenter et puis, c'est pas dur pour la MMU de regarder le ring actuel et regarder les flags de la page mémoire pour comparer et générer ou non un page_fault.
Comparer ça aux milliers de lignes nécessaires dans l'OS pour arriver à se passer du concept de ring, c'est osé ;)
Pour le coup de l'OS qui doit faire abstraction du matos, c'est vrai d'un point de vue userspace, mais pas d'un point de vue kernel space. Le kernel doit utiliser autant que possible le matériel car il est plus rapide et consomme moins d'énergie que le software.
J'espère que tu conviendras qu'il n'y a pas besoin de vérification à l'exécution pour être sûr que la boucle n'accède pas en-dehors du tableau ?
Il y a aussi la notion de compilation juste à temps que tu sembles ignorer : un certain nombre de vérifications peuvent être faites à ce moment, lorsqu'on a des infos plus fines sur le contexte d'exécution.
Oui, je suis 100% d'accord, mais dans l'absolu, un compilateur (JIT ou pas) ne peut pas toujours prouver que l'on ne sortira pas du tableau. C'est plus le rôle d'un analyseur statique de faire ça, et même là, c'est pas toujours la joie.
Et tu rates la moitie du truc quand tu t'arretes a une page d'introduction
Ok, si les concepts généraux ne sont pas dans la page d'intro, dans ce cas là la page est mal faite. Je lirai peut être un jour les articles, en attendant, je crois pas au futur du truc.
Et tu crois que qqe APIs suffisent pour un kernel ? Tu n'as visiblement aucune idee de ce qu'un kernel contient.
Roo, calme toi. Je te parle d'une interface de manipulation de tableau avec vérification des accès à l'exécution, et toi tu pars direct sur; ça suffit pas pour faire un kernel. Tu dérailles là, bien sûr que ça suffit pas.
Maintenant explique moi comment fait .net pour empêcher les buffers overflow alors? C'est de la programmation orientée objet, et une vérification à la compilation à moins que .net interprète ton code.
Si tu crois que .net fait de la verif a la compilation, tu n'as rien ocmpris a .NEt, c'est a l'execution que c'est verifie, et c'est pas interprete (tout comme Java).
En effet, j'ai dis de la grosse merde là. J'ai très très mal formulé ce que je voulais dire. Tu as 100% raison là dessus.
Et comment tu lancera un soft qui programmera ton materiel sous Singularity ? Tu ne peux pas.
Tu crois pour je ne sais quelle raison que tu peux faire tourner le code que tu veux sous Singularity, c'est pas le cas.
Et tu crois pour je ne sais quelle raison qu'on arrivera jamais à trouver une faille qui va faire qu'on va pouvoir exécuter du code. C'est ça que je trouve scandaleux de la part d'une équipe de sécurité, avoir une confiance aveugle en son système au point de faire tourner tout programme en ring0.
Pourquoi la recherche sur la sécurité mémoire ne s'est pas arrêtée lors de l'arrivée de .net et C#? Oh, mais que je suis bête, c'est simplement parce que C# ne résout rien...
Parce que tout le monde ne veut pas ecrire un OS avec les attributs de Singularity, tout comme tout le monde ne mange pas que des fettuccine comme pates.
Ou simplement aussi que ça ralentit énormément les accès mémoires. Je pense que là dessus, on a plus rien à dire.
De toute façon, C# ne peut être meilleur que la virtualisation ... qui n'est pas de la sécurité.
Il y a toute la partie controle d'acces que visiblement tu as rate.
Ou simplement tu oublies encore les failles dans les drivers. La virtualisation ne fait qu'augmenter la surface d'attaque. Actuellement, root sur une VM rime avec root sur l'host tellement il y a de failles.
Je ne te traite pas d'incapable mais d'arrogant. Quand a moi, ca fait plus de 10 ans que je bosses chez MS, dont plus de 6 sur la securite de l'OS et 4 sur la stack reseau, dans le kernel. On va dire que la securite d'un OS je connais.
Moi je trouve arrogant de la part de l'équipe de Singularity d'enlever l'interface userland/kernel.
Sinon, ça veut dire que tu as participé à la création de MIC? J'ai bien aimé l'idée de forcer les gens à utiliser un système de contrôle d'accès mandataire, mais le faire se baser sur des niveaux d'intégrité, c'est vraiment pas géant à mon goût. Je suis plus fan des labels et de la création de domaines car ça permet de segmenter les tâches en activités.
Super, quel rapport ? Il parle du fait qu'il existe des bouts de code non-manage, ca ne dit rien sur l'architecture de Singularity a part que L4 est plus petit et plus facilement verifiable..
C'est vrai que vérifiable et sécurité, c'est pas associé du tout. M'enfin, c'était pas le truc que je voulais montrer. Tu me demandes comment le code malicieux pour arriver comme ça et être exécuté. Moi je dis, prouve moi que c'est impossible. Jusqu'à preuve du contraire, je continuerai à penser que c'est possible, donc ça va arriver.
En fait, je trouve nos approche vraiment opposées. Pour moi, un pourrait potentiellement arriver si les étoiles sont alignées etc... = arrive. Pour toi, c'est un pourrait arriver = peu probable.
Donc tu penses qu'en Java, Python, Ruby... tu peux crasher un processus en faisant un accès hors limites de tableau, sous prétexte qu'il n'y a pas de CPU idoine ?
C'est simple, si ça plante pas, c'est que les accès aux éléments d'un tableau sont vérifiés à l’exécution. Bonjour les perfs quand tu fais que manipuler des structures de données comme dans ... un kernel?
Si ça te laisse faire (depuis quand ça devrait crasher le processus? C'est juste quand tu sors des pages mémoires qui t'ont été mappées par le kernel dans ta mémoire virtuelle que tu te récupères un segfault), alors c'est que c'est pas vérifié. C'est ce que fais C/C++.
On peut avoir le meilleur des 2 mondes (le débug facile de Python/Ruby/Java) et les perfs de C grâce à valgrind (userland uniquement) qui te vérifiera tous tes accès mémoires. Mais faudra coder en C pour avoir les perfs de C.
Il est impossible de prouver une propriété en faisant de l'analyse statique pour la bonne et simple raison qu'il est impossible pour un programme de vérifier tous les cas. C'est un truc que tu vois dans les 20 premières minutes d'un cours sur l'analyse statique. La seule solution pour prouver le bon fonctionnement d'un programme en un temps raisonnable, c'est de générer des tonnes de faux négatifs. Ça revient à demander à un compilateur de générer des patterns de code. Pourquoi pas, mais c'est documenté? Quid de la vitesse d'exécution?
Un exemple, tu peux vérifier que les appels systèmes sont bien les bons et appelés seulement avec une adresse immédiate (miam le cassage de programmes existants).
Mais au final, c'est quoi un appel système dans un OS comme ça? Ça existe pas, c'est plus un espèce de gros tas qui prétend être tenu en place par de l'analyse statique de tous les cotés.
2) Si tu crois que C# se limite a débordements de tampons c'est que tu n'as rien compris a C# et encore moins a Singularity.
Ensuite si tu es assez naif pour croire que les problemes de gestion de tampon se reglent avec une API quelconque c'est que tu n'as rien compris a la programmation...
Si tu veux vraiment éviter les buffers overflows, il faut contrôler la création de buffers puis tous les accès subséquents. La seule façon crédible de faire ça et vérifier à l'exécution et la seule façon de vérifier et de faire des processeurs qui soient au courant de la taille de ton "buffer".
Ça a déjà été "fait": http://www.cc.gatech.edu/~idoud/documents/TAINTTC.pdf
Maintenant explique moi comment fait .net pour empêcher les buffers overflow alors? C'est de la programmation orientée objet, et une vérification à la compilation à moins que .net interprète ton code.
Et je me répète, mais y'a pas que les processus qui font des accès mémoire, le matériel aussi. Et le matériel peut être programmé pour faire un accès mémoire qui va modifier les bits que tu veux au bon endroit même si la page mémoire est marquée comme ro (et oui).
3) De nouveau, tu n'as rien compris, un gestionnaire de paquets depot/app store n'a rien a voir avec la problematique en jeu, ces manifestes c'est pas une histoire de dependance ou securite sur le paquet lui-meme
Mais oui, je comprend rien, regarde plutôt ça:
Singularity’s third unique architectural feature, called “manifest-based programs,” represents another shift in orientation. Traditionally, operating systems have had no “knowledge” of a program’s composition, its purpose, or the resources it uses. Presented with a set of bits, the operating system would simply run them. Singularity, with its emphasis on overall system dependability, takes a different approach to ensure that a new program won’t “break” the programs already on board.
Comment ils font? 2 choix, soit le manifest décrit le fonctionnement du programme de façon formelle de façon à ce que le kernel puisse voir si c'est normal ou pas.
Soit le manifest ne contient que des informations de plus haut niveau qui permettent à l'OS de choisir de l'exécuter ou pas.
Dans le 2ème cas, le kernel devrait vérifier que le manifest soit pas bidonné, donc, il faut utiliser l'analyseur statique pour vérifier le code.
J'aime l'idée du manifest qui indique les besoins d'un programme, c'est une très bonne chose. Mais c'est pas au kernel de vérifier ça! C'est à un dépôt de vérifier ça puis de livrer les applications à l'utilisateur signées par le dépôt.
Alors, c'est qui qui a rien compris?
Quand à l'arrogance, je te retourne le compliment. Pourquoi la recherche sur la sécurité mémoire ne s'est pas arrêtée lors de l'arrivée de .net et C#? Oh, mais que je suis bête, c'est simplement parce que C# ne résout rien...
De toute façon, C# ne peut être meilleur que la virtualisation ... qui n'est pas de la sécurité.
Je le répète, je suis à l'aise avec ce sujet car j'ai fais mon mémoire de master sur la gestion d'accès aux pages mémoires, j'ai étudié la sécurité durant 3 ans (spécialité mobilité et virtualisation) et je débute dans l'écriture de driver (je bosse sur Nouveau, le driver libre nvidia). Tu fais quoi toi pour me traiter d'incapable?
Et puis si encore j'étais le seul: http://www.ok-labs.com/blog/entry/about-security-singularity-vs-l4-part-2/ Et j'ai passé 10s sur google pour le trouver.
Je ne traite pas Microsoft d'idiots, juste de personnes qui pensent avec le porte monnaie. Dire qu'ils travaillent sur un OS sécurisé, c'est dire on essaye de faire mieux, ça rassure et donc, ça rapporte à plus ou moins long terme.
Epic fail ? Non l'epic fail c'est toi qui ne comprend pas Singularity et qui n'a pas compris les avantages d'enlever cette barriere ainsi que les barrieres entre processus (message passing sans copie necessaire)
Bla, c'est du vent tout ça. Un processus qui tourne en ring0 reste un processus en ring0 même si y'a le miracle .net et de la vérification statique avant. Un processus en ring0 accède à ce qu'il veut, fait ce qu'il veut et court-circuite le kernel si il veut. C'est irresponsable comme concept.
Le coup du message passing (sans copies? et alors?) n'enlève rien à ce problème.
Tu vas le faire tourner comment ton programme non manage exactement ? T'as un API miracle pour le lancer ?
Un processeur exécute du x86 et pas du C#, y'a pas besoin d'API pour exécuter du code, simplement une zone mémoire où s'écrire et $ip placé au bon endroit.
Comment tu peux oser dire que .net empêche $ip d'aller dans cette zone? Alors oui tu peux marquer les pages mémoires avec les bons droits et utiliser le bit NX pour grandement empêcher ça mais un processus en ring0 a la possibilité d'enlever ce bit. Faire confiance à l'analyse statique pour vérifier ça, c'est vraiment chercher la merde.
Merci, ça m'a permis de lire des âneries derrière cette idée de Singularity:
1) Cool, vérifions statiquement qu'un programme se comporte comme on veut et faisons encore une fois abstraction du hardware.
2) Et puis le choix du C# pour éviter les débordements de tampon, trop bien! C'était pas possible de faire une API pour la gestion des 3/4 pauvres chaines de caractère qui traînent dans le noyau? Ah ben non, c'est vrai, on est dans un modèle de kernel propriétaire et on peut pas faire confiance aux devs de drivers. C'est ça leur problème! Un kernel DOIT être ouvert et développé par tous les créateurs de drivers.
3) Cool, on va faire un OS qui réagit différemment suivant le type de programme, juste pour rigoler. Parce que c'est vrai, le kernel est mieux placé pour juger des besoins d'un programme plutôt que le programme lui même. C'est ça le principe des manifests (outre l'analyse statique pour vérifier que le comportement est bon avant de l'installer). Sérieux, ils pourraient pas faire comme tout le monde et proposer un gestionnaire de paquet et des dépôts/app store? Eux peuvent être vérifiés statiquement.
Au final, je trouve qu'il ont bien choisi le nom. Avec ce kernel, ils approchent de la Singularity et du trou noir que pourrait être l'informatique, gigantesque (dépend d'un analyseur statique!), invérifiable, instable et affreusement complexe.
[^] # Re: Petites erreurs dans le descriptif sur Nouveau
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 3.1. Évalué à 3.
Un petit "Up" pourrait attirer l'attention. Je te conseille de tester le kernel nouveau. Un fix est peut être déjà disponible.
Si ça marche toujours pas, il va falloir faire une trace du driver propriétaire lors de la mise en veille et son réveil: http://nouveau.freedesktop.org/wiki/MmioTrace
[^] # Re: Petites erreurs dans le descriptif sur Nouveau
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 3.1. Évalué à 4.
Comme pour tout, il faut remplir un bug report ou au moins venir sur #nouveau.
[^] # Re: Petites erreurs dans le descriptif sur Nouveau
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 3.1. Évalué à 8.
Arg, c'est le genre de bug qu'il y a uniquement avec certains matos. Et bien sûr, les PCs des développeurs n'ont pas tous les bugs possible (et c'est bien dommage au final)...
Si tu veux aider sur ce point, on peut te donner des directions :)
[^] # Re: Petites erreurs dans le descriptif sur Nouveau
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 3.1. Évalué à 3.
La magie des OEM. Ça arrive et si ta carte est instable, c'est possible que ça vienne de là.
[^] # Re: Petites erreurs dans le descriptif sur Nouveau
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 3.1. Évalué à 10.
La situation n'est pas perdue. J'ai le code pour changer les clocks de ta carte aussi souvent que tu veux, même quand tu joues. Je suis en train de faire merger ça dans le kernel.
J'espère que ça sera dans le 3.3. Je vais presser le mainteneur.
[^] # Re: Petites erreurs dans le descriptif sur Nouveau
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 3.1. Évalué à 9.
Quelques conseils:
Les geforce inférieures à 8 sont, en général, réputées pour leur performance. C'est dû au fait qu'elles sont pour la plupart toutes clockée à leurs fréquence maximale ou presque au boot. De plus, la fréquence de la mémoire (qui influe énormément sur les performances, presque linéairement) était la plupart du temps fixée à son maximum.
[^] # Re: Petites erreurs dans le descriptif sur Nouveau
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 3.1. Évalué à 10.
Pour info, je travaille sur la gestion d'énergie dans Nouveau depuis un peu plus d'un an.
Suivant les cartes, on arrive à avoir entre 60 et 80% des performances du driver propriétaire quand la carte tourne à la même fréquence que Nouveau.
Il faut savoir que par défaut, la carte boote avec des fréquences de fonctionnement inférieures à leur maximum. C'est cette limitation qui fait que Nouveau peut être extrêmement lent ou assez rapide. Ces informations sont accessibles dans les logs kernel:
Cet example est celui de ma carte Fermi nvc4. La dernière ligne (c:) indique les fréquences actuelles. Les lignes d'avant définissent les niveaux de performance tels qu'on peut les lire dans le bios de la carte.
On voit que la vitesse de ma ram est inférieure à 1/10 de sa fréquence maximale. Les performances seront vraiment ridicules comparées au driver propriétaire.
J'essaye de faire fusionner mes modifications pour pouvoir changer les fréquences sans crasher la carte. Cependant, ça demande de pouvoir monitorer à la fois la température et gérer la vitesse du ventilateur, 2 choses qui sont très mal normalisées et qui rate assez souvent. On a encore du boulot avant d'être sûr qu'on ne va pas cramer votre carte en l'upclockant...
J'ai réussi à faire plus ou moins marcher le changement automatique de fréquence en fonction du taux d'utilisation de la carte. Quand j'aurai un truc qui marche bien sur toutes les nv50-a3, je demanderai à inclure ce code. En attendant, je travaille avec Ben Skeggs, le mainteneur nouveau, pour faire entrer mes patchs et optimisations de la consommation.
[^] # Re: Petites erreurs dans le descriptif sur Nouveau
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 3.1. Évalué à 9.
De rien. Au dernier noyau, je m'étais promis de venir prêter main forte ici pour vérifier et compléter le travail sur Nouveau. Il semblerait que j'ai encore oublié.
Ce n'est que partie remise.
# Petites erreurs dans le descriptif sur Nouveau
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 3.1. Évalué à 10.
Petites corrections:
Fµc: Flexible microcode. On l'appelait Fermi microcode avant, mais il se trouve que les premiers moteurs à l'utiliser ont été introduis sur les nv98. On l'a donc renommé pour montrer à quel point cette ISA et le moteur d’exécution qui lui est associé sont génériques. Pour information, Fµc est utilisé pour définir les interfaces entre l'OS et le hardware (command submission) dans certains moteurs tel que PGRAPH (rendu 2D/3D), PCRYPT, PDAEMON (une sorte de RTOS qui tourne dans la carte graphique), video decoding et plein d'autres.
Avant, le rendu ne nécessitait pas l'écriture de microcode en Fµc. La situation a changée avec Fermi ce qui a empêché d'avoir une accélération graphique totalement libre pendant un long moment.
L'utilisation de Fµc est encore plus générale dans Keppler, la prochaine architecture de NVidia dont on a un aperçu avec les nvd9. En effet, une bonne partie des moteurs d'exécution ont été convertis à Fµc. Pour l'instant, seul le modesetting marche sur ces cartes (je vous écris un message avec là). Dans ce cas là, l'accélération graphique est effectuée par le driver gallium llvm.
Le microcode de PGRAPH ne marche pas sur les nvc1. Le problème est en cours d'analyse.
Pour ceux qui sont intéressés par le statut général de Nouveau, vous pouvez consulter la présentation que j'ai faite à l'XDS2011: https://github.com/mupuf/xdc2011-nouveau/blob/master/nouveau.pdf
Un résumé rapide de l'XDS2011 est aussi disponible sur mon blog: http://mupuf.org/blog/article/52/
[^] # Re: Quels avantages à installer un noyau 64 bits ?
Posté par Martin Peres (site web personnel) . En réponse au journal Quels avantages à installer un noyau 64 bits ?. Évalué à 4.
Tu veux pas dire segmentée? C'est bien comme ça qu'on l'appelle quand on a un segment:offset, non?
[^] # Re: Déhu et autres
Posté par Martin Peres (site web personnel) . En réponse au journal Nom de geek pour une chatte ?. Évalué à 1.
Voleur de blague!
J'appelle le mien Terton même si c'est un femelle. Même si c'est pas son nom de baptême (Phoebe, en rapport avec 2 series américaines hautement intellectuelles), elle se reconnait, c'est le principal!
[^] # Re: Ceux qui ont oublié l'histoire, sont condamnés à la revivre.
Posté par Martin Peres (site web personnel) . En réponse au journal Mozilla concurrence OpenID. Évalué à 3.
Tu n'exagères pas un petit peu? C'est pas incompréhensible, c'est juste pas adapté à tous les cas d'utilisations (besoin d'un temps partagé) ;) Et puis, si même microsoft l'a mis en place (dans Active Directory), c'est que ça doit pas être si dur que ça de le faire comprendre aux admins (bonne journée à eux).
Perso, je vois pas comment quelqu'un pourrait garantir autant de propriétés de sécurité avec un protocole plus simple. C'est élégant d'un point de vue sécu, beaucoup moins d'un point de vue conso énergétique et latence d'accès aux services.
[^] # Re: Efficacité éléctrique ?
Posté par Martin Peres (site web personnel) . En réponse au journal Enfin l'accélération du décodage vidéo par la carte graphique sous linux !. Évalué à 10.
Ceci est une implémentation initiale. Le but final est bien sûr d'utiliser le hw dédié.
Pour Nouveau (je bosse que sur ce driver), on sait décoder du mpeg 2 en hardware pour les geforce 7 jusqu'aux geforce 9. Pour AMD, pas de docs. Peut être Jérome Glisse pourra nous dire plus :)
Quelqu'un est en train de voir de notre coté comment gallium pourrait se servir du circuit de décodage mpeg2. Ça sera la première implémentation libre qui utiliserait un décodage totalement hardware :).
[^] # Re: systemd c'est pour les filles, Wayland c'est pour les mecs
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 1.
C'est typiquement ce que j'aimerai qu'il explique dans "X vs Wayland".
Mais je ne sais pas si c'est très pertinent de poser ce genre de questions car c'est peut être un peu trop technique/spécifique. Cela dit, je suis probablement mal placé pour préparer des questions, c'est pour ça que j'ai proposé quelque chose de vague pour laisser une grande liberté à la personne interviewée.
Cela dit, y'aurai peut-être moyen que je fasse une vidéo-interview lors du projet XDS (Septembre) si vous me fournissez les questions.
[^] # Re: systemd c'est pour les filles, Wayland c'est pour les mecs
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 4.
En effet, une interview de Kristian Høgsberg, ce serait cool.
Idées de questions:
Origine du projet?
Qu'a permis son changement d'employeur (Red Hat -> Intel)?
X vs Wayland: Ce que permet de faire l'un et pas l'autre.
Wayland, la communauté?
Ses objectifs actuels
Pour information, j'ai discuté avec Kristian lors de l'XDS2010 qui s'est déroulé à Toulouse. C'est une personne très sympathique mais avec de fortes convictions (comme tous et c'est normal). Il répond généralement quand on lui pose une question sur IRC, même basique. Je suppose donc qu'il ne dira pas non pour se soumettre au jeu de l'interview :)
[^] # Re: Modestie...
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Un entretien avec Lennart Poettering. Évalué à 4.
Exact, la pile graphique de Vista/7 est vraiment pas mauvaise!
Autre truc excellent que l'on est loin de pouvoir faire, c'est la migration à chaud d'un GPU à l'autre (optimus et consors). Dave Airlie travaille à ce qu'une carte nvidia puisse écrire dans le scanout buffer d'un IGP intel. C'est un premier pas pour pouvoir choisir la carte qu'on veut utiliser au démarrage de X dans le cas où il n'y aurait pas de multiplexer hardware sur la sortie vidéo. Pour la migration à chaud, faudra probablement attendre Wayland (ça suffirait pour utiliser la carte que l'on veut utiliser au démarrage d'une application) et quelques modifications dans les toolkits (pour se re-créer un contexte graphique sur la nouvelle carte et faire son rendu si l'on veut switcher tout le système).
Cela dit, comme souvent chez doz, je suppose que les drivers doivent y être pour énormément. N'empêche que sur ce point là, ils ont fait fort chez crosoft.
[^] # Re: Tiens, autre info
Posté par Martin Peres (site web personnel) . En réponse au journal KDE 4.7 beta1 was out. Évalué à 2.
Encore plus mieux, la rc1 arrive: http://osdir.com/ml/release-team/2011-06/msg00205.html
Merci pour ce journal, ça donne effectivement envie de tester :)
[^] # Re: Bonne interview
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Linus Torvalds : l’interview anniversaire des 20 ans du noyau. Évalué à 0.
Bon, on va dire que j'ai peur de voir un modèle comme ça appliqué parce que le système de vérification de code est complexe.
En tous cas, bonne explication! Cela dit, pourquoi ne pas simplement vérifier le code en userspace, pourquoi ré-écrire le code du kernel. Je trouve vraiment pas ça pertinent. Qu'on le veuille où non, les drivers utiliseront toujours des pointeurs et c'est dans les drivers que les failles seront trouvées.
On retombe donc sur un problème de vitesse de résolution de la faille et sur ce terrain, le libre a son intérêt. Même si le kernel n'est pas prouvé, le temps entre la découverte d'une faille et l'arrivée du patch est généralement de quelques heures. Il suffit d'appliquer le correctif sur son kernel et tout est bon. Cela dit, quid des failles pas publiques? Là, on est obligé de limiter l'exécution de code à des binaires plus ou moins prouvés par l'expérience. Sur ce point, l'aspect centralisateur des dépôts est un bon point car les vérifications de l'un participe aux autres. Et puis il est toujours possible de faire tourner tous les analyseurs statiques qu'on veut sur les sources.
Au final, je dirai que l'idée a le mérite d'exister. Comme tu dis, on verra si ça marche en pratique.
[^] # Re: Bonne interview
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Linus Torvalds : l’interview anniversaire des 20 ans du noyau. Évalué à 4.
Sur le fond tu as pas tord, mais faut pas exagérer non plus. Le concept de ring est assez simple à implémenter et puis, c'est pas dur pour la MMU de regarder le ring actuel et regarder les flags de la page mémoire pour comparer et générer ou non un page_fault.
Comparer ça aux milliers de lignes nécessaires dans l'OS pour arriver à se passer du concept de ring, c'est osé ;)
Pour le coup de l'OS qui doit faire abstraction du matos, c'est vrai d'un point de vue userspace, mais pas d'un point de vue kernel space. Le kernel doit utiliser autant que possible le matériel car il est plus rapide et consomme moins d'énergie que le software.
[^] # Re: Bonne interview
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Linus Torvalds : l’interview anniversaire des 20 ans du noyau. Évalué à -2.
Oui, je suis 100% d'accord, mais dans l'absolu, un compilateur (JIT ou pas) ne peut pas toujours prouver que l'on ne sortira pas du tableau. C'est plus le rôle d'un analyseur statique de faire ça, et même là, c'est pas toujours la joie.
[^] # Re: Bonne interview
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Linus Torvalds : l’interview anniversaire des 20 ans du noyau. Évalué à -2.
Ok, si les concepts généraux ne sont pas dans la page d'intro, dans ce cas là la page est mal faite. Je lirai peut être un jour les articles, en attendant, je crois pas au futur du truc.
Roo, calme toi. Je te parle d'une interface de manipulation de tableau avec vérification des accès à l'exécution, et toi tu pars direct sur; ça suffit pas pour faire un kernel. Tu dérailles là, bien sûr que ça suffit pas.
En effet, j'ai dis de la grosse merde là. J'ai très très mal formulé ce que je voulais dire. Tu as 100% raison là dessus.
Et tu crois pour je ne sais quelle raison qu'on arrivera jamais à trouver une faille qui va faire qu'on va pouvoir exécuter du code. C'est ça que je trouve scandaleux de la part d'une équipe de sécurité, avoir une confiance aveugle en son système au point de faire tourner tout programme en ring0.
Ou simplement aussi que ça ralentit énormément les accès mémoires. Je pense que là dessus, on a plus rien à dire.
Ou simplement tu oublies encore les failles dans les drivers. La virtualisation ne fait qu'augmenter la surface d'attaque. Actuellement, root sur une VM rime avec root sur l'host tellement il y a de failles.
Moi je trouve arrogant de la part de l'équipe de Singularity d'enlever l'interface userland/kernel.
Sinon, ça veut dire que tu as participé à la création de MIC? J'ai bien aimé l'idée de forcer les gens à utiliser un système de contrôle d'accès mandataire, mais le faire se baser sur des niveaux d'intégrité, c'est vraiment pas géant à mon goût. Je suis plus fan des labels et de la création de domaines car ça permet de segmenter les tâches en activités.
C'est vrai que vérifiable et sécurité, c'est pas associé du tout. M'enfin, c'était pas le truc que je voulais montrer. Tu me demandes comment le code malicieux pour arriver comme ça et être exécuté. Moi je dis, prouve moi que c'est impossible. Jusqu'à preuve du contraire, je continuerai à penser que c'est possible, donc ça va arriver.
En fait, je trouve nos approche vraiment opposées. Pour moi, un pourrait potentiellement arriver si les étoiles sont alignées etc... = arrive. Pour toi, c'est un pourrait arriver = peu probable.
[^] # Re: Bonne interview
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Linus Torvalds : l’interview anniversaire des 20 ans du noyau. Évalué à 1.
C'est simple, si ça plante pas, c'est que les accès aux éléments d'un tableau sont vérifiés à l’exécution. Bonjour les perfs quand tu fais que manipuler des structures de données comme dans ... un kernel?
Si ça te laisse faire (depuis quand ça devrait crasher le processus? C'est juste quand tu sors des pages mémoires qui t'ont été mappées par le kernel dans ta mémoire virtuelle que tu te récupères un segfault), alors c'est que c'est pas vérifié. C'est ce que fais C/C++.
On peut avoir le meilleur des 2 mondes (le débug facile de Python/Ruby/Java) et les perfs de C grâce à valgrind (userland uniquement) qui te vérifiera tous tes accès mémoires. Mais faudra coder en C pour avoir les perfs de C.
[^] # Re: Bonne interview
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Linus Torvalds : l’interview anniversaire des 20 ans du noyau. Évalué à 1.
Il est impossible de prouver une propriété en faisant de l'analyse statique pour la bonne et simple raison qu'il est impossible pour un programme de vérifier tous les cas. C'est un truc que tu vois dans les 20 premières minutes d'un cours sur l'analyse statique. La seule solution pour prouver le bon fonctionnement d'un programme en un temps raisonnable, c'est de générer des tonnes de faux négatifs. Ça revient à demander à un compilateur de générer des patterns de code. Pourquoi pas, mais c'est documenté? Quid de la vitesse d'exécution?
Un exemple, tu peux vérifier que les appels systèmes sont bien les bons et appelés seulement avec une adresse immédiate (miam le cassage de programmes existants).
Mais au final, c'est quoi un appel système dans un OS comme ça? Ça existe pas, c'est plus un espèce de gros tas qui prétend être tenu en place par de l'analyse statique de tous les cotés.
Tu lis vraiment ce que tu veux lire. C'est le seul intérêt de C# citée dans http://research.microsoft.com/en-us/news/features/singularity.aspx . Je m'arrête donc là.
Si tu veux vraiment éviter les buffers overflows, il faut contrôler la création de buffers puis tous les accès subséquents. La seule façon crédible de faire ça et vérifier à l'exécution et la seule façon de vérifier et de faire des processeurs qui soient au courant de la taille de ton "buffer".
Ça a déjà été "fait": http://www.cc.gatech.edu/~idoud/documents/TAINTTC.pdf
Maintenant explique moi comment fait .net pour empêcher les buffers overflow alors? C'est de la programmation orientée objet, et une vérification à la compilation à moins que .net interprète ton code.
Et je me répète, mais y'a pas que les processus qui font des accès mémoire, le matériel aussi. Et le matériel peut être programmé pour faire un accès mémoire qui va modifier les bits que tu veux au bon endroit même si la page mémoire est marquée comme ro (et oui).
Mais oui, je comprend rien, regarde plutôt ça:
Comment ils font? 2 choix, soit le manifest décrit le fonctionnement du programme de façon formelle de façon à ce que le kernel puisse voir si c'est normal ou pas.
Soit le manifest ne contient que des informations de plus haut niveau qui permettent à l'OS de choisir de l'exécuter ou pas.
Dans le 2ème cas, le kernel devrait vérifier que le manifest soit pas bidonné, donc, il faut utiliser l'analyseur statique pour vérifier le code.
J'aime l'idée du manifest qui indique les besoins d'un programme, c'est une très bonne chose. Mais c'est pas au kernel de vérifier ça! C'est à un dépôt de vérifier ça puis de livrer les applications à l'utilisateur signées par le dépôt.
Alors, c'est qui qui a rien compris?
Quand à l'arrogance, je te retourne le compliment. Pourquoi la recherche sur la sécurité mémoire ne s'est pas arrêtée lors de l'arrivée de .net et C#? Oh, mais que je suis bête, c'est simplement parce que C# ne résout rien...
De toute façon, C# ne peut être meilleur que la virtualisation ... qui n'est pas de la sécurité.
Je le répète, je suis à l'aise avec ce sujet car j'ai fais mon mémoire de master sur la gestion d'accès aux pages mémoires, j'ai étudié la sécurité durant 3 ans (spécialité mobilité et virtualisation) et je débute dans l'écriture de driver (je bosse sur Nouveau, le driver libre nvidia). Tu fais quoi toi pour me traiter d'incapable?
Et puis si encore j'étais le seul: http://www.ok-labs.com/blog/entry/about-security-singularity-vs-l4-part-2/ Et j'ai passé 10s sur google pour le trouver.
Je ne traite pas Microsoft d'idiots, juste de personnes qui pensent avec le porte monnaie. Dire qu'ils travaillent sur un OS sécurisé, c'est dire on essaye de faire mieux, ça rassure et donc, ça rapporte à plus ou moins long terme.
[^] # Re: Bonne interview
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Linus Torvalds : l’interview anniversaire des 20 ans du noyau. Évalué à -6.
Bla, c'est du vent tout ça. Un processus qui tourne en ring0 reste un processus en ring0 même si y'a le miracle .net et de la vérification statique avant. Un processus en ring0 accède à ce qu'il veut, fait ce qu'il veut et court-circuite le kernel si il veut. C'est irresponsable comme concept.
Le coup du message passing (sans copies? et alors?) n'enlève rien à ce problème.
Un processeur exécute du x86 et pas du C#, y'a pas besoin d'API pour exécuter du code, simplement une zone mémoire où s'écrire et $ip placé au bon endroit.
Comment tu peux oser dire que .net empêche $ip d'aller dans cette zone? Alors oui tu peux marquer les pages mémoires avec les bons droits et utiliser le bit NX pour grandement empêcher ça mais un processus en ring0 a la possibilité d'enlever ce bit. Faire confiance à l'analyse statique pour vérifier ça, c'est vraiment chercher la merde.
[^] # Re: Bonne interview
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Linus Torvalds : l’interview anniversaire des 20 ans du noyau. Évalué à -3.
Merci, ça m'a permis de lire des âneries derrière cette idée de Singularity:
1) Cool, vérifions statiquement qu'un programme se comporte comme on veut et faisons encore une fois abstraction du hardware.
2) Et puis le choix du C# pour éviter les débordements de tampon, trop bien! C'était pas possible de faire une API pour la gestion des 3/4 pauvres chaines de caractère qui traînent dans le noyau? Ah ben non, c'est vrai, on est dans un modèle de kernel propriétaire et on peut pas faire confiance aux devs de drivers. C'est ça leur problème! Un kernel DOIT être ouvert et développé par tous les créateurs de drivers.
3) Cool, on va faire un OS qui réagit différemment suivant le type de programme, juste pour rigoler. Parce que c'est vrai, le kernel est mieux placé pour juger des besoins d'un programme plutôt que le programme lui même. C'est ça le principe des manifests (outre l'analyse statique pour vérifier que le comportement est bon avant de l'installer). Sérieux, ils pourraient pas faire comme tout le monde et proposer un gestionnaire de paquet et des dépôts/app store? Eux peuvent être vérifiés statiquement.
Au final, je trouve qu'il ont bien choisi le nom. Avec ce kernel, ils approchent de la Singularity et du trou noir que pourrait être l'informatique, gigantesque (dépend d'un analyseur statique!), invérifiable, instable et affreusement complexe.