pasBill pasGates a écrit 16349 commentaires

Tu veux dire que c'est aux developpeurs Microsoft de faire des themes pour dflp ?

Eh bien, on va en avoir du boulot si c'est a nous de devoir faire des themes pour tous les sites de la planete...

Chez MS on sort des patchs pour des problemes qualifies d'importants.

Question: est-ce que ce bug est important ?

- Il peut-etre declenche en remote ? Non
- Il arrive frequemment ? Non, il faut le faire explicitement, 99.9999% des softs ne font pas ca.
- Elevation de privilege en local ? Non
...

Bref, ce bug est un petit DoS en local, pas tres utile car le coupable est trouve dans les 30 secondes et se fera empaler sur un pieu.

Resultat: ca merite pas qu'on sorte un hotfix, ca veut pas dire qu'on ne le corrigera pas dans un SP ou SRP cependant.

Ben j'imagines que c'est du au fait que nombre de choses initialisees au depart ne peuvent plus l'etre a ce moment, ou autres trucs du genre qui font qu'il n'est pas possible de revenir a un etat utilisable apres avoir kille Win32, mais ce n'est qu'une supposition, Dave Cutler sait ca surement mieux que moi :+)

Sinon, c'est vrai que ca serait tellement mieux si toutes les discussions etaient de ce type.

Par defaut Win2k sauve le dump(ce que tu vois a l'ecran et d'autres infos).

Control Panel -> System -> Advanced -> Startup and recovery

Win32 est de tres tres loin le plus utilise, le plus complexe et le plus gros, c'est pour ca qu'il y a plus de bugs la que dans les autres.

Notes que dans ce cas la ca vient de Win32, d'autres fois ca peut etre autre chose(bug driver, bug kernel,..).

Lire les ecrans bleus ca donne souvent pas mal d'infos sur la raison du crash.

Parce que le kernel a aucune idee de qui a demande quoi a Win32, il sait juste que Win32 a fait une grosse connerie(acces illegal dans ce cas), ca dit pas si cette connerie etait tellement grosse qu'elle a corrompu des donnees vitales dans Win32 auquel cas il vaut mieux killer le process plutot que risquer d'avoir une perte ou corruption de donnees plus grave, et le kernel peut pas deviner non plus si le bug en question est du a l'application ou si c'est un bug interne a Win32.

En gros, la solution la plus sure pour eviter de foutre le merdier dans les donnees de l'utilisateur c'est de killer un process qui fait une grosse connerie, quel que soit le process.

Je connais pas Hurd assez bien pour faire une comparaison, mais le truc principal selon moi qui fait que c'est pas un micro-kernel au sens puriste du terme est que dans winNT/2000/XP, les drivers tournent en mode privilegie, par contre les sous-systemes eux ne tournent pas en mode kernel.

Le process Win32 n'a pas ecrit n'importe ou dans la memoire et fait crasher l'OS, il s'est fait killer par le kernel car il a essaye d'ecrire n'importe ou, et apres le kernel qui continuait a tourner sans prob, s'est rendu compte que sans Win32, ben il n'y a plus rien de faisable --> reboot ou ecran bleu.

C'est un sous-systeme, une sorte de mini-OS, rien a voir avec init.

Sous NT t'as les sous-systemes :
- Win32
- Posix
- OS2

par defaut.

Win32 t'apporte l'API win32, les fenetres Windows, blabla...
Posix t'apporte.... Posix :+)
OS2 te permet de faire tourner les softs OS2(16bit only je crois)

Une app tourne dans un et un seul sous-systeme, tu peux pas avoir une API Posix qui joue avec l'API Win32 par exemple.

En gros, en theorie tu pourrais faire tourner un tas de systemes differents par dessus le kernel NT(que j'appelerais personnellement un micro-kernel hybride, car il en a certains traits, mais pas tous).

Ce probleme n'existe pas sous NT, Win9x lui par contre...

Tiens, j'ai dit une grosse connerie(certains diront: comme d'hab).

La fonction qui ecrit dans les choux, elle fait partie du sous-systeme Win32, vu que le kernel n'apprecie pas cette chose(en fait la partie verif est dans Win32, la fctn d'ecriture est dans Win32(celle qui crash) et l'AV est la aussi), il kill Win32, et comble de malchance, le kernel n'a rien a faire quand Win32 est kille, donc le kernel affiche un ecran bleu et s'arrete ou reboot selon la config qu'on a.

Je me suis laisse emporter en voyant que le fichier etait dans les repertoires habituellement reserves au kernel, mais ce qui crashe ne tourne pas en mode kernel, simplement le kernel fait un BSOD car il n'a plus rien a faire(sans Win32, le kernel ne sert a rien)

En gros le fautif c'est Win32, pas le kernel(j'esperes que le kernel me pardonnera cette diffamation involontaire).

Ben je suis pas sense parler des raisons et causes de trucs [non/pas encore] releases, donc je dirais simplement:
- Entre l'appel a printf, et l'affichage des caracteres a l'ecran tu passes par plein de couches
- Pour afficher un pixel a l'ecran, faut que tu passes par le kernel a un moment ou un autre
- Quand certaines fonctions du kernel sont appelees par des fonctions jugees "sures", elles ne verifient pas les parametres et ecrivent ou on leur dit d'ecrire, car c'est a la fonction appelante de faire le boulot de verif(ca fait moins de boulot cote kernel).

