Le 17/11/2012 à 08h 17

Tu réclamais un exemple. je te l’ai donnéplus haut

C’est pour OpenGL mais ça s’applique très bien à WebGL arrête d’être de mauvaise foi.

Comme je l’ai expliqué au dessus ça s’applique pour toutes les technologies qui utilisent les Shaders. Pourquoi WebGL y réchapperait? . Si c’était possible Microsoft l’aurait modifié au niveau du système.

De plus sachant qu’ils se basent sur DirectX pour les shaders, ça risque d’être dur de le gérer.

Le 17/11/2012 à 07h 45

Je crois que tu n’as pas compris pourquoi Microsoft a fait ça en fait.

Ils ne l’ont pas fait parce que les marchands de GPU ne peuvent pas le faire à leur place (ce qui serait complètement ridicule puisque ce sont eux qui font les pilotes de leur matériel quand même).

Ils ont fait ça parce qu’ils ne contrôlent pas ce que font les marchands de GPU, et qu’ils voulaient une solution qui garantisse à windows d’avoir des ressources dans tous les cas.

Il est tout à fait naturel pour Microsoft de prévoir un système qui puisse redonner la main à windows (qui utilise le GPU pour la composition de la GUI), au cas où une application trop gourmande viendrait à le monopoliser.

Ils font aussi ça pour faciliter le boulot des développeurs d’applications sous Windows.

Maintenant le constructeur du GPU peut trés bien implémenter des mécanismes bas-niveau pour faire la même chose dans le driver. Le pilote sait de quel contexte viennent les instructions qu’il doit exécuter (sans quoi il ne pourrait pas y avoir d’utilisation concurrente du GPU), il peut donc trés bien partager le temps d’exécution en fonction des contextes et éviter les problèmes de déni de service. Ce n’est pas quelque chose de facile à faire, car il est trés difficile d’arbitrer l’utilisation des ressources de façon “équitable”. Mais ce n’est pas impossible, et la solution de Microsoft dans ce domaine n’est pas universelle.



Ce que tu expliques c’est le fonctionnement actuel du multitache GPU cooperatif. où l’os et le constructeur essayent de diviser les paquets trop gros avant de les envoyer au GPU . Ce mécanisme est imparfait.

Sur un même execution context(le GPU en gère tout un tas ce qui garantit le parallélisme) le GPU ne sait pas interrompre la tache et redonner la main au noyau graphique. les documents que j’ai donné l’expliquent bien. c’est la raison même du dévelpppement du TDR. Tout comme les nombreuses applications qui provoquent des TDR à cause d’un shader trop lourd.

Pour faire le rapprochement avec le processeur, les premiers processeurs ne géraient pas les context switch et donc les premiers systèmes de l’époque utilisaient un multitache coopératif.

Le principe du multitache preemptif c’est que c’est géré directement par le matériel.

Pour WDDM 1.2 une carte graphique DirectX11 est obligatoire.

Je finirai en disant que ce mécanisme avait étéannonce par Microsoft dès 2006. Microsoft connaissait le problème depuis le début.

Le 16/11/2012 à 19h 14

Je viens de tomber sur cet article





problem with WebGL is poor graphics driver support for OpenGL. Chrome and Firefox have chosen a very radical approach to solve this: on Windows, they convert all WebGL GLSL shader code into DirectX 9 HLSL code through a converter called ANGLE.



Apparemment vu le support restreint des drivers OpenGL Firefox et Chrome convertissent les GLSL shader code en directX9 HLSL. Du coup ta théorie sur un OpenGL tuné pour WebGL ne tient pas debout ça passe par DirectX.

Le 16/11/2012 à 19h 01

Et désolé d’être obstiné, mais je ne peux pas te laisser dire n’importe quoi sur WebGL. Tu t’appuies certes sur des articles de Microsoft parlant des problèmes de TDR, mais tu oublies de dire (un peu comme eux), que ce type de problème survient sans même utiliser WebGL. L’utilisation par Microsoft de l’accélération matérielle dans le navigateur peut également provoqué ce type de problème, tout comme des programmes Flash qui permettent également d’utiliser les shaders.

Étrangement ça n’empêche pas Microsoft d’autoriser ces technologies dans leur navigateur..



