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.
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.
Serieusement, je te suggeres de te renseigner un peu plus sur ce champs avant d'affirmer des choses comme tu le fais. La securite c'est vraiment pas le bon champs pour prendre des decisions sans comprendre de quoi il en retourne.
Gni ? L'implémentation de std::vector n'est pas obligée de faire une préallocation si on ne donne pas de capacité initiale. Si le constructeur par défaut le fait quand même, c'est un problème de qualité d'implémentation de std::vector.
Si dans ton cas particulier le vector contient généralement 10 elements, rien ne t'empeche de faire un reserve(10) avant la premiere insertion, que le vecteur soit alloué dynamiquement ou non.
Si tu dois de toute facon avoir du code avant la 1ere insertion, pourquoi alors te taper ces 12 bytes additionels tout le temps ?
Un simple pool de char[sizeof bob] obtenues via l'allocateur est suffisant.
Et il a quelle taille ton pool ? Tu alloues un gros bloc bien enorme qui mange la RAM et qui a l'effet oppose(je te rappelles que l'objectif est minimiser l'utilisation memoire hein) ou tu alloues plusieurs blocs a la demande auquel cas il te faut gerer les allocations/deallocations des blocs complets avec tracking, etc... ?
Dans son cas, il a deux threads, et deux variables, ou il pose ses mutex sur une variable apres l autre, ce qui provoque cette corruption entre le size_t et la vraie taille memoire du char *. Le soucis est de ne pas avoir ecrit ses threads correctement (deux erreurs de conception) ca n a rien a voir avec une gestion de char *.
Ben donnes moi un exemple ou l'erreur est dans le traitement du char* alors, c'est quoi l'erreur ? Il s'est trompe de variable et a passe le mauvais char* comme parametre ?
Non la plupart des cas sont dus au fait que la taille de buffer (a lire, a allouer, a ecrire, ...) est fausse pour une raison X ou Y. X ou Y peut etre une erreur de calcul, un integer overflow/underflow, une race condition, etc...
Un hacker aura bien du mal faire expres de foirer les threads comme decrit alors que tout fonctionne autrement, pour une raison tres simple : le probleme ne vient pas d une attaque!
Tu es naif mon cher, tu crois que je l'ai invente de toute piece ce scenario ? Je te rappelles que j'ai passe 6 ans a bosser sur des failles dans un OS de 30 millions de lignes hein, le hacker il va simplement constamment te lancer 2 requetes en simultane et attendre qu'une fois ca declenche la faille toute simplement...
Ce n est donc pas plus un probleme de securite lie a un BOF potentiel.
De plus, je rappelle que pour des serveurs ou il faut de la securite, y a un mec qui s appelle Spender et qui produit des patchs kernels plus qu interessants.
Moi je te suggeres de te demander si tu devrais prendre en compte l'avis de quelqu'un dont la securite a ete le boulot pendant 6 ans plutot que balancer cela par dessus l'epaule comme ca...
[^] # Re: et les implications juridique ?
Posté par pasBill pasGates . En réponse au journal Microsoft est dans le top 5 des contributeurs de linux 3.0. Évalué à -10.
Dommage qu'aucun d'eux n'arrive a la cheville de PREfast et je ne parles meme pas de PREfix
[^] # Re: et les implications juridique ?
Posté par pasBill pasGates . En réponse au journal Microsoft est dans le top 5 des contributeurs de linux 3.0. Évalué à -2.
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.
[^] # Re: et les implications juridique ?
Posté par pasBill pasGates . En réponse au journal Microsoft est dans le top 5 des contributeurs de linux 3.0. Évalué à 2.
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.
[^] # Re: et les implications juridique ?
Posté par pasBill pasGates . En réponse au journal Microsoft est dans le top 5 des contributeurs de linux 3.0. Évalué à 2.
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.
[^] # Re: et les implications juridique ?
Posté par pasBill pasGates . En réponse au journal Microsoft est dans le top 5 des contributeurs de linux 3.0. Évalué à 3.
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.
[^] # Re: Chacun son style
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -1.
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.
[^] # Re: Dépassement de tampon
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -4.
•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
[^] # Re: Dépassement de tampon
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -4.
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.
[^] # Re: Dépassement de tampon
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -2.
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.
[^] # Re: Chacun son style
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -4.
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.
[^] # Re: pb vie privé facebook google+
Posté par pasBill pasGates . En réponse au journal Réflexions après quelques jours de test de Google+. Évalué à -3.
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)
[^] # Re: Dépassement de tampon
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -3.
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.
[^] # Re:Dépassementde tampon
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -9.
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.
[^] # Re: Chacun son style
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -1.
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.
[^] # Re: support d'Amiga envers Aros
Posté par pasBill pasGates . En réponse au journal Nouvelles d'AROS - Amiga Research Operating System. Évalué à 2.
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.
[^] # Re: Dépassement de tampon
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -2.
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.
[^] # Re: works for me
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -4.
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...
[^] # Re: works for me
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -2.
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
[^] # Re: works for me
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -4.
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.
[^] # Re: Dépassement de tampon
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -1.
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.
[^] # Re: Dépassement de tampon
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -2.
Dis-moi, c'est quelle partie de la phrase
Attackers can exploit this issue to execute arbitrary code with superuser privileges, facilitating the complete compromise of affected computers
que tu as rate ?
a) GRSEC n'est de loin pas present sur tous les kernels, de tres loin meme
b) C'est pas une protection a 100%, il y a des manieres de passer outre (cf. http://jon.oberheide.org/blog/2011/04/20/stackjacking-your-way-to-grsec-pax-bypass/ )
Serieusement, je te suggeres de te renseigner un peu plus sur ce champs avant d'affirmer des choses comme tu le fais. La securite c'est vraiment pas le bon champs pour prendre des decisions sans comprendre de quoi il en retourne.
[^] # Re: works for me
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -3.
Gni ? L'implémentation de std::vector n'est pas obligée de faire une préallocation si on ne donne pas de capacité initiale. Si le constructeur par défaut le fait quand même, c'est un problème de qualité d'implémentation de std::vector.
Si dans ton cas particulier le vector contient généralement 10 elements, rien ne t'empeche de faire un reserve(10) avant la premiere insertion, que le vecteur soit alloué dynamiquement ou non.
Si tu dois de toute facon avoir du code avant la 1ere insertion, pourquoi alors te taper ces 12 bytes additionels tout le temps ?
Un simple pool de char[sizeof bob] obtenues via l'allocateur est suffisant.
Et il a quelle taille ton pool ? Tu alloues un gros bloc bien enorme qui mange la RAM et qui a l'effet oppose(je te rappelles que l'objectif est minimiser l'utilisation memoire hein) ou tu alloues plusieurs blocs a la demande auquel cas il te faut gerer les allocations/deallocations des blocs complets avec tracking, etc... ?
[^] # Re: Dépassement de tampon
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -1.
Cadeau : http://www.securityfocus.com/bid/48538/discuss
Serieusement, tu n'as absolument aucune idee des risques et consequences de diverses erreurs de programmation en matiere de securite visiblement.
[^] # Re: Dépassement de tampon
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 1.
Vaut mieux ca que coder en C en croyant qu'eviter les BOF est simple. Au moins ca evitera que le systeme se mette a executer du code externe.
[^] # Re: Dépassement de tampon
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -2.
Dans son cas, il a deux threads, et deux variables, ou il pose ses mutex sur une variable apres l autre, ce qui provoque cette corruption entre le size_t et la vraie taille memoire du char *. Le soucis est de ne pas avoir ecrit ses threads correctement (deux erreurs de conception) ca n a rien a voir avec une gestion de char *.
Ben donnes moi un exemple ou l'erreur est dans le traitement du char* alors, c'est quoi l'erreur ? Il s'est trompe de variable et a passe le mauvais char* comme parametre ?
Non la plupart des cas sont dus au fait que la taille de buffer (a lire, a allouer, a ecrire, ...) est fausse pour une raison X ou Y. X ou Y peut etre une erreur de calcul, un integer overflow/underflow, une race condition, etc...
Un hacker aura bien du mal faire expres de foirer les threads comme decrit alors que tout fonctionne autrement, pour une raison tres simple : le probleme ne vient pas d une attaque!
Tu es naif mon cher, tu crois que je l'ai invente de toute piece ce scenario ? Je te rappelles que j'ai passe 6 ans a bosser sur des failles dans un OS de 30 millions de lignes hein, le hacker il va simplement constamment te lancer 2 requetes en simultane et attendre qu'une fois ca declenche la faille toute simplement...
Ce n est donc pas plus un probleme de securite lie a un BOF potentiel.
De plus, je rappelle que pour des serveurs ou il faut de la securite, y a un mec qui s appelle Spender et qui produit des patchs kernels plus qu interessants.
Moi je te suggeres de te demander si tu devrais prendre en compte l'avis de quelqu'un dont la securite a ete le boulot pendant 6 ans plutot que balancer cela par dessus l'epaule comme ca...