Meme sous MS.

runas.exe

Ces bugs n'ont RIEN a voir avec la segmentation memoire.

Ils font appel a une fonction en mode kernel, qui elle a un bug, d'ou le crash.

Ouaif, je sais pas si on peut considerer le CERT comme des consultants voulant jouer au malin.

C'est surement pas le probleme de securite le plus important de l'univers, mais ca donne des infos sensibles(logins des users), c'est pas visible a l'utilisateur, et en cela c'est une faille meme si c'est pas l'equivalent d'une elevation de privilege.

Non, beaucoup voir peut-etre tous(j'ai pas compte) sont expliques dans le manuel de Windows2000 a la fin du manuel.

Ben il me semble que le logiciel proprio ca a toujours ete ca non ?

On te vend le droit d'utiliser le soft, on te vend pas le soft lui-meme.

Parce que justement, cette limite de 1 seul user en meme temps vient du fait que tu passes par ces API.

Si je modifie VNC pour qu'il s'occupe de creer des processus pour 4 users differents et faire l'affichage, rien n'empeche plus 4 users d'etre en meme temps sur la machine(ca revient a avoir 4 sockets connectes a un VNC qui fait l'affichage pour 4 personnes, pas un probleme technique), sans possibilite de verifier les licences, car t'as un VNC qui tourne dans l'unique session permise, mais il cree des process pour 4 users et s'occupe de l'affichage, bref 4 users utilisent la machine en meme temps.

Le fait de pouvoir faire tourner des process de 2 users differents en meme temps c'est justement le probleme(et non sous Win9x c'est impossible, il n'y a aucune notion de user sous Win9x), ca permet de completement separer 2 sessions et il reste plus qu'a se charger de l'affichage --> ce que veut controler MS pour eviter les violations de licence.

Ben c'est bien, t'as un probleme et tu mets un peu du tiens pour trouver ce qui cloche, c'est cool.

Si tu veux des conseils/infos t'as qu'a demander.

Moi j'adores me la peter.

Le truc etant que MOI je ne m'amuses pas a critiquer un OS avec des arguments bidons. Je m'amuses juste a corriger ceux qui s'amusent a critiquer avec des arguments bidons.

Maintenant ca peut ne pas te plaire, libre a toi.

Quand a denier leur propre faute, tu m'expliqueras.

Je sais pas vraiment comment marche VNC, mais le truc est que sur Win95, c'est simplement impossible d'avoir 2 utilisateurs differents sur la machine en meme temps car l'OS ne sait pas gere 2 users en meme temps sur la machine.

Avec NT4 TS/XP/W2k c'est possible car ils sont multi-user, tu peux avoir des process appartenant a des users differents qui tournent sur la machine en meme temps, ca ouvre une possibilite technique d'outrepasser TS et utiliser son propre soft pour avoir plusieurs personnes loggees en meme temps.

A mon avis faut pas voir ce truc comme dirige contre VNC en particulier, c'est pour un type de violation de licence, et peut-etre bien que selon les usages VNC n'entre pas dans la liste des produits interdits.

Ah oui, le truc ou il faut payer encore des licences.

Non.

Tu ne payes pas pour utiliser Terminal Services, tu payes pour utiliser le Windows auquel tu te connectes en utilisant Terminal Services.

Quand a IPSEC, ben c'est con, beaucoup de gens s'en servent et savent le configurer. D'autres dont toi ont des problemes incroyables avec, quelle malchance quand meme, faut croire que Windows t'en veut personnellement.

Rien a voir avec open source.

Si une lib X n'est pas en standard avec ta distrib les gens doivent faire quoi ? la mettre en statique...

C'est juste une question de choix de l'editeur(de distrib ou de Windows)

Ca ne limite pas les sessions distantes aux clients MS.

Ca dit "pour afficher le display de XP, il faut passer par NetMeeting, Remote assistance ou Remote Desktop".

Ce qui veut dire:

T'utilises n'importe quel client que tu veux, mais il doit passer par un de ces 3 points d'entree, la raison etant que ca permet a MS de limiter le nombre de connections simultanees en fonction du nombre de licences dispo. Si t'utilises un truc qui passe outre, MS n'a aucun moyen de verifier que t'as pas 50 personnes connectees sur la machine en meme temps.

Chacun son truc, nous on a deja decouvert Terminal Services au dessus de IPSEC depuis un moment.

Pour ceux qui ne sont pas sectaires, il y en a un par defaut dans Win2000 qui s'appelle PageHeap.

Il se trouve dans le resource kit et/ou le SDK.

Ca permet de modifier les allocations pour n'importe quel executable(faut juste lancer l'outil en specifiant le nom du soft avant de lancer ledit soft) de plusieurs manieres:
- "full": chaque allocation est placee a la fin d'une page avec une guard page apres --> AV direct si il y a un ovverun, et il detecte les underrun en remplissant le debut de la page avec un pattern
- "light": plusieurs alloc par page, mais avec des pattern pour detecter les overrun/underrun, defaut: le probleme n'est detecte qu'au moment du free. Avantage: ca bouffe vachement moins de RAM.

Pas besoin de torcher ca a coup de [-], ca pourrait servir pour les softs libres developpes sous Windows.