Pour le flash je n’etais pas au courant qu’ils ont proposé cette fonctionnalité autant(ou au temps comme vous voulez " /> ) pour moi d’ou “mon de mémoire si je trompe pas” sur un commentaire précédent.

Ensuite je viens de le dire dans ce commentaire que ça ne concerne pas uniquement WebGL:



“Le flash ne donne pas accès aux shaders. Ce probleme existe aussi avec toute application openGL,DirectX et le dernier silverlight.”



J’ai oublié WPF d’ailleurs. La différence avec WebGL c’est que quasiment toutes ces technologies ne sont pas faites pour le web. Le danger est de proposer un accès bas niveau à des fonctionnalités systèmes dangereuses pour n’importe quelle page web. Ce n’est pas le même danger qu’une application tu conviendras.



Pour Silverlight 5 par contre oui c’est pour le web. Mais je me souviens que julien manici avait posté des liens msdn ou Microsoft évoquait ce problème aux développeurs de WPF. Ce n’est pas juste un archarnement sur WebGL comme tu sembles prétendre puisque Microsoft previent les développeurs sur ses propres technologies. Par contre je doute fort que silverlight5 soit un problème de sécurité, au vu des dernières informations sur WinRT je ne connais pas beaucoup de développeurs autour de moi qui comptent y passer.

Le 16/11/2012 à 17h 23

-Stephane- a écrit :



Comment ça ils n’ont aucun contrôle sur l’exécution des shaders ?!

Les shaders s’exécutent sur le GPU, bien sur que si qu’ils peuvent contrôler ce qui s’y passe. C’est justement ce que Microsoft leur demande explicitement (cf. ta citation)

Bref c’est bien à Nvidia et consort de mettre en place les watchdogs (ou de scheduler) en amont, avant que la couche de Microsoft ne s’en occupe.

Pour le reste tu continues à brasser du vent, moi je n’ai toujours pas vu de sample code WebGL qui plante mon système.





Tu as tord Microsoft n’aurait pas sorti le multitache GPU preemptif si c’était le cas.



Voilà ce qui mette sur une doc Microsoft







This is made worse by the fact that an increasingly larger number of applications are trying to broadly use GPUs. Windows 7 saw the introduction of the Direct Compute API targeted specifically at scenarios wanting to leverage the GPU for compute-intensive applications such as video encoding. Leveraging this API today is not without risk. It is very easy for an application to inadvertently submit a very complex and long workload to the GPU, which may take a significant amount of time to complete during which the GPU is unavailable to other applications, resulting in an unresponsive desktop.

The GPU is a shared resource that is used by many applications, including UI rendering of most applications. Today, applications have to cooperate to avoid this problem. Cooperating is accomplished by attempting to break down the work to be executed on the GPU into small batches to avoid using the GPU exclusively for extended periods of time. This task is much more difficult than it may sound as the performance characteristics of a GPU can change drastically from low end to high end and batch size is a combination of application and driver behavior. There is no strict guideline on how to achieve this either. It is essentially accomplished through trial and error one application/developer at a time.

GPU preemption offers a better solution to this problem by making it possible to preempt long-running workloads on the GPU. This should free developers from having to fine tune their application for every GPU, allowing them to fully leverage the power of the GPU while maintaining great desktop responsiveness and allowing scenarios such as touch to feel great no matter what other applications are doing.



Sur Vista et 7 le multitache GPU était coopératif. Ils tentaient de diviser les taches GPU invoqués par les applications mais c’est loin d’être parfait. Ils expliquent clairement qu’ils ne peuvent pas assurer de rendre la main dans les temps si une tache GPU est trop longue.



Je pense qu’on ne peut pas faire plus clair comme explication. Du coup j’arrête la je n’ai pas que ça a faire de tenter d’expliquer des trucs à des gens obstinés. " />

Le 16/11/2012 à 17h 13

zefling a écrit :



Et Flash ou Silverlight c’est pas le même problème ? Je demande, perso mon domaine c’est plus le CSS et le DOM HTML.





Le flash ne donne pas accès aux shaders. Ce probleme existe aussi avec toute application openGL,DirectX et le dernier silverlight.

Le 16/11/2012 à 13h 04

fitfat a écrit :



WebGL ne peux pas être sandboxé ?





Marre d’expliquer désolé j’ai d’autres problèmes à résoudre j’arrête là.

Ce n’est pas WebGL qui chie à la base. Ca se passe au niveau de la carte graphique et des drivers graphiques. WebGL expose juste des fonctionnalités dangereuses au niveau du web.

Le 16/11/2012 à 12h 46

ldesnogu a écrit :



Il ne dit rien ton message sinon que les drivers ne doivent pas bloquer des ressources trop longtemps. Je ne suis pas certain de comprendre ce que tu essaies de prouver dans le contexte d’une attaque par WebGL, puisqu’apparemment ce processus de déblocage est automatique et ne provoque pas de plantage. Ou alors j’ai rien compris " />





Reprend le premier lien que j’ai donné. ils parlent d’attaques DDOS. En clair tu balances en continue un program shader bien lourd.Le système va récupérer mais l’application(voir d’autres applications qui utilisaient aussi le GPU) vont planter.. De plus le TDR a une limite de 7 redémarrages si je me souviens bien. Au delà tu devrais te taper un BSOD.

Le 16/11/2012 à 12h 38

-Stephane- a écrit :



C’est vieux ça, Nvidia a déjà mis en place des corrections pour les problèmes de TDR dans ses pilotes… L’an dernier.

J’attends encore de voir un sample code WebGL qui produit ce genre de problème sur un système avec un navigateur récent.





NVidia ne peut pas corriger les problèmes de TDR. Ils n’ont aucun contrôle sur l’execution d’un program shader. Tu as lu le lien ou quoi? Le mec a juste créer un program shader très gourmand pour provoquer le TDR.

Il arrive régulièrement que des utilisateurs se tapent le message d’avertissement du TDR comme quoi le driver graphique ne répondait plus. Mais même avec ça ces problèmes n’existent pas d’après toi :(



Enfin bref là j’ai tout dis j’arrête là. J’ai des problèmes personnels bien plus importants à résoudre " />

Le 16/11/2012 à 11h 40

Voici un exemple précis du problème que j’évoque. Je viens de le trouver.

Regardez ce message

Le 16/11/2012 à 11h 05

Vista et 7 essayaient de découper les paquets envoyés au GPU mais ça ne marchait pas toujours.

Le 16/11/2012 à 11h 03

-Stephane- a écrit :



Le blacklistage n’est pas fait par celui qui écrit le code WebGL, mais par l’éditeur du navigateur. Ce n’est pas “je crois”, c’est déjà en place chez Mozilla et Google dans leur navigateur respectif, et ça marche trés bien.

ça veut dire quoi “envoyer un programme shader trés lent” ? Depuis tout à l’heure tu parles dans le vide, donne un exemple concret.

J’ai déjà fait des shaders qui “rament” sur un GPU faible, au pire j’arrive à faire ramer le navigateur, jamais je n’ai réussi à faire planter l’affichage du PC via WebGL.





GPU reset





To prevent timeout detection from occurring, hardware vendors should ensure that graphics operations (that is, direct memory access (DMA) buffer completion) take no more than 2 seconds in end-user scenarios such as productivity and game play.

Le 16/11/2012 à 10h 50

Crysalide a écrit :



FUD FUD FUD… La preuve, t’as aucun exemple précis.





Personne ne s’y est encore intéressé en effet mais ça viendra. Surtout si WebGL atteint une part de marché importante. On en reparlera à ce moment là.

J’ai argumenté donne des liens si tu ne veux pas me croire c’est ton problème.



PS: J’utilise Chrome depuis quasiment le début pour d’autres raisons.

Le 16/11/2012 à 10h 44

-Stephane- a écrit :



Détrompe toi.

Le GLSL que permet OpenGL ES 2.0, est beaucoup plus limité que ce qu’un langage classique comme le C permet de faire. De ce fait il est bien plus simple de détecter une anomalie dans le code.

Et je ne vois pas ce que le blacklistage a de foireux, puisqu’il ne bloque WebGL que si la version des pilotes est trop ancienne et comporte une faille. C’est une saine façon d’alerter les gens sur la nécessiter de mettre à jour leur pilote.





Si tu trouves une faille sur un pilote récent nvidia et puis Ati. Généralement les failles existent depuis longtemps. Je t’ai expliqué avant que les drivers graphiques sont de vrais passoires. Donc tu crois que WebGL va bloquer ces pilotes. Ca signifierait que quasiment plus personne puisse accéder à WebGL. Sur le coup je doute que les devs de WebGL fassent le blacklist nécessaire.



Pour le GLSL comment ils gèrent l’attaque DDOS qui consiste à envoyer un program shader très lent. Je doute fort qu’ils vont s’amuser à mesurer le temps d’éxecution du code. Ca ressemble plus à une heuristique qu’autre chose.

Le 16/11/2012 à 10h 36

earth01 a écrit :



Sans vouloir t’offenser, c’est justement ce qu’est en train de faire Microsoft depuis plusieurs années avec .NET : Même si tu codes tes programmes n’importe comment, il y a toujours une verification faite par windows qui empêche le programme de faire planter le système.



Pour Javascript (et donc WebGL) c’est pareil, puisque le langage est interprété, les concepteurs de navigateurs peuvent à loisir contrôler l’exécution du code pour empêcher de faire planter le programme voire le système.





.NET n’empêche pas un programme de planter. Il ne va pas modifier le code du programme. Si il y a un bug il restera.

Ensuite le program shader est executé sur le GPU. Je ne vois pas comment OpenGL ou DirectX pourrait modifier le code. Déjà il faudrait connaitre les failles futures et je ne vois pas comment il peut détecter le temps d’éxécution pour éviter le timeout.

Si ca avait été possible de faire cela. Ca ferait longtemps que ms l’aurait ajouté dans son architecture graphique.



Pour le driver OpenGL il s’execute aussi en mode noyau, il permet le même genre d’attaque que DirectX en exploitant les bugs dans les drivers graphiques ou la carte graphique.

Le 16/11/2012 à 10h 14

ldesnogu a écrit :



Oui tout cela, je le sais :) Mais la façon dont les programmes shader sont chargés et la manière dont OpenGL ES s’insère dans l’architecture graphique ne sont pas forcément nécessairement identiques et donc pas nécessairement soumis aux mêmes bugs/problèmes.





Le problème vient surtout du program shader lui même qui peut faire planter le GPU ou le monopoliser. Du coup le GPU ne réponds plus. le program shader s’execute sur le GPU.

Le 16/11/2012 à 09h 34

Dernière chose si il devait arriver quelque chose on reporterait la faute à Microsoft car en réalite c’est le système qui planterait . Il suffit de voir les plaintes des utilisateurs sur les BSOD liés en réalité soit aux drivers ou au matos.

Le 16/11/2012 à 09h 31

Sans compter que sur bon nombre de machines les drivers ne sont jamais mis à jour. Ce serait assez grave en terme de sécurité.

Le 16/11/2012 à 09h 29

-Stephane- a écrit :



Je suis déjà développeur 3D, donc je connais la problématique.

Si je demande un exemple concret c’est parce que la situation a pas mal évoluée depuis le début de WebGL. Contrairement à un programme natif, les applications WebGL passent par le parser du navigateur qui peut autoriser ou pas certaines choses, voir même modifier les shaders avant de les compiler. De même certains pilotes 3D peuvent être “blacklistés” s’ils possèdent un problème connu, empêchant toute application WebGL de tourner.

Bref les problèmes de sécurité ne sont pas plus élevés que ceux qui concernent les API 3D de Flash par exemple. Tant qu’il n’y a pas d’exemple récent démontrant une réelle faille de sécurité, ça relève du FUD.





Je doute fort qu’il soit possible de voir si le code d’un program shader soit mauvais ou pas. Pour donner un exemple c’est comme si tu racontais qu’on pouvait écrire un programme qui empêche de faire bugger d’autres programmes.

Pour le blacklistage donc si on trouve une faille sur un pilote qui existe depuis le début on bloque l’accès à WebGL sur toutes les machines. Ca aussi c’est très foireux.

Le 16/11/2012 à 09h 21

ldesnogu a écrit :



Tu parles de DirectX là. Es-tu certain que le comportement du driver OpenGL ES serait équivalent ?



EDIT : Je ne nie pas le danger de WebGL, hein, je pose juste la question :)





