Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
« Developpez.com est un groupe international de bénévoles dont la motivation est l'entraide au sens large » (incl. forums developpez.net)
Club des professionnels en informatique
Qu'appelle tu pile systeme ?Envoyé par commandantFred
Celle de l'OS ?
Parce que la pile de ton exécutable et celle de l'OS (et des autres applications) , sont pas dans les mêmes adresses mémoires.
Sinon non en C la taille de la pile est "infini", c'est juste l'OS qui le limite, en embarqué la pile c'est la taille de la RAM - (text/bss/data/heap).
Mais le C ne définis pas une taille précise de la pile, elle peut faire quelque Ko comme plusieurs Mo ,techniquement rien n’empêcherai d'avoir une pile de 1Go (mais l'interet serait bien limité).
Damn, trois trucs faux ou à côté en trois phrases. Je pensais que vous étiez en vacances. Vous êtes sûr de vouloir à tout prix intervenir sur ce topic ?
Le sujet de mon post n'est pas la pile ni les segments mémoire un exécutable C. Le sujet ici, c'est les vulnérabilités logicielles. Ca peut être un peu pointu et la plupart du temps, c'est non-documenté. Merci de trouver un topic approprié pour les autres sujets.
Ouaw cela veut dire que pendant mes 15 ans de pratique bas niveau, j'ai rien compris !
Si c'est le cas n'hésitez pas à me rectifier, mais pour le moment je constate que vous dites des choses souvent fausse
Ou alors vos phrases ne sont pas clair et vous devriez plus les expliquer.
Je trouve exagéré de déplacer des problèmes liés aux réseaux et à internet sur le langage C et C++. La NSA s'imagine qu'en changeant pour du Rust tout s'améliore. En fait ces problèmes de mémoire dépendent des développeurs. Et ensuite ce qui est amusant c'est que les défauts sont ciblés sur le C et le C++ mais pas les autres langages. Le C++ offre un code sur pour qui dispose d'une acuité normale. Le C est plus difficile à maîtriser mais on y arrive cela prend plus de temps . J'ai écrit entre autres en C et C++ une application qui sert des services statistiques dans un tableur. Tout le code correspondant aux traitements et aux calculs comporte une multitude d'allocations mémoire et une fois mis au point et testé avec Linux ne présente aucune anomalie. Les zones allouées sont correctement initialisées, il n'y a aucune erreur d'écriture dans des zones tampons, il n'y aucune erreur de fuite mémoire. C'est évident que c'est plus lent à mettre en oeuvre en C qu'en C++. Bref ce code volumineux testé sans erreur de manière autonome a été injecté dans une application graphique de type Qt et GTK et wxWidgets et là lors du test de l'application c'est la cata , des erreurs qui fusent de partout MAIS qui ne viennent pas du module injecté MAIS de ces environnements graphiques . Alors j'image qu'une fois en réseau sur internet les risques sont décuplées mais ne viennent pas du langage mais du contexte dans lequel on manipule le langage. Rust ne fait qu'avancer une rustine sur un problème qui est plus vaste lié la sécurité des réseaux et le développement Web.
Rien qui va dans ton message. C'est pas que des problèmes de réseaux et d'internet. C'est pas la NSA. Il y a des milliers (littéralement) de vulnérabilités reportées chaque année (dont une grosse partie liées à la mémoire). Le problème n'est pas juste lié à un manque "d'acuité" des devs.
Tu ne serais pas le premier qui n'a aucun problème lorsqu'il travaille sur du code non critique, et qui se prend un grosse claque lorsque son code essaie de passer une validation un peu sérieuse.
A part peut être dans les domaines critiques, n'importe qui qui me dit qu'une app un peu sérieuse (pas les petits outils internes de quelques milliers de LOC) à 0 bugs, je lui dis que c'est parce que son app n'est pas assez testée.
On va citer un grand de ce monde:
Qu'est ce qui vous garantit que vos affirmations sont vraies ?Program testing can be used to show the presence of bugs, but never to show their absence!
Edsger W. Dijkstra
Dijkstra est effectivement un algorithme très puissant et astucieux qui s'adapte à la topologie de la data qu'il traite.
Néanmoins, je n'en dirais pas autant de sa citation.
Evidemment qu'on teste l'absence de bug !
Les simulations sont parfois aussi coûteuses que le développement en lui-même. Tout dépend du budget bien sûr mais j'ai souvent exploité mes périodes improductives pour essayer de planter mon programme. Plutôt que de rester devant son écran à ne rien faire, quand le cerveau est fatigué, c'est le moment de lancer un gros crash test. Egalement pendant les pauses et pendant la nuit.
Chercher les régressions est toujours plus long que de faire des tests unitaires mais quelle fiabilité peut-on espérer si on ne le fait pas ? Donc, la phrase est jolie, son auteur est prestigieux mais ... comment dire... elle est complètement fausse dans mon cas. Je ne saurais trop suggérer de ne pas économiser le testing, changer souvent de jeu de tests et même de testeurs(euses).
J'ai discuté avec un développeur Rust hier soir. Il y a un runtime, comme en C++. Donc, Rust est surtout pressenti pour remplacer C++. Pour le C, c'est une autre histoire. Dans l'embarqué. Il n'est pas d'usage d'utiliser des runtime. Ca pourrait changer à l'avenir. Mais C reste unique sur ce point.
Pour les allocations mémoire, j'ai du mal à appréhender la "Big Picture" de Rust. Clairement, le runtime fait beaucoup de choses mais sans aller jusqu'à la GC.
Bon, dans la réalité, les capacités mémoire d'aujourd'hui permettent d'allouer de gros buffers avec des marges confortables en usage courant (strings affichables notamment)
D'autre part, pour les variables locales, les arguments de fonctions etc... Après vérification sur Gemini, Rust alloue un nouveau buffer de pile à chaque appel de fonction !! Grosse différence avec le C qui n'utilise que la pile allouée au démarrage du programme.
En cas de dépassement de buffer de string, le runtime génère une erreur.
Par contre, pour les arrays je copi colle la réponse de Gemini :
En résumé:
Les dépassements d'arrays ne sont pas testés par défaut en Rust, ce qui peut entraîner des problèmes de sécurité et de fiabilité.
Il est important de prendre des mesures pour prévenir les dépassements d'arrays et de gérer les cas d'erreur potentiels.
Des alternatives existent pour garantir un accès sécurisé aux arrays en Rust.
Comportement identique au C donc mais j'ignore à quoi ressemblent les arrays Rust. Noter que C# teste systématiquement les indices et lève une exception en cas de dépassement.
Tester c'est pour les faibles, il faut prouver son code...
Si vous ne trouvez plus rien, cherchez autre chose...
Vous trouverez ici des tutoriels OpenGL moderne.
Mon moteur 3D: Castor 3D, presque utilisable (venez participer, il y a de la place)!
Un projet qui ne sert à rien, mais qu'il est joli (des fois) : ProceduralGenerator (Génération procédurale d'images, et post-processing).
Ben non, pas "évidemment" du tout. Parce que le test exhaustif ça n'existe pas. Tout ce qu'un test garantit c'est qu'il n'y a pas de bug pour la trace d'exécution exécutée. Des traces d'exécutions il y en a un nombre pas du tout raisonnable dans un programme réaliste.
Ça tombe bien, la citation ne dit pas du tout qu'il ne faut pas tester. Elle dit juste que tester est insuffisant pour garantir l'absence de bugs. C'est même précisément pour ça qu'il a inventé une technique qui s'appelle le weakest precondition calculus (et que d'autres ont inventé pleins d'autres méthodes pour garantir l'absence de certains bugs, comme les procédures de typage par exemple).
Sécuriser par la conception : Le point de vue de Google sur la sécurité de la mémoire
Existe-t-il un consensus au sein de l'industrie sur l'abandon de C/C++ ? Sécuriser par la conception : Le point de vue de Google sur la sécurité de la mémoire
Dans un livre blanc, Google partage son point de vue sur la sécurité de la mémoire. Voici les raisons pour lesquelles Google publie ce livre blanc.
Le projet zéro de Google indique que les vulnérabilités liées à la sécurité de la mémoire - défauts de sécurité causés par de subtiles erreurs de codage liées à la manière dont un programme accède à la mémoire - ont été "la norme pour attaquer les logiciels au cours des dernières décennies et c'est toujours la manière dont les attaquants réussissent". Leur analyse montre que deux tiers des exploits "0-day" détectés dans la nature utilisent des vulnérabilités liées à la corruption de la mémoire. Malgré des investissements substantiels pour améliorer les langages peu sûrs pour la mémoire, ces vulnérabilités continuent de figurer en tête des classes de vulnérabilités les plus couramment exploitées.
Dans ce document, Google examine les données, les défis liés à la sécurité de la mémoire, et discute des approches possibles pour atteindre la sécurité de la mémoire et leurs compromis. Elle y souligne également son engagement à mettre en œuvre plusieurs des solutions décrites dans le livre blanc, tout récemment avec une subvention de 1 000 000 dollars à la Rust Foundation, faisant ainsi progresser le développement d'un écosystème robuste de sécurité de la mémoire.
Pourquoi Google publie ce livre blanc maintenant ?
L'année 2022 a marqué le 50e anniversaire des vulnérabilités en matière de sécurité de la mémoire. Depuis lors, les risques liés à la sécurité de la mémoire sont devenus plus évidents. Comme d'autres, les données et recherches internes de Google sur les vulnérabilités montrent que les bogues liés à la sécurité de la mémoire sont très répandus et constituent l'une des principales causes de vulnérabilités dans les bases de code non sécurisées en termes de mémoire. Ces vulnérabilités mettent en danger les utilisateurs finaux, l'industrie et la société dans son ensemble. Google est encouragé par le fait que les gouvernements prennent également ce problème au sérieux, comme l'a montré la publication d'un document sur le sujet la semaine dernière par l'Office of the National Cyber Director (bureau du directeur national du cyberespace) des États-Unis.
Google :
En partageant nos idées et nos expériences, nous espérons inciter l'ensemble de la communauté et de l'industrie à adopter des pratiques et des technologies sans danger pour la mémoire, ce qui, en fin de compte, rendra la technologie plus sûre.
Le point de vue de Google
Chez Google, ils ont des dizaines d'années d'expérience dans la résolution, à grande échelle, de grandes catégories de vulnérabilités qui étaient autrefois aussi répandues que les problèmes de sécurité de la mémoire. Leur approche, qu'ils appellent "Safe Coding", traite les constructions de codage sujettes à la vulnérabilité comme des dangers (c'est-à-dire indépendamment et en plus de la vulnérabilité qu'elles peuvent causer), et est centrée sur l'assurance que les développeurs ne rencontrent pas de tels dangers lors de leurs pratiques de codage régulières.
Sur la base de cette expérience, ils pensent qu'une sécurité élevée de la mémoire ne peut être obtenue que par une approche de conception sécurisée centrée sur l'adoption complète de langages offrant des garanties rigoureuses en matière de sécurité de la mémoire. Par conséquent, ils envisagent une transition progressive vers des langages à sécurité mémoire tels que Java, Go et Rust.
Au cours des dernières décennies, outre les vastes bases de code à mémoire sécurisée de Java et Go, Google a développé et accumulé des centaines de millions de lignes de code C++ qui sont utilisées activement et font l'objet d'un développement actif et continu. Cette très grande base de code existante pose des problèmes importants pour la transition vers la sécurité de la mémoire.
Mais Google considère qu'il est important de compléter la transition vers des langages à mémoire sûre pour le nouveau code et les composants particulièrement à risque par des améliorations de la sécurité du code C++ existant, dans la mesure du possible. Ils pensent également que des améliorations substantielles peuvent être obtenues par une transition progressive vers un sous-ensemble de langage C++ partiellement sûr en mémoire, complété par des fonctions de sécurité matérielle lorsqu'elles sont disponibles.Google :
Nous ne voyons pas de voie réaliste pour une évolution du C++ vers un langage offrant des garanties rigoureuses de sécurité de la mémoire, y compris la sécurité temporelle. Une réécriture à grande échelle de tout le code C++ existant dans un langage différent, sûr pour la mémoire, semble très difficile et restera probablement impraticable.
Les investissements de Google dans les langages à mémoire sécurisée
Google reconnait que les langages à mémoire sécurisée ne résoudront pas tous les bogues de sécurité, mais tout comme ses efforts pour éliminer les attaques XSS par le biais d'outils l'ont montré, l'élimination de grandes catégories d'exploits profite directement aux consommateurs de logiciels et leur permet de se concentrer sur la résolution d'autres catégories de vulnérabilités de sécurité.Google :
Nous investissons activement dans de nombreuses solutions décrites dans notre livre blanc et dans notre réponse à la demande de renseignements du gouvernement fédéral américain sur la sécurité des logiciels open source.
- Android a écrit plusieurs composants en Rust au cours des dernières années, ce qui a permis d'améliorer considérablement la sécurité. Dans le module UWB (Ultra-wideband) d'Android, cela a permis d'améliorer la sécurité du module tout en réduisant l'utilisation de la mémoire et les appels interprocéduraux.
- Chrome a commencé à livrer certaines fonctionnalités en Rust ; dans un cas, Chrome a pu sortir son générateur de code QR d'une sandbox en adoptant une nouvelle bibliothèque à mémoire sécurisée écrite en Rust, ce qui a permis d'améliorer à la fois la sécurité et les performances.
- Google a récemment annoncé l'octroi d'une subvention d'un million de dollars à la fondation Rust afin d'améliorer l'interopérabilité avec le code C++. Cela facilitera l'adoption progressive de Rust dans les bases de code existantes où la mémoire n'est pas sûre, ce qui sera essentiel pour permettre à un plus grand nombre de nouveaux développements de se produire dans un langage à mémoire sûre. Dans le même ordre d'idées, nous nous efforçons également de résoudre les attaques inter-langues qui peuvent se produire lorsque l'on mélange Rust et C++ dans le même binaire.
- Google investit dans la construction d'un écosystème open-source à mémoire sécurisée par l'intermédiaire du GISR Prossimo et du projet Alpha-Omega de l'OpenSSF. En 2021, nous avons financé les efforts visant à intégrer Rust au noyau Linux, ce qui nous permet désormais d'écrire des pilotes à mémoire sécurisée. Ce financement est également destiné à fournir des alternatives ou des mises à jour de bibliothèques open-source clés dans un langage à mémoire sécurisée, comme la fourniture d'une implémentation TLS à mémoire sécurisée.
Source : Sécuriser par la conception : compléter la transition vers des langages à mémoire sûre par des améliorations de la sécurité du code C++ existant, selon Google
Et vous ?
Pensez-vous que cet avis de Google est crédible ou pertinent ?
Voir aussi :
Publication de communiqués de presse en informatique. Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités
C'est bizarre cette crainte d'être déshonoré qu'on voit sur ce site. Je me fiche pas mal que vous ayez raison ou tort.
Allez je vous offre un intermède
A la une du NYT demain :
La Maison Blanche se rétracte après une remarque désobligeante de Developpez.net à propos du C++
La DGSI française et le ministère des armées présentent leurs excuses au groupe d'experts éminents
Crédible ? Hem ! C'est quand même Google ! Le million de dollars donné à l'équipe Rust pour faciliter la migration parle bien. Qu'ils aient raison ou tort, ils entérinent la mort de C++ sur toutes les plateformes où Rust est implémenté. Donc il est deux fois crédible, d'une part, il est Google, d'autre part, il paye pour aider à faire le job.[B][SIZE=4]
Mon avis, je l'ai déjà donné plus haut. C gardera l'immense marché du petit embarqué. C++ est sur le barbecue.
Pour une application desktop, vu l'évolution de Java, C# est la première option à considérer. L'écriture d'un gros projet en full C++ a toujours été un choix inexplicable selon moi. Les bugs sont très méchants, les temps de dev sont monstrueux.
Pour du temps réel vraiment pointu comme un séquenceur audio (DAW) par exemple, le choix est plus difficile même si les machines d'aujourd'hui propulsent un programme javascript beaucoup plus vite que le même programme en assembleur d'il y a 20 ans. Il reste des problèmes de milliseconde qui peuvent se poser typiquement à la lecture d'une séquence musicale sur 20 pistes utilisant une demi douzaine d'instruments VST différents. Le minimum de synchronicité dans ce cas est d'au moins 5 ms. Un délai à la portée de langages de haut niveau avec un CPU récent quoique on puisse souhaiter descendre plus bas et employer Rust comme une bibliothèque pour améliorer la "résolution temporelle" (subtilement différente de la vitesse d'exécution)
D'autre part, dans les hackatons (CodinGame) les modules C++ tombent comme des mouches à chaque upgrade du compilateur. Très peu de modules survivent à 3 ou 4 upgrades (certains y parviennent quand même). C++ est quand même ultra sensible aux mises à jour.
A voir si le software des géants (office, .net framework, chrome, etc...) fera sa mue. Les grands éditeurs en ont les moyens. Je dirais même qu'ils y ont intérêt.
A voir aussi combien d'éditeurs moyens ne pourront pas faire face et mettront la clé sous la porte.
Il est évident que développeur Rust est une situation plus enviable que développeur C++ depuis quelques mois.
Rust a gagné tous les suffrages de toutes façons. Il semble évident que le marché l'adopte massivement à l'avenir.
Ou alors tu n'as pas compris la phrase.
Mais franchement, c'est pénible et sans intérêt de discuter avec toi. Tu veux pas comprendre et tu nous prend pour des cons quand on n'est pas d'accord avec toi. Je vais arrêter de perdre mon temps.
Au final, Google conclue les mêmes choses que l'on sait déjà, à savoir (j'ai lu en diagonal la news, pas le doc publié) :
- les problèmes mémoire sont une cause importante des vulnérabilités connues
- c'est impossible de réécrire tout le code C++ existant
- Rust n'empêchera pas tous les bugs
Donc globalement, cela reste un pari a faire sur l'évolution des différents langages et pratiques. Et différents contextes (on n'est pas tous Google, avec leurs problématiques spécifiques, ainsi que leurs moyens)
Dans ton lien : "They define the semantics of an imperative programming paradigm". Question naive : pour les autres paradigmes, en particulier (au hasard...) en POO, il y a des sémantiques spécifiques ou c'est la même sémantique appliquée à de la POO transformée en impératif ? EDIT: et pour la concurrence ?
C'est pas comme si à chaque message que je poste, y'avait pas une meute pour me dire que j'ai pas compris, ou que je suis "idiot". Vous n'êtes pas du tout le genre à interrompre quelqu'un qui parle, fût-ce pour lui dire des âneries hors sujet.
Je n'ai pas le souvenir d'avoir jamais "discuté" avec toi. Ma mémoire fuite peut-être. Si tu trouves ça pénible, surtout, passe au message suivant. Le thread n'appartient pas à l'un ou l'autre des commentateurs que je sache.
Tout énervé que tu sois, cette citation est très explicite et dit quelque chose que je ne veux pas entendre dans une équipe de dev. Donc, pour conclure, je dirais que je l'ai très bien comprise et peut-être a-t-elle été mal traduite. Je ne parle pas un mot de polonais.
Je n'ai pas été impoli en faisant cette remarque qui reste proportionnée et appropriée.
Google est dans son domaine le Web. C'est dans ce contexte que l'on observe le plus de vulnérabilités . N'importe qui peut essayer de trifouiller une application accessible par le réseau. Les attaques sur internet avec Google sont un véritable fléau qui dépasse de loin la conception du C++.
Rust ne remplacera jamais le C++ qui est un langage sur pour qui ne fait pas d'aberrations. L'avantage du borrowing de Rust ne peut pas effacer toute l'architecture du C++. Il en faudrait plus pour menacer le C++.
Le problème du C++ c'est la lourdeur si on ne va pas à l'essentiel et la surcharge syntaxique qui est inutile à mon sens.
Google parle Android, Chrome c'est le monde de l'internet c'est à dire le terrain des arnaqueurs de tout poil. Si on pouvait réduire la cybercriminalité par une rustine comme Rust on l'aurait déjà fait. Mais il faut être réaliste. Mais il est tout à fait concevable que des acteurs d'internet comme Google créent leur propre langage pour mettre à disposition leurs services . A l'heure actuelle il y a une tribu constituée de Rust Go Julia Swift qui tente de percer. Google c'est le Go. Mozilla c'est le Rust. Apple c'est le Swift. Le poids de ces entreprises est tel qu'il peut modifier la donne dans le développement informatique.
Je préfère swift à Rust mais Rust est mieux supporté par la communauté.
C'est pour remplacer Objective C. Faut pas rêver cela ne diminue pas la complexité de Cocoa sur Mac. Objective C s'est vu maudit du jour au lendemain alors que c'était un langage très ouvert permettant l'intégration du C et du C++. Apple travaille sur la compatibilité du C++ avec Swift.Je préfère swift à Rust mais Rust est mieux supporté par la communauté.
Pour revenir à ces acteurs de l'internet qui refond le monde des langages on s'étonne qu'Amazon n'ait pas crée le sien. Du moins à ma connaissance. Mais j'insiste sur le fait que ces problèmes de mémoire sont étroitement liés au contexte dans lequel on utilise un langage comme le C++ ou pourquoi pas Python . La gestion de la mémoire sur Python me surprendra toujours. Mais bon ce n'est pas un langage compilé.
Avec le C++ ce qui est critique est la move sémantique dans la navigation des objets en mémoire. Cela induit un partage potentiel excessif des objets en mémoire. Maintenant on dit que Java est plus sur mais avec son garbage collector on ne peut pas bien voir ce que deviennent les objets en mémoire. Pas plus qu'avec Javascript . Mais bon dans la catégorie des langages compilés Ada est sans doute très scrupuleux et C# sur Windows héritier du Pascal Delphi semble assez assez surs.
Objective C était prometteur. Son modèle objet était élégant à l'oeil.
Pour la sécurité mémoire, le problème est centré sur les langages compilés ciblant un CPU précis. Les langages p-codés à GC comme java ou .net ne sont pas vraiment concernés. Les langages interprétés comme javascript ou python sont à priori immunisés à 100% pour autant que l'interpréteur soit bien débuggé.
La garbage collection, c'est à cause d'elle que Google parle de "sécurité temporelle", du moins, je l'interprète comme ça. La prose des géants reste un peu évasive...
Ce qui m'étonne le plus, c'est de savoir que Rust est déjà implémenté dans Chrome et Android. Ils ont visiblement déjà beaucoup investi dans la migration.
Je veux bien parier ma plus belle chemise qu'Amazon ne créera jamais de langage compilé. Pas son style, trop de problèmes, pas assez de revenu, responsabilité très lourde. Les langages, c'est surtout l'affaire des éditeurs d'OS qui ont toujours un avantage pour placer leur système si les API de leur OS sont bien implémentées. En outre, ils ont besoin d'outils pour leurs développements internes.
Amazon pourrait bien éditer un langage de script pour naviguer dans les offres AWS ou retail. Mais rien de plus qu'un genre de shell script.
C pourrait bien revenir dans les annonces d'emploi par le truchement de contrôleurs bien pourvus en mémoire qui viendraient grignoter le marché des machines d'enregistrement logistiques (type TPV ou caisse enregistreuse dans les boutiques).
Pour la demande de développeurs, la double compétence C++ et Rust pourrait être très recherchée dans un avenir très proche.
en C++/ C, ce qui est surtout critique, c'est d'avoir des programmeurs super qualifiés et se prendre la tronche pour ne pas faire "d'erreurs" (du moins réduire au maximum)
C'est 1 ancien débat entre le C++ et le Java : avec le C++ tu te focalises sur le comment faire, avec Java sur ce que tu dois faire.
Si 1 langage comme Rust permet dans 1 temps assez rapide de supprimer 1 grande partie des "erreurs communes", c'est déjà 1 énorme +.
C'est comme le casque pour le vélo. En apparence, cela ne sert pas à grand chose. Mais, il permet de ne pas surcharger les urgences pour le moindre choc "bénin".
De de toute façon, plus le temps passe, et plus dans le domaine embarqué on commence à avoir de gros processeurs et 1 bonne capacité mémoire.
Et donc à terme ne plus se focaliser sur le pouillième de performance qu'1 langage pourra apporter. Tout sera sandboxé (peut-être virtualisé).
Regarde la Switch avec Zelda ToTK : ce qu'1 ""téléphone de 2015"" est capable de faire/ d'afficher.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager