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?
Qui t'a dit que ca s'arrete a l'analyse statique ?
Et tu rates la moitie du truc quand tu t'arretes a une page d'introduction
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
Et tu crois que qqe APIs suffisent pour un kernel ? Tu n'as visiblement aucune idee de ce qu'un kernel contient.
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).
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).
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.
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.
Pourquoi centraliser qqe chose qui n'a pas besoin d'etre centralise ? Si un depot ne contient pas le soft que tu veux alors tu peux pas le lancer ? Super
à 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...
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.
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.
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?
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.
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..
[^] # Re: Bonne interview
Posté par pasBill pasGates . 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?
Qui t'a dit que ca s'arrete a l'analyse statique ?
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à.
Et tu rates la moitie du truc quand tu t'arretes a une page d'introduction
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
Et tu crois que qqe APIs suffisent pour un kernel ? Tu n'as visiblement aucune idee de ce qu'un kernel contient.
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).
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).
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.
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.
Pourquoi centraliser qqe chose qui n'a pas besoin d'etre centralise ? Si un depot ne contient pas le soft que tu veux alors tu peux pas le lancer ? Super
à 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...
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.
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.
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?
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.
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.
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..