OpenGL permet aussi de charger des programmes shaders. C’est une fonctionnalité matérielle des cartes graphiques.

Ensuite le driver OpenGL s’insère dans l’architecture graphique Vista. Il communique avec le noyau graphique dont j’ai parlé plus haut et le driver graphique.

Le 16/11/2012 à 09h 04

zefling a écrit :



Ça serait bien de préciser « expérimentaux », ils sont préfixés (et en plus pas super à jour)







Par contre ça ne le dérange pas d’inclure directement Flash.



Bon Firefox va faire la même chose, mais en JS.





Sauf si je me trompe mais flash ne donne pas un accès aussi bas niveau que WebGL permettant d’écrire son propre shader program.

Le 16/11/2012 à 09h 01

-Stephane- a écrit :



Je suis curieux d’avoir un exemple concret dans ce cas… Pour le moment ce n’est que du FUD.





Demande à un programmeur de jeux vidéo. C’est arrivé plusieurs fois à des programmeurs DirectX de faire planter la pile graphique pendant le développement d’un jeu.

.

Sinon certains vieux jeux conçus sous XP font planter la couche graphique car le program shader rend pas la main assez tôt

Dans cette histoire il y a deux choses:

L’attaque DDOS c’est le plus simple à faire



*Mais tu as aussi tous les bugs dans les drivers graphiques et même les cartes graphiques. Par mon boulot je peux te dire que les drivers graphiques sont les drivers les plus buggés qu’on peut trouver. Tu devrais demander à Jean Baptiste de VLC ce qu’il en pense il a déja approuver ce post dans un de mes anciens commentaires.

Le 15/11/2012 à 18h 24

arno53 a écrit :



Il faudrait qu’ils aient 2 navigateurs l’un pour le support vis a vis des entreprises et un autre plus pour les utilisateurs non pro avec un rythme plus soutenue parce que la attendre 3 ans " />



Bon c’est vrai que leur preview s’en approche mais j’ai cru comprendre qu’il prenait la place d’IE donc " />



Sinon Charon pour ton dossier technique sur W8 j’espère que tu expliqueras ce qu’est un “ ordonnanceur GPU preemptif ” parce que la je suis largué " /> d’ailleurs c’est pas de ca qu’avait besoin midori ou helios ou un de ces projets top secret de Ms " /> ? Ou alors je confonds complètement " />





rien à voir avec Midori. C’est le morceau de code qui gère le multitache GPU entre les applications. Depuis Vista ,Windows est doté d’un noyau graphique qui gère la mémoire vidéo et les différents paquets envoyés sur le gpu. Comme pour le processeur il existe un ordonnanceur GPU. Jusqu’à maintenant il était coopératif mais plus sur Windows 8.

La différence entre coopératif et préemptif

Le 15/11/2012 à 17h 47

charon.G a écrit :



C’est faux il suffit de faire un shader programme un peu long et tu fais une DDOS sur le sous système graphique. Il n’y a aucun moyen de l’éviter. Et quand tu rends ce genre de possibilité disponible à n’importe quelle page web , ça fait peur.





Sur XP tu te tapes un BSOD. Sur Vista et 7 le sous système graphique se reinitialise à la volée.

Sur 8 vu que WDDM1.2 utilise un ordonnanceur GPU preemptif il y a des chances que ça puisse passer dans certains cas.

Le 15/11/2012 à 17h 44

-Stephane- a écrit :



L’eau a coulée sous les ponts depuis… Les failles ont été corrigées et la sécurité a été renforcée à la fois du côté des navigateurs et des pilotes 3D.

Ces craintes là n’ont plus lieu d’être, et l’excuse de Microsoft ne tient plus.





