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...
Quel est le cout d'un constructeur / destructeur pour un vecteur vide ? Si le cycle de vie de la structure est un probleme de performance, ca ne viendrait pas plutot de l'allocateur ?
Ca depend du cas comme pour tout, si par defaut ton vecteur a une taille allouee de 10 objets (parce que dans le cas usuel ou le vecteur contient quelque chose il en a 10), ton constructeur va faire une allocation a chaque fois par exemple.
Si ton vecteur est cree uniquement lorsque un objet va etre ajoute, ben tu sauves cette allocation pour tous les cas ou aucun objet n'est ajoute.
En ce qui concerne la taille de la structure et les performances d'un allocateur "standard" par bloc, cela n'est pertinent que si tu alloue tes structures unitairement avec cet allocateur (un gros tableau de structures n'est pas concerné).Si tu as vraiment des problèmes de performance liées a ton allocateur, pourquoi ne pas en prendre un autre, puisque le langage le permet facilement ?
Je vais te donner un tres bon exemple de pourquoi: L'allocateur standard dans Windows a tout un tas de features pour eviter qu'un buffer overflow dans la heap ne se transforme en vulnerabilite (c'est pas une garantie a 100% mais il rend la chose vraiment compliquee pour le hacker), je ne connais a peu pres aucun allocateur 'custom' qui a ces features.
on parle bien de "ouais mais le C/C++ c est trop complique, car t as des BOFs partout quand tu manipules des char *", et toi tu viens avec un probleme de gestion des threads, pas un probleme de gestion de char *. la source du probleme n est pas du tout la meme.
Non tu n'as visiblement pas compris le probleme. En C++ tu peux meme utiliser std::string si ca te chante est t'es dans le meme cas que Java, la seule difference c'est qu'en C++ si t'as un acces hors buffer rien ne t'arrete, tu vas aller ecrire sur les structures de la heap, sur la stack, etc... alors qu'en Java tu vas prendre une belle exception dans la tete. C/C++ te permet de faire de l'arithmetique de pointeur et aller lire/ecrire ou tu veux, et c'est ca l'enorme difference avec des langages type C# ou Java, avec eux t'as beau avoir une variable modifiee sans le savoir par un autre thread, tu n'auras jamais de BOF car la VM ne te laissera jamais lire ou ecrire hors du buffer.
Tu ne parles pas de probleme de gestion de debordement memoire comme ca a ete le cas au debut, tu parles de probleme de gestion des threads sur un acces concurrent, qui donnent une corruption de la data qu aucun langage ne va corriger pour toi.
Si c'est un probleme de gestion de debordement memoire, et justement un langage comme Java te protege de cela alors que C/C++ non.
a) J'evites le cout du constructeur / destructeur si le vecteur n'est pas utilise
b) J'economises 12 bytes sur la taille de la structure qui peuvent faire une sacree difference selon l'utilisation et qui notamment:
- peuvent faire la difference entre entrer dans une ligne de cache ou pas par exemple qui a un impact plutot gros selon les cas
- ca peut aussi te permettre d'economiser pas mal de RAM si tu passes ta structure d'une taille d'un peu plus de 64 bytes a moins de 64 bytes par exemple du fait du fonctionnement de l'allocateur standard (il prendra l'allocation sur la liste des blocs de 64 bytes plutot que 96 ou 128)
Dans les cas ou le vecteur n'est utilise que dans certains cas, ca peut avoir une valeur absolument significative
Ben tout depend des structures a gerer, quand la vitesse n'est pas l'element le plus important mais l'espace memoire l'est, faut faire des choix. Tu passes de 20 bytes a 8, t'as 60% de gain, c'est consequent. en plus ca peut permettre de faire rentrer ta structure dans une ligne de cache, etc... qui amenera des gains non negigeables en vitesse.
Maintenant est-ce que ces vecteurs seront le plus souvent utilises ou pas ? De nouveau ca depend du probleme, dans certains cas oui dans d'autres non. Evidemment que si ils sont le plus souvent plein alors c'est pas rentable.
Le test de non-nullite supplementaire c'est 1 cycle, c'est genre 0 comme cout. Quand au new+delete en plus, tu peux toujours avoir un systeme de cache de vecteurs dispo si tu veux qui t'evite ce cout la(si t'en as besoin, de nouveau c'est selon les besoins).
[^] # 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...
[^] # Re: works for me
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -1.
Quel est le cout d'un constructeur / destructeur pour un vecteur vide ? Si le cycle de vie de la structure est un probleme de performance, ca ne viendrait pas plutot de l'allocateur ?
Ca depend du cas comme pour tout, si par defaut ton vecteur a une taille allouee de 10 objets (parce que dans le cas usuel ou le vecteur contient quelque chose il en a 10), ton constructeur va faire une allocation a chaque fois par exemple.
Si ton vecteur est cree uniquement lorsque un objet va etre ajoute, ben tu sauves cette allocation pour tous les cas ou aucun objet n'est ajoute.
En ce qui concerne la taille de la structure et les performances d'un allocateur "standard" par bloc, cela n'est pertinent que si tu alloue tes structures unitairement avec cet allocateur (un gros tableau de structures n'est pas concerné).Si tu as vraiment des problèmes de performance liées a ton allocateur, pourquoi ne pas en prendre un autre, puisque le langage le permet facilement ?
Je vais te donner un tres bon exemple de pourquoi: L'allocateur standard dans Windows a tout un tas de features pour eviter qu'un buffer overflow dans la heap ne se transforme en vulnerabilite (c'est pas une garantie a 100% mais il rend la chose vraiment compliquee pour le hacker), je ne connais a peu pres aucun allocateur 'custom' qui a ces features.
[^] # Re: Dépassement de tampon
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -1.
on parle bien de "ouais mais le C/C++ c est trop complique, car t as des BOFs partout quand tu manipules des char *", et toi tu viens avec un probleme de gestion des threads, pas un probleme de gestion de char *. la source du probleme n est pas du tout la meme.
Non tu n'as visiblement pas compris le probleme. En C++ tu peux meme utiliser std::string si ca te chante est t'es dans le meme cas que Java, la seule difference c'est qu'en C++ si t'as un acces hors buffer rien ne t'arrete, tu vas aller ecrire sur les structures de la heap, sur la stack, etc... alors qu'en Java tu vas prendre une belle exception dans la tete. C/C++ te permet de faire de l'arithmetique de pointeur et aller lire/ecrire ou tu veux, et c'est ca l'enorme difference avec des langages type C# ou Java, avec eux t'as beau avoir une variable modifiee sans le savoir par un autre thread, tu n'auras jamais de BOF car la VM ne te laissera jamais lire ou ecrire hors du buffer.
Tu ne parles pas de probleme de gestion de debordement memoire comme ca a ete le cas au debut, tu parles de probleme de gestion des threads sur un acces concurrent, qui donnent une corruption de la data qu aucun langage ne va corriger pour toi.
Si c'est un probleme de gestion de debordement memoire, et justement un langage comme Java te protege de cela alors que C/C++ non.
[^] # Re: works for me
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -1.
En ayant un pointeur :
a) J'evites le cout du constructeur / destructeur si le vecteur n'est pas utilise
b) J'economises 12 bytes sur la taille de la structure qui peuvent faire une sacree difference selon l'utilisation et qui notamment:
- peuvent faire la difference entre entrer dans une ligne de cache ou pas par exemple qui a un impact plutot gros selon les cas
- ca peut aussi te permettre d'economiser pas mal de RAM si tu passes ta structure d'une taille d'un peu plus de 64 bytes a moins de 64 bytes par exemple du fait du fonctionnement de l'allocateur standard (il prendra l'allocation sur la liste des blocs de 64 bytes plutot que 96 ou 128)
Dans les cas ou le vecteur n'est utilise que dans certains cas, ca peut avoir une valeur absolument significative
[^] # Re: works for me
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -3.
Je parles d'un tableau ? Non je parles d'un vecteur qui est conceptuellement membre d'une structure largement utilisee.
public struct bob { vector<int> *MonVecteur; plein de bordel supplementaire}
[^] # Re: works for me
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 0.
Ben tout depend des structures a gerer, quand la vitesse n'est pas l'element le plus important mais l'espace memoire l'est, faut faire des choix. Tu passes de 20 bytes a 8, t'as 60% de gain, c'est consequent. en plus ca peut permettre de faire rentrer ta structure dans une ligne de cache, etc... qui amenera des gains non negigeables en vitesse.
Maintenant est-ce que ces vecteurs seront le plus souvent utilises ou pas ? De nouveau ca depend du probleme, dans certains cas oui dans d'autres non. Evidemment que si ils sont le plus souvent plein alors c'est pas rentable.
Le test de non-nullite supplementaire c'est 1 cycle, c'est genre 0 comme cout. Quand au new+delete en plus, tu peux toujours avoir un systeme de cache de vecteurs dispo si tu veux qui t'evite ce cout la(si t'en as besoin, de nouveau c'est selon les besoins).