pasBill pasGates a écrit 16204 commentaires

Profite parce que le robinet va bientot se fermer

Simplement parce qu'il y a des annotations ne signifie pas que c'est pas "a vue d'oeil"

Jettes un oeil au kernel, combien de fonctions sont annotees ? --> Impossible d'analyser correctement, meme si t'as un bon outil
Regarde Sparse (http://linux.die.net/man/1/sparse), ou est le solveur de contraintes ? Il n'y en a pas, il est incapable de te dire par exemple qu'une boucle int b=4; while(b<5) ne s'arretera jamais car il ne peut pas comprendre l'execution du code et voir qu'aucun chemin ne permet de sortir.

Tu peux en decouvrire plus sur Coccinelle ici : http://coccinelle.lip6.fr/papers/fosdem10.pdf et tu decouvriras que c'est idem, c'est des patterns et autres, il n'y a aucune comprehension reelle du code, des appels de fonction, etc... et le nombre de faux-positifs peut etre sacrement eleve a cause de cela.

"Lorsqu'un cheval boit il n'a plus soif". Loi de PbPg

Aucun de ces softs n'est capable de vraiment savoir ce qui est attendu du code, parce que le code du kernel (et de tous les autres projets des distribs quasiment) n'est pas annote.

Rien ne permet de dire que le parametre length de blob(void* buffer, int length) est sense etre la longueur du buffer par exemple, ce qui empeche l'analyse statique d'etre efficace. Tu regardes le code de Windows par contre, il est quasi-entierement (voire entierement maintenant) annote du kernel jusqu'au demineur, ce qui permet aux softs genre PREfix et PREfast de verifier que le buffer qui a ete passe a la fonction dans la plupart des 32 chemins de code possible (il peut evidemment pas verifier tous les cas possibles et imaginables) a une taille au moins aussi grande que la valeur de la variable length, et que la fonction elle meme ne s'amuse pas a acceder au buffer plus loin que la valeur de la variable length.

La plupart de ces softs pour le kernel se contentent de faire de l'analyse "a vue d'oeil", il ne s'agit pas de vrais processeurs et analyseurs C avec un solveur derriere pour trouver les contraintes sur les variables, ils se contentent de voir que le code repond a certaines criteres basiques genre ne pas avoir un "if (a=x)" qui sont facilement detectables.

Bref, deux mondes totalement differents, un monde largement plus avance que l'autre.

C'est peut-etre bon pour la securite, mais c'est pas bon pour la retention d'eau tout ce sel quand meme

Dommage qu'aucun d'eux n'arrive a la cheville de PREfast et je ne parles meme pas de PREfix

Faut les comprendre, sous Linux c'est prehistorique et ils n'ont rien du genre de http://msdn.microsoft.com/en-us/windows/hardware/gg487345 pour eviter ces erreurs betes, alors que sous Windows tout le code est verifie avec ce genre d'outils constamment ce qui evite ces problemes.

Le code d'une partie de Windows 2000 dispo sur les torrents est la pour prouver de maniere irrefutable que c'est faux, il y a des conventions de codage.

Tu me fais rire, ils paient justement des gens pour faire ce boulot, tu voudrais qu'ils fassent quoi d'autre ?

Ils auraient attendu de nettoyer le code avant de l'ouvrir, vous vous seriez plaint qu'ils trainent des pieds pour ouvrir le code, etc...

Quand a la qualite des logiciels, le fait que l'enorme majorite des correctifs aient ete un changement entre le style interne a MS et celui de Linux montre plutot que la qualite est bonne, il y a eu au final peu de vrai bugs.

Si tu suivais le lien qu'il donne dans son article tu verrais que la majorite des trucs sont dus au style : ils codaient avec le style Windows (nommage des typdefs, etc...) et ont des lors du passer gentiment au style Linux, rien a voir avec une qualite de code mauvaise.

Ensuite il y avait des bugs dans leur code et des check-ins supplementaires pour les resoudre ? Grande nouvelle, c'est la meme chose dans le code du kernel qui voit des bugs corriges tout le temps.

Il y a plein de choses sur ce DVD: des symboles de debuggage par exemple, de la doc dans plusieurs langues, du code source, le platform SDK qui comprends les headers et les .lib pour l'OS, etc... l'IDE et le compilo ne sont qu'une petite partie du DVD.

•tu n a pas relu ce qui etait dit, l exemple etait un strncpy et prendre en compte le '\0' dans le calcul. Rien a voir avec deux threads qui vont corrompre un size_t qui va ensuite partir sur une mauvaise utilisation du char *.

Et la taille de buffer pour strncpy tu l'oublies ? C'est un entier, comment tu le calcules sans te prendre les pieds dans le tapis ? Tu crois que ca sera toujours une valeur statique toute simple ?

On parlai de savoir utiliser strncpy sans faire de gaffe, tu es tout de suite parti totalement autre chose, qui sont des problemes en AMONT. Ne pas savoir coder un thread (ou une faute d etourderie, fatigue) et donc provoquer une corrumption memoire, ca n a rien a voir avec le fait de savoir dimensionner un char * et savoir passer les bons params a strncpy ou controler si une chaine passee a snprintf ne contiendrai pas des caracteres qui vont provoquer un seg.

Vraiment ? L'exemple que je t'ai donne est exactement la meme chose : se louper dans le calcul d'un des parametres, exactement comme dans ta phrase savoir passer les bons params a strncpy

une appli qui lit un buffer sur plusieurs sockets a la fois" Le probleme est la. tu as plusieurs sockets, mais un seul buffer pour stocker tout le monde a la fois ? on peux partir loin dans les implementations. On peux meme parler des forks et leurs limites.

Il y a plein d'implementations differentes oui tout a fait, c'est une des nombreuses raisons qui font que tu ne comprends toujours pas qu'eviter des BOFs est complique, parce qu'il y a 10'000 cas differents a gerer.
Si ton propos est de dire "appeler strcpy est simple dans 3 cas" super, mais ca on s'en fout pas mal, il reste 9997 cas a gerer.

•La stack non executable c est l un des mecanismes a mettre en oeuvre. Les ret2libc je connais bien ca aussi, c est la parade bien connue, mais plus difficile a maitriser car ils faut savoir pointer sur system(). On peux aussi complexifier le ret2libc via l ASLR, et surtout l ASLR sur un systeme 64bits, ou via noexec. On peux aussi utiliser certaines options de gcc comme -fstack-protection, le RELRO, et toutes ces joyeusetees. Il existe plusieurs projets tres sympa comme hardened gentoo/debian. Mais si on ne donne plus de contextes aux dialogues, on est pas pres de s arreter.

Moi je regarde les distribs dispo au grand public, et force est de constater qu'en tant que developpeur, tu n'as qu'un choix: eviter les BOFs dans ton code parce que les protections du systeme et du compilateur ne sont pas suffisantes pour te proteger.

Tu m'as vu ou parler de taille d'entreprise ?

Je regarde le type de projet :
- Base de donnees haute performance & disponibilite (Oracle)
- OS grand public stable et performant (Mac OS X, Windows, ...)
- Soft serveur performant & stable (Oracle encore, SQL Server, platformes Google, etc...)

Tout ca c'est des projets gros et extremement complexes, sans rapport avec l'enorme majorite des projets software. Evidemment tu vas avoir des petites boites specialisees dans les softs pour Airbus avec des requirements de qualite incroyables, mais compare a l'enorme majorite des boites de soft c'est clair et net. C'est d'ailleurs flagrant lors de nos rachats de societes, le code qu'on trouve est souvent de sacrement pietre qualite.

Meme pas malheureusement, a moins d'etre chef de projet ou bosser dans une banques les salaires de dev en Suisse volent pas super haut. C'est pas la pauvrete non plus, mais c'est sans rapport avec les USA.

Je doute tres tres fort que FB ait fait cela, ils se mettraient sour le risque d'un sacres proces aux USA vu que c'est la ou se trouvent les donnees et qu'il n'y avait aucun risque securitaire vis-a-vis des USA (ou meme d'Israel)

La question etait : "c est trop dur en C/C++ de borner un char *"
Pour prouver que c est vrai, tu as derive sur "j ecrit mal mes threads en posant mal des mutex, pour corrompre mes variables" ce qui est un probleme d ecriture de threads.

Je me suis contente de te parler de la realite, dans le monde reel, ou les BOFs sont legion, et qui prouve que non c'est pas simple.

Maintenant, tu en es a venir au sein meme du kernel pour prouver le contraire. En quoi l ecriture d une application JAVA va changer le fonctionnement du KERNEL ?

J'en viens au kernel ? Quel rapport ? Le kernel est un bout de code en C/C++ comme un autre, si tu veux je te sors un BOF trouve la semaine passee dans un soft user-mode, il y en a a la pelle.

Moi je repondai aux BOFs quand il s agit de lire via son appli ce qui vient d une source externe, tu me parle de race condition au en interne d une appli, puis du kernel.

Et moi je te parles exactement de la meme chose mais tu ne le comprends pas, une appli qui lit un buffer sur plusieurs sockets a la fois car plusieurs connections en meme temps et qui a une race condition causant un BOF c'est quoi d'apres toi ?

Le bypass de grsec est tres sympa, je ne me rappelle pas l avoir vu, il faudrait que je check mes activitees pour cela. Mais je le repete, on est encore sorti du cas qui etait discute au debut, on est pas en train de faire un BOF sur un demon qui ecoute sur la socket, on a un programme qui s execute deja sur le systeme, donc on a deja bypass la stack qui n est pas executable, ce qui est bloque par GRSEC.

La stack non-executable c'est un gag a passer, je t'invites a aller chercher ce qu'est le return-oriented programming par exemple.

Le jour ou Linux arrivera a notre cheville a se sujet on en reparlera, d'ici la je me contenterai de rire de ton post qui prouve que tu ne connais absolument rien au sujet.

Si tu installes absolument tout ca va certainement prendre bcp de place mais je connais peu de gens qui ont besoin des outils de dev pour embedded, pour VB, pour C#, pour C++, pour Office, pour SQL, etc... avec toutes les sous-options.

Surtout pas, les gens qui ont rachete Commodore USA sont des cons qui n'ont qu'un but : faire de l'argent en vendant des PCs sous un nom connu.

Leurs machines n'ont techniquement absolument aucun rapport avec le C64 ou l'Amiga, ils utilisent la forme et le nom purement comme outils mercantiles.

Pour retrouver un vrai Amiga il faut regarder du cote d'Hyperion (http://www.hyperion-entertainment.biz/ ) qui a les droits sur le developpement d'AmigaOS et sur le nom, qui a developpe AmigaOS4 et qui bosse sur la prochaine version.

Bien c'est cool, comment tu fais pour juger de la compétence de quelqu'un ?

Je lis ce qu'il ecrit et tant que ca a un minimum de sens c'est qu'il a un minimum de competence.

Enfin tout ça pour dire que jouer à celui qui a le plus gros et le plus beau CV qui travaille dans l'entreprise la plus grosse et ayant les meilleurs développeurs du monde (et qu'en plus tu es capable de corriger !), tu peut le garder pour draguer à la plage (par exemple).

Le but est pas de dire que j'ai la plus grosse, je pense pas forcement que les dev/testeurs ici sont plus forts que chez Google, Oracle ou autres entreprises de ce style, mais force est de constater que ces gens ont une experience de developpement de gros softs largement utilises qui doivent tenir la route. Quand a trouver des bugs dedans, le point est justement de dire que meme si t'es bon, il y a toujours des bugs dedans, j'ai jamais dit qu'ils etaient super dur a trouver et que j'etais un genie pour ca.

Je rajoutes des contraintes quand ca m'arrange ? Je t'ai donne un exemple typique plus haut : gestion du protocole TCP

Explique moi quel OS a une stack TCP mono-thread, ou quel soft serveur est mono-thread et lequel de ces softs peut se permettre un pool non-performant...

Si tu te contentes de faire un push_back, alors tu auras des reallocations frequentes plutot qu'une allocation, sachant que la taille moyenne est de 10, le moyen pour regler ca est de faire un reserve(10) a la 1ere insertion, mais dans ce cas, autant creer le vecteur a la 1ere insertion aussi.

Tu crois qu'un vecteur vide est forcement rare, c'est pas forcement le cas, ca depend du scenario, il y a plein de cas ou t'as besoin d'une structure pour gerer un tableau a taille dynamique mais qu'il se peut que tu n'aies jamais d'elements.

Prend un protocole avec une liste d'options par exemple (TCP par exemple), a chaque connection tu veux garder la liste des options et leur parametres. Il y a de fortes chances que tu n'aies aucune option, mais il se peut tout a fait que tu aies plusieurs options aussi

Un pool à multiples blocs, typé et réutilisable, c'est grosso-modo 20 lignes de code, sans aucun impact sur le reste si on surcharge new/delete dans la structure bob. Ou est le problème ?

20 lignes ? J'aimerais bcp voir un pool en 20 lignes qui marche et qui est efficace (temps d'allocation, support multithread,...)

J'ai un peu de mal à cerner le genre de programme auquel tu fais référence : on a besoin d'un maximum de performances (on descend jusqu'au lignes de cache), mais d'un autre coté on alloue de nombreux objets de petite taille, avec cycle de vie court (la performance des ctor/dtor a été évoquée), et on ne peut pas faire de pré-allocation massive parce qu'il faut aussi réduire l'empreinte mémoire globale...

Un OS ou soft serveur, ces jouets la typiquement on besoin de controle sur leur empreinte memoire et doivent etre rapide.

Non c'est pas moi, tu m'as vu faire ca ou ?

Perso je consideres que l'experience d'une personne a de la valeur tant qu'il n'est pas incompetent.