C'est noté pour la stack. Il me semble que tu as affirmé à plusieurs reprises sur ce forum qu'il n'y avait aucun rapport entre NT et 95, et d'un seul coup tu nous dis que tu n'as pas accès au code de 95. Serais-tu donc un pipoteur ?
Pour les drivers graphiques, c'est simple, l'écrasante majorité des cartes graphiques sous linux ne nécessite pas de module noyau. Le support noyau est minimal (en gros il permet d'envoyer des commandes à la carte, par exemple sur le bus agp) et le driver de la carte graphique s'exécute en mode utilisateur. De ce fait, en général quand X plante, ce qui peut parfois arriver, le noyau ne plante pas (en général). J'ai lu dans divers journaux informatiques (pas très sérieux comme source, je l'admets) que les drives de cartes graphiques s'exécutent entièrement en mode noyau sous Windows. C'est une source d'instabilité notoire. Tu peux ne pas me croire, mais ma machine plante très souvent sous XP et jamais sous linux. Je suis presque sûr que cela vient des drivers NVidia car quand je fais des mises à jour, les plantages changent. Le truc fun, c'est que ça plante assez brutalement, genre BSOD....
Nous sommes d'accord sur le fait que l'interprétation de code n'est pas un problème du noyau Windows. Cependant, comme tu l'as dit plusieurs fois ici, et comme l'affirme régulièrement MS, livrer Windows sans IE est impossible. Je te renvoie aux derniers numéros de MISC (5 par exemple) pour une description des vulnérabilités monstrueuses d'IE, en général liées à de graves erreurs de conceptions.
Concernant le trust entre les fenêtres, le problème est bien entendu qu'il faut suivre des "guidelines". L'expérience montre que les gens ne le font pas et qu'il est donc très important que le système empêche les programmeurs de faire des conneries. Les mécanismes de type chroot ou jail permettent de lancer un soft suid root de façon à limiter les problèmes. Je ne pense pas qu'on puisse faire la même chose pour le trust entre fenêtre, i.e. lancer une appli fenêtrée en bloquant le trust. Il y a donc bien un risque (même minime) lié à un mécanisme qui est peut être pratique mais qui n'est pas bien conçu du point de vue de la sécurité.
[^] # Re: Interview de Steve Ballmer
Posté par boubou . En réponse à la dépêche Interview de Steve Ballmer. Évalué à 3.
Pour les drivers graphiques, c'est simple, l'écrasante majorité des cartes graphiques sous linux ne nécessite pas de module noyau. Le support noyau est minimal (en gros il permet d'envoyer des commandes à la carte, par exemple sur le bus agp) et le driver de la carte graphique s'exécute en mode utilisateur. De ce fait, en général quand X plante, ce qui peut parfois arriver, le noyau ne plante pas (en général). J'ai lu dans divers journaux informatiques (pas très sérieux comme source, je l'admets) que les drives de cartes graphiques s'exécutent entièrement en mode noyau sous Windows. C'est une source d'instabilité notoire. Tu peux ne pas me croire, mais ma machine plante très souvent sous XP et jamais sous linux. Je suis presque sûr que cela vient des drivers NVidia car quand je fais des mises à jour, les plantages changent. Le truc fun, c'est que ça plante assez brutalement, genre BSOD....
Nous sommes d'accord sur le fait que l'interprétation de code n'est pas un problème du noyau Windows. Cependant, comme tu l'as dit plusieurs fois ici, et comme l'affirme régulièrement MS, livrer Windows sans IE est impossible. Je te renvoie aux derniers numéros de MISC (5 par exemple) pour une description des vulnérabilités monstrueuses d'IE, en général liées à de graves erreurs de conceptions.
Concernant le trust entre les fenêtres, le problème est bien entendu qu'il faut suivre des "guidelines". L'expérience montre que les gens ne le font pas et qu'il est donc très important que le système empêche les programmeurs de faire des conneries. Les mécanismes de type chroot ou jail permettent de lancer un soft suid root de façon à limiter les problèmes. Je ne pense pas qu'on puisse faire la même chose pour le trust entre fenêtre, i.e. lancer une appli fenêtrée en bloquant le trust. Il y a donc bien un risque (même minime) lié à un mécanisme qui est peut être pratique mais qui n'est pas bien conçu du point de vue de la sécurité.