C’est faux il suffit de faire un shader programme un peu long et tu fais une DDOS sur le sous système graphique. Il n’y a aucun moyen de l’éviter. Et quand tu rends ce genre de possibilité disponible à n’importe quelle page web , ça fait peur.

Le 15/11/2012 à 17h 33

chriscombs a écrit :



Toujours pas de WebGL (à priori ?)

Concurrence avec les technos maison (directx), dommage.





Je t’invite à lire ceci

C’est la raison pour laquelle Microsoft ne gère pas WebGL ils se sont déjà exprimés la dessus.

Le 14/11/2012 à 10h 20

arno53 a écrit :



En gros ca sera un “service pack” " /> enfin une mise a jour 8,5 …





Plus un feature pack à la server 2003. ou un mango sur mobile oui

Le 14/11/2012 à 08h 09

Strimy a écrit :



Je trouve ça bien dommage. J’adore WPF et toutes les possibilités qu’il propose. Quand je compare WinRT avec WPF (au niveau graphique), j’ai l’impression d’avoir un sous ensemble extrêmement restreint. Pour pas mal de projets sur lesquels j’ai bossé (tous en WPF), je m’arrache les cheveux rien qu’en pensant à comment il faudrait s’y prendre pour faire la même chose en WinRT.

J’ai l’impression que MS n’a fait que réduire les capacités de WPF, en premier avec Silverlight (en particulier pour WP7), puis maintenant WinRT qui me parait être plus réduit que Silverlight.



Pour le coup, ce que tu me dis me fait un peu peur. Je viendrai juste d’avoir fini mes études qu’il faudra que ce dans quoi je me suis spécialisé ne me servira à rien " />





Sur le court terme WPF est toujours là et devrait même rester pour la compatibilité même si il devient obsolète.

Ensuite C’est la version 1 de WinRT. Regarde le .NET sur sa première version et maintenant. Je pense que les manques que tu cites vont être corrigés par la suite surtout que WinRT a été vraiment été conçu pour évoluer facilement. La mise à jour Blue en 2013 devrait à mon avis corriger ces manques de jeunesse.

Le 13/11/2012 à 16h 54

Nyco87 a écrit :



Qu’entends-tu par “api de type safe” ? (je n’y connais pas grand chose en Dev " />)





C’est du code managé(.NET ou java) qui est compilé en code machine. ce code est dit type safe et memory safe. Un tel code n’utilisant pas de pointeurs(adresses dans la mémoire) il est impossible d’avoir de buffer overflow. Un buffer overflow pour résumer simplement est un dépassement des données en mémoire.Sortie de tableau par exemple. Ce dépassement peut être exploité pour exécuter du code viral.

Le 13/11/2012 à 16h 14

Nyco87 a écrit :



Un WinRT plus étendu ? qui reprendrait du Win32 (ou en émulant) ?





Non pas du Win32, de nouvelles api systèmes en code géré très certainement.

WinRT est un framework natif mais toutes les api sont type safe et memory safe. Aucun pointeur n’est communiqué. Visiblement ils ont prévu de le porter pour un os en code safe.

Le 13/11/2012 à 16h 06

J’ai un ami qui est allé à la build 2012. Il y avait une conférence avec un dev Microsoft de WPF. A la fin un dev lui a demandé quel était l’avenir du bureau(dans le sens environnement Win32/WPF/silverlight). il lui a répondu qu’il le savait pas directement mais que son avis personnel il n’y avait aucun avenir. Je pense qu’en travaillant sur WPF il a du s’apercevoir que le produit n’évoluait plus. Mais ça me parait évident que ça ne va pas rester dans cet état.

Le 13/11/2012 à 16h 01

Ce que j’explique sur Windows 8 ils n’ont quasiment pas touché à l’environnement bureau car ca voudrait dire remplacer Win32(l’interface bureau est historiquement indissociable à win32)

Microsoft bosse sur un nouveau système. Je pense que ce nouveau système proposera surement de nouvelles api étendues à WinRT. Le problème actuel WinRT est trop limité et ne permet pas de créer d’applications systèmes.(mon appli c’est mort perso)



Au final on devrait voir une réelle unification entre le bureau et l’environnement actuel WinRT.

Windows 8 est actuellement une sorte d’hydre à deux têtes. Microsoft ne peux pas laisser ça comme ça, cela me parait évident.

Pour te répondre photoshop en effet ne portera jamais son application en WinRT, par contre si Microsoft propose une nouvelle plateforme système il suivra surement.

Le 13/11/2012 à 15h 44

Nerdebeu a écrit :



Je ne suis et ne serait jamais concerné " />





Pour les tablettes Windows 8 surement mais c’est fort probable que sur les windows à venir ils étendent les applications WinRT sur l’environnement bureau qui est un peu la critique numéro 1 que tout le monde fait y compris moi.

Le 13/11/2012 à 15h 38

Nerdebeu a écrit :



Je n’ai jamais mis en doute qu’il soit plus sécurisé, encore que se fier à Smart Screen est franchement risqué, car très certainement moins fiable que de vrais antivirus (son ancêtre MSE n’était pas réputé pour être d’une efficacité redoutable).



Je dis simplement que ceux qui mettent en avant un prétendu bliindage ont tort, quand bien même il serait plus sécurisé que 7 ou ses ainés.



Le Secure Boot, parlons en, tout le monde n’en “profite” pas forcément, j’ai installé 8, j’ai un BIOS UEFI et pas de secure boot.





Tout a fait mais sur les tablettes ARM(Windows RT) il est obligatoire.

Le 13/11/2012 à 15h 29

Nerdebeu a écrit :



http://www.zdnet.com/microsoft-warns-of-first-critical-windows-8-rt-security-fla…





Ce sont des failles de sécurité tant que les os ne seront pas en code safe il y en aura toujours. Au mieux on peut éviter l’exploitation des failles. La aussi ils ont amélioré les mécanismes comme l’ASLR sur Windows 8.

Windows RT est de loin la version de Windows la plus sécurisée. Tout simplement car

1)le secure boot est activé et truste jusqu’aux applications

2)Tu ne peux pas lancer d’applications bureau(win32) autres que celles de Microsoft

Le pire qui puisse arriver est d’installer une application WinRT malware. Mais la menace restera limitée à l’application elle-même à cause de la sandbox. Il suffira juste de la désinstaller. Les procédures actuelles de désinfection système n’ont rien à voir. il suffit de lire les forums d’informatique.

Le 13/11/2012 à 15h 20

Nerdebeu a écrit :



RT ne serait pas mis à mal, justement ?





C’est à dire je ne vois pas où tu veux en venir?

Le 13/11/2012 à 15h 18

Nerdebeu a écrit :



Non, modern UI en général et le Start Screen peuvent être vus comme deux choses différentes.



Ensuite sur les failles, comme dit juste au dessus, dans mon précédent post, je réagissais à l’argument de Von Block qui n’en était pas un: il mettait en avant le côté sécuritaire de l’OS, je démontre qu’il ne l’est pas plus que son prédécesseur, vala.





Ah bon secure boot et la sandbox sur les applications WinRT c’est de la merde? C’est sur ce n’est pas invulnérable mais Windows 8 est surement plus sécurisé que Windows 7

Le 13/11/2012 à 11h 47

sylware a écrit :



Il va chez nokia ou novell?





Chez Apple (commentaire 2) " />

Le 13/11/2012 à 11h 33

Tolor a écrit :



Il était très loin d’être qu’un exécutant. Il allait même jusqu’à cacher des choses à Ballmer lui même et prendre des décisions sans consulter les autres.





+1

Le 13/11/2012 à 11h 32

Nerdebeu a écrit :



Sauf que si Sinofsky n’était qu’un “exécutant” (noter les guillemets). Que fort de sa capacité à mettre un projet au point et de tenir les délais, on lui ai confié celui-ci, mais que, pour le metteur au point de 7, ce projet n’était pas spécialement à son goût, pour diverses raisons, mais “qu’il a fait le job” , comme on dit ?



En ce cas, normal que son bras droit reste, surtout si elle a été à l’origine du look Modern UI, mais que lui partent une fois le devoir accompli.





Je doute fort c’est plutôt le contraire, il a imposé sa vision dans l’équipe windows et tentait de l’imposer ailleurs. Ca m’a été confirmé plusieurs fois par des amis qui bossent chez Microsoft. L’avantage ça a permis d’unifier Windows mais l’inconvénient il a peut être trop museler les équipes.

On m’a raconté aussi que c’était une bête du travail et réagissait immédiatement (même la nuit) dès que la build Windows ne compilait plus. le développeur recevait rapidement une notification par mail.

Le 13/11/2012 à 11h 12

AlbertSY a écrit :



“ il refusait apparemment de communiquer avec les autres” LOL, c’est un doux euphémisme.

Il refusait de communiquer tout court.

Tout le monde trouvait que Metro n’est pas adapté à la souris mais plus à une surface tactile. Mais il refusait de comprendre. Certes il a pris la peine d’écrire aux beta testeurs, mais pour leur dire que Metro sera servi à tout le monde et point barre.



Ceci dit, il a fait le boulot qu’on lui a demandé (et plutôt bien d’ailleurs). Et comme il est un piètre communicant, c’est sur lui que c’est tombé (c’est celui qui gueule le plus fort qui reste). " />





Julie Larson-Green qui remplace sinofksy a travaillé sur Modern UI(metro) mais aussi les rubans d’office. Donc si métro était vraiment la raison de son départ . Microsoft n’aurait pas mis cette personne a son poste tu ne crois pas?

Le 13/11/2012 à 11h 07

Nyco87 a écrit :



Je pense que l’écosystème et surtout l’intégration de l’ensemble des services de Microsoft sont les éléments clés de ce départ.



Il a fait du bon boulot à la tête de la division Windows mais s’il n’était pas capable de s’ouvrir avec les autres divisions pour pouvoir faire quelque chose de concert alors c’est peut-être mieux ainsi.



Un truc tout con : revoir l’histoire de Skydrive face à LiveMesh. Le second mis au piloris par Steven alors qu’il a une fonction “différente” MAIS complémentaire du premier.



Pour avoir une symbiose des différents produits, il faut forcément que les divisions communiquent entre elles.



Faut rappeler aussi que Sinofsky a tué des innovations : le Courrier.



L’ouverture de la division Windows au reste du groupe est un point clé pour la suite du développement de Windows 8 : il faudrait intégrer plus les projets de recherches et surtout, avec le cash qu’ils ont, prendre des risques avec de nouvelles choses tel le Courrier.





Courier n’est pas complètement mort. Il a été repris dans le projet austin

Ca utilise C++ AMP(C++ pour GPU) et Windows Runtime pour l’interface. J’ai vu une présentation sur ce projet à la build 2012

Le 13/11/2012 à 10h 23

Tolor a écrit :



Faudra voir si ce n’est que de la comm, mais Ballmer a pas mal communiqué récemment sur sa place de CEO, et, en dehors d’une décision contraire du board, il est parti pour rester encore quelques années.



Sinon, je veux Belfiore pour futur CEO si Ballmer part " />





J’ai entendu dire qu’il risquait de partir en 2013 après à voir.

Le 13/11/2012 à 10h 17

OVB1C a écrit :



Whouais, signe que ça va mal chez Crosoft ! Déjà que le lancement de Win 8 était un peu chaotique, cette démission ne fait que souligner un peu plus le bazar ambiant dans la stratégie de MS.



Je suis pas dans la place, mais est-ce que le problème central ne serait pas Balmer lui-même ????





Enfin maintenant que sinofsky ne sera jamais le remplaçant de Ballmer, Kevin turner(un financier) a ses chances " />

Je sens que certains vont regretter Ballmer le jour ou il partira…

Le 11/11/2012 à 10h 10

megabigbug a écrit :



@charon.G

En ce qui concerne le shim bootloader, interdire le chargement d’un noyau non signé signifie interdire la possibilité de modifier soit même son système d’exploitation. C’est une limitation très forte qui a des conséquences sur l’avenir de linux et de l’informatique en général. En empechant les utilisateurs de pouvoir s’impliquer dans le développement on laisse les multinationales décider de notre avenir.

On a eu le même schémas dans l’industrie automobile avec des réglements trés fortes empechant la création de voiture par des particuliers. Cela a freiné l’arrivée des voitures électriques.

Personnellement, je pense qu’il faudrait interdire par défaut mais qu’avec une action de l’administrateur, il soit possible d’installer et d’éxécuter un kernel non signé.





Désolé pour le HS " /> De toute façon j’ai du taf en retard . je voulais juste répondre à ce commentaire. Je suis entièrement d’accord je ne sais plus si j’ai dit que ce mécanisme n’a pas été implémenté avant sur Linux à cause d’un problème de licence. Microsoft en effet n’a pas ce problème. " />

Par contre si on peut le désactiver ça perd de son intérêt

Le 10/11/2012 à 18h 52

Para-doxe a écrit :



Des messages qui contredisaient des trolld sur GNU/Linux sont swordé, mais les trolls à l’origine de ces réponses sont laissé intacte.





Tu m’as juste traité de troll car je n’ai pas mentionné hurd comme un micro noyau et tu m’as fait des procès d’intention. je ne pense pas que je suis une personne connue pour troller. Le pire je voulais le mentionner au départ mais je me suis dit que ça allait troller. Dans tous les cas tu aurais trouvé une excuse bidon car ce que je racontais aller pas dans ton sens. Ce sont les mêmes qui font des grands discours sur le libre et qui sont complètement intolérants dans la réalité des faits.



Tolor supprime mon commentaire si tu le juges nécessaire. Mais comme il sort que les posts suivants infirmaient ce que je disais. Je donne juste un lien à paradoxe pour le secure boot sur Linux

Comme indiqué seul fedora et suse bloque le chargement de drivers non signé. C’est pas le cas de ubuntu la distribution la plus utilisée. De plus même sans secure boot c’est géré depuis Windows Vista 64 bits que ca te plaise ou non.

Enfin bref la c’est HS, de toute facon je me casse, tu peux m’insulter et me cracher si ça te détend. Ca finit toujours pareil sur les news Windows " />







The Linux Foundation’s approach ultimately only verifies the mini-bootloader’s signature. In Ubuntu, on the other hand, the shim mini-bootloader will also check the full boot manager and only execute it if a valid signature is found. The same approach is planned for Fedora and SUSE. Unlike that of Ubuntu, these two distributions’ full bootloaders will only start signed kernels.

Le 10/11/2012 à 10h 33

Sebdraluorg a écrit :



" />





Je pense qu’il parle d’injecter du code dans le host d’un service ou des process genre lsass etc avec un WriteProcess suivi d’un CreateRemoteThread, faisable en admin, mais avec des droits utilisateur tu peux te lever tôt, ou downgrader jusqu’à XP… " />





+1 Il a du lire ça sur un site sans comprendre les concepts car il parle de drivers . Pour injecter du code dans un processus ,depuis Vista on ne peut pas injecter du code dans un processus admin avec des droits utilisateurs.

Le 10/11/2012 à 09h 36

J’explique juste pour canard jaune, apparemment il confond droits utilisateurs/espace utilisateur.



Tu as le noyau qui possède tous les privilèges

Ensuite les drivers kernel ont les mêmes privilèges que le noyau. seuls les micro-noyau isolent les drivers et le noyau. Windows,Linux , OSX aucun de ces os n’utilise de micro noyau. Singularity/Midori oui par contre.



Ensuite on a l’espace utilisateur où tournent toutes les applications(et certains drivers user mode). Il existe plusieurs niveaux d’intégrité:



high: c’est réservé au système, cela permet à Windows Update de mettre à jour les fichiers systèmes,



admin: j’expliquerai pas ca coule de source mais à noter qu’une application même en administrateur n’a pas accès au système. Et les programmes admins ne tournent pas dans le noyau mais en espace utilisateur " />

utilisateur: La aussi j’explique pas on comprend le truc



low: C’est le mode d’intégrite utilisé dans la sandbox de ie7 à 9. Elle bloque toutes les écritures en dehors des dossiers IE. par contre la lecture reste autorisé



AppContainer. C’est le nouveau mode d’intégrité de Windows 8 . Les applications WinRT et IE10 metro l’utilise. Il sandboxe la lecture et l’écriture vers d’autres dossiers. Il bloque aussi les mécanismes IPC standards.

Le 10/11/2012 à 09h 09

canard_jaune a écrit :



Je souligne le fait qu’un malware qui se cantonne aux droits user (un code malveillant exécuté en ring 3 si tu préfère) n’est pas dangereux. " />





Tu es un troll de compet toi " />, tu persistes en plus(je note le lien pour JC32. Pour lui des gens comme toi ça n’existe pas )

95% des virus et malwares sur Windows se contentent de droits utilisateurs et 99% de l’espace utilisateur..(visiblement tu ne fais pas la différence)



Généralement les trolls dans ton genre viennent raconter que si Windows a toujours des virus c’est parce que l’implémentation d u système de comptes sous Windows Vista/7/8 est pourri " />

Avec des droits utilisateurs tu as accès à toutes les données de l’utilisateur, c’est bien plus intéressant que le système. Tu peux très bien utiliser les sockets pour envoyer des informations sur internet et tu peux créer des taches de fonds. En fait tu as accès quasiment à tout pour créer un virus Tu demanderas au gars qui s’est fait volé le code de sa carte bancaire ou paypal si ce n’est pas grave.

Ensuite tu sembles confondre admin espace noyau espace utilisateur/ compte utilisateur.

1. Attaquer les DLL système non ASLR, il y en a.
   
   
   
   
   
   
   
   1. Se servir de l’API Windows pour changer directement l’attribut de la mémoire où ton malware est chargé (PAGE_READ_EXECUTE ou VirtualAlloc).
      
      
      
   
   
   2. Infecter les drivers pour exécuter du code au niveau ring 1 / 2.
      
      
      
   
   
   3. Injecter des DLL dans les services du noyau (WriteProcessMemory) pour exécuter du code malveillant en ring 0 : technique utilisé par les rootkits.
      
      …
      
      
      
      Le buffer overflow est juste la méthode qui nécessite le moins de connaissances techniques pour réaliser des exploits (l’équivalent du SQLi pour le web) et l’ASLR n’est au final qu’un rempart parmi d’autres.
      
      
      
      C’est bien tu reprends ce que j’ai écris sans rien comprendre " />
      
      Tout les dll systèmes ont l’ASLR activé depuis Vista. Je parlais des dll tierces dans d’autres programmes.
      
      
      
   
   
   4. C’est utilisé pour les runtimes. le même type d’attaque existe aussi sous linux
      
      
      
      3)Ca existe aussi sur les autres os sauf que depuis Windows Vista 64 bits les drivers doivent être signés numériquement,, donc à moins d’un vol de certificat Microsoft c’est chaud d’installer un rootkit. Avec Secure boot sur Win8 Microsoft vient de bloquer les seules possibilités de détournement restantes. Sur Linux à cause de la licence les modules du noyau ne sont pas obligés d’être signés.
      
   
   
   5. La on voit que tu captes rien. WriteProcessMemory ca sert à écrire dans la mémoire d”un processus Un processus est une notion utilisateur. les drivers ne sont pas des processus. Tu peux encore moins charger un dll dans un driver " />
   
   

Le 09/11/2012 à 19h 59

Sebdraluorg a écrit :



" /> Tu m’étonnes qu’ils avaient de problèmes de perfs !!

Non mais quelle idée d’aller foutre du xml à ce niveau !

Rassure-moi, Singularity ne prévoit pas de processer du Xml à chaque appel driver ?

Ce que je dis est peut-être très con, j’ai pas lu grand chose sur Singularity " />



En tout cas merci, c’est toujours un plaisir de te lire " />





C’était une erreur de mémoire regarde juste au dessus ça utilisait le langage IDL utilisé pour COM+ . Il devait surement être compilé en .TLB

Dans l’idée c’était pareil que le XML,les échanges user-kernel étaient fortement typés.

Singularity utilise du spec#. C’est compilé en natif au final.