Je me pose une question méta physique ce soir.
Qu'est-ce qu'un langage sécurisé ?
En général, lorsque l'on voit ce terme, Java n'est pas loin. Mais il est plus souvent question de JVM que du langage lui-même.
La jvm controle le champ d'execution d'un programme pour empécher d'aller faire des choses non autorisé : accéder directement à certaine fonctions, injecter du code, executer du code non prévus en injectant des paramètres, accéder à des IOs interdite, accéder directement à la mémoire, etc...
Mais du point de vue du Langage ? J'imagine qu'il doit absolument pouvoir éviter les horreurs du C comme les buffers overflow. Mais est-ce que tous langages avec allocation automatique de mémoire serait protégés ?
La plus part des attaques du C sont basé sur ce problème : le retour dans la libc, l'injection de code dans la pile, etc... Par contre, les bug de printf avec "%n", est plus un problème de non controle de paramètres par le C.
On peut aussi bannir les pointeurs qui permètent de casser la ségmentation des données (au profit des références).
On peut aussi ajouter toutes les fonctionnalités qui empèchent les bugs et assurent plus facilement que le code soit correct.
Mais est-ce suffisant ? Y'a t -il d'autres paramètres à prendre en compte ?
Journal Qu'est-ce qu'un langage sécurisé ?
11
nov.
2007
# Le fortran
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
[^] # Re: Le fortran
Posté par z a . Évalué à 1.
[^] # Re: Le fortran
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Fortran traine (souvent ici) une image de langage vieux et dépassé mais il a su évolué bien plus que d'autres langages qui sont nés après et déjà mort.
Par exemple, le compilateur NAG sais gérer l'allocation dynamique avec ramasses miettes. Avec ce compilateur, il n'est pas nécessaire de déallouer la mémoire et il n'y a pas de fuite mémoire possible (contrairement au C)...
Avec g95, il est aussi possible de suspendre un programme dans un fichier pour le redémarrer plus tard au même point. C'est le compilateur qui gère tout cela. A ma connaissance, gcc pour le C ne fait pas cela.
Cela peut paraitre bête mais un programme écrit en Fortran 98 est à la fois lisible et clair (important pour la sécurité) tout en étant performant.
[^] # Re: Le fortran
Posté par z a . Évalué à 1.
call toto(2)
i = 2
write (6, 100) i
stop
100 format(i5)
end
subroutine toto(j)
j = j + 1
return
end
affecte 3 à 2, du coup, i vaut 3 en faisant "i = 2" (selon mon cours)
[^] # Re: Le fortran
Posté par lasher . Évalué à 3.
[^] # Re: Le fortran
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
D'ailleurs, un code en F77 ne compilera plus sur un compilateur F2003 car le langage a éliminé pas mal de structure aujourd'hui obsolète. Ce type de structure avait une raison à l'époque ou elles ont été écrites mais ne devrait plus être donné en exemple pour dénigrer un langage de nos jours.
Un truc très beau des vieux Fortran mais complètement imbitable de nos jours, un vieux programme Fortran peut être écrit sans espace ! On colle tout ! L'intérêt se comprends si on a utilisé un tant soit peu les cartes perforées (ce qui n'est pas mon cas). Le F90 a du être compatible avec cette contrainte. Essayez d'écrire un langage de programmation sans séparateur... Bon courage.
[^] # Re: Le fortran
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Avec les derniers Fortran, tu es obligé de déclarer toutes les variables. Il n'y a plus de variable implcite. Enfin, avec un drapeua du compilateur, tu peux mais c'est à tes risques et périls...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le fortran
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Je ne parle pas non plus du Fortran 77 et de ses COMMON... Tout cela est maintenant dépassé.
Lorsque je parle du Fortran, j'évoque la dernière version, F98 (qui n'a pas vraiment d'existence légale = F95 + quelques extensions), voire du F2003 qui supporte l'héritage simple (alors que le C ne le fait pas !).
Fortran, c'est autre chose qu'une version du langage qui a plus de 30 ans aujourd'hui. Le grand ménage a été réalisé avec F90, cela commence quand même à faire...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le fortran
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Ensuite, je suis preneur de langage plus adapté pour faire du numérique. J'avais trouvé Sather avec lequel je m'amusais bien mais il est mort.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le fortran
Posté par lasher . Évalué à 3.
1/ Beaucoup des bibliothèques d'analyse numérique ont leur API en FORTRAN [1], ce qui force le programmeur/utilisateur à comprendre un minimum comment fonctionne ce langage (et dans le cas de pas mal de numériciens et physiciens, ils ont carrément appris la programmation avec ce langage, car il permet certaines constructions très pratiques qui n'existent pas nativement en C, comme par exemple les instructions vectorielles « natives »).
2/ En F77, comme il n'y a pas de pointeur, il n'y a aucun risque d'aliasing, c'est-à-dire de pointeurs différents dont les zones mémoires pointées se recouvriraient. C'est une propriété extrêmement importante en ce qui concerne les transformations optimisantes qu'un compilateur peut appliquer sur un code.
Avec FORTRAN 90 et ses successeurs, il est toujours possible de signaler qu'il n'y a pas de recouvrement de zones mémoires (tout comme en C avec certains compilateurs d'ailleurs), mais là ça devient la responsabilité du programmeur de s'en assurer a priori.
Comme je l'ai dit précédemment, on a aussi la présence d'instructions « vectorielles », qui permettent d'effectuer une même opération entre deux tableaux, de façon transparente, et qui simplifie du coup énormément l'écriture de programmes.
3/ À cause de 1/ et 2/, le FORTRAN se prête déjà bien à tout ce qui est analyse numérique, mais tout ça, on pourrait certainement le dire avec Haskell ou LISP, en effet. Ce qui différencie FORTRAN du reste des langages, c'est qu'en plus, il est, tout comme le C, proche de la machine, ce qui est extrêmement important.
Enfin, une petite remarque : FORTRAN est lui aussi « issu des maths ». :-)
[1] Ce qui est gênant, car il m'arrive de voir parfois des implémentations en f77 qui sont sémantiquement correctes, mais à des années lumières de l'optimisation souhaitée pour les architectures actuelles.
[^] # Re: Le fortran
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Important pourquoi ? Pour être rapide ? Pour pouvoir plus facilement optimiser son code ?
"La première sécurité est la liberté"
[^] # Re: Le fortran
Posté par lasher . Évalué à 2.
Après, tout dépend de l'application qu'on veut faire. Je dirais que, mis à part le calcul scientifique, ou en tout cas les noyaux de calcul ou la conception d'OS, il serait de bon ton de lâcher le plus possible des langages tels que C ou FORTRAN, car ils sont (enfin je trouve) extrêmement difficiles à maîtriser correctement.
Pour ceux que la prog fonctionnelle ne gêne pas, programmer avec OCaml permet d'obtenir de très bonnes perfs tout en ayant un système de vérification des types extrêmement bon (et le pattern matching de code est un super outil). Pour les autres, tout dépend de ce qu'on veut faire, mais je trouve que les langages dits de 4è génération sont plutôt bons et permettent d'éviter pas mal d'erreurs car le code est simple à écrire et à relire (beaucoup plus simple qu'en C/C++/FORTRAN/etc).
Enfin, ce n'est que mon avis. :)
[^] # Re: Le fortran
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
Pour Haskell et OCaml, j'aime bien mais je ne suis pas sur qu'il soit facile d'y rentrer dedans si on n'a pas fait un peu de cours d'informatique sur ce type de langage. Or, à par en math appli, les étudiants n'ont en général aucune notion d'informatique au niveau des langages fonctionnels.
Enfin et surtout, si tu vas sur les grosses machines de type IDRIS (Calculateur vectoriel NEC, cluster superscalaire IBM, SMP avec BUS NUMA performant SGI...) tu vas pleurer avec les langages que tu proposes... Tous les outils tournent autour du C, C++ et Fortran et si tu n'utilises pas les bibliothèques de la machine, ton code va se trainer.
Dans le futur, un code scientifique non parallèle est à mon avis un code mort. Il faut donc avoir un langage qui utilise au mieux l'architecture d'une machine fortement parallèle. Selon SGI, très peu de code sont performant au dela de la barrière des 1000 coeurs...
C'est peut être cet aspect la qui va faire bouger les choses d'un point de vue langage.
[^] # Re: Le fortran
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Le fortran
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Ici le problème est d'arriver à écrire un programme très fortement parallèle qui ne passe pas son temps en communication. C'est donc plus un problème d'architecture matérielle et logicielle que de programmation pour commencer.
[^] # Re: Le fortran
Posté par lasher . Évalué à 3.
#pragma omp parallel for
(avec éventuellement quelques ajouts pour dire ce qui doit être privatisé, public, les chunks en termes d'itérations à faire, quelles variables servent à faire des réductions, etc), alors qu'un programme MPI doit explicitement déclarer toutes ses communications, et donc le programmeur effectue nécessairement bien plus de boulot à lui tout seul.
Le problème avec OpenMP, c'est qu'on a nécessairement une barrière implicite à la fin d'une section parallèle. On peut tenter de s'en dépatouiller en utilisant « nowait » comme mot-clef dans certains cas, mais cela ne fait que retarder le moment où il faudra synchroniser les accès.
Le problème avec MPI, c'est qu'en plus d'avoir à tout faire à la main, je ne connais pour le moment aucune implémentation qui soit thread-safe ET efficace.
À mon avis, il faut un peu plus chercher du côté d'OpenMP, et revenir à des bibliothèques de threads à deux niveaux (MxN), où on fixe des threads noyau sur les coeurs/processeurs, et où on spawne des threads utilisateur à chaque nouvelle section parallèle (ce qui permettrait peut-être de « coller » au modèle fork/join d'OpenMP, tout en ayant un overhead minimal, et en assurant une possibilité d'avoir des « sections parallèles récursives »).
MPI est super efficace, mais bien trop contraignant à mon goût.
[^] # Re: Le fortran
Posté par lasher . Évalué à 3.
N'empêche que pas mal de problèmes parallélisables sont bien plus facilement exprimés en termes fonctionnels qu'impératifs. Si on rajoute les bons mots clef aux langages (impératifs ou fonctionnels) pour gérer une forme explicite de parallélisme, je pense qu'on peut faire de très jolies choses (cf Erlang, par exemple, même s'il induit trop de synchros pour le genre de calculs que je fais).
[^] # Re: Le fortran
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
http://isaacproject.u-strasbg.fr/download/Lisaac_RM_03.pdf
"La première sécurité est la liberté"
[^] # Re: Le fortran
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: Le fortran
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Le fortran
Posté par lasher . Évalué à 2.
Une extension non standard dans l'implémentation OpenMP d'intel a un peu la même façon de procéder.
Bref, ça me semble plutôt bien, vu que j'utilise approximativement la même méthode. ;-)
En fait le seul problème pour ce que j'ai lu de COP (qui est aussi une limitation de notre implémentation aussi), c'est qu'il n'y a absolument aucune préemption (dans le cadre du calcul scientifique c'est plutôt bien), ni de possibilité de vol de tâche (et ça par contre, c'est potentiellement moins bien). Mais comme je n'ai pas lu jusqu'au bout, peut-être que je me trompe. :-)
[^] # Re: Le fortran
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
En gros, tu veux régler des problèmes typiquement temps réel ?
"La première sécurité est la liberté"
[^] # Re: Le fortran
Posté par lasher . Évalué à 2.
Maintenant non, je n'ai pas besoin de temps réel, mais le vol de tâche permet d'équilibrer la charge de calcul sur une machine parallèle.
Typiquement, dans un cas tu dois prévoir avec un ordonnancement statique l'intégralité d'une section parallèle car tu veux que la charge soit bien équilibrée sur tous les threads/coeurs/processeurs (sans parler de la gestion des mémoires plus ou moins locales) ; dans l'autre, tu dois quand même équilibrer correctement au début, mais ensuite, tu peux éventuellement continuer à rajouter des jobs dans les queues (en essayant quand même d'équilibrer la charge entre les processeurs), mais si un thread/processeur se retrouve à court de boulot dans sa liste de tâches, il peut toujours aller voir dans les listes de tâches des threads voisins, et leur piquer leur boulot (ce qui soulage un thread d'une tâche, et permet de mieux utiliser les unités fonctionnelles de la totalité de la machine parallèle).
[^] # Re: Le fortran
Posté par Ontologia (site web personnel) . Évalué à 1.
Il suffirait de s'envoyer des Block (une fonction) entre différents objets fonctionnant en parallèle. Les objets/threads ne feraient qu'héberger des blocks qui pourrait voyager en fonction de la charge.
Bon ce n'est que de la théorie(car il y a le problème du contexte), mais ta remarque va être signalée au concepteur du modèle :-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Le fortran
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Oui et non, c'est un boulot d'OS ça.
Que tu utilises une règle genre n+2 threads, avec n == nombre de cpu et que tu charges chaque thread me semble correct. Le +2 est là pour masquer les ios.
Plusieurs fois, j'ai lu sur kernel trap ou la lkml que des gens avaient essayé de rajouter des extentions au scheduler linux pour visser un thread à un cpu. A chaque fois, les performances étaient en baissent pour de sombre histoire de gestion d'interruption.
Bref, si tu as une machine linux avec qq centaines de processeurs, je laisserais faire l'OS.
Je n'imagine pas faire du scheduling à la main pour des raisons de "thoughput" (de bande passante), si on en trouve encore c'est pour des raisons de latence, lié à des contraintes temps réel.
"La première sécurité est la liberté"
[^] # Re: Le fortran
Posté par lasher . Évalué à 3.
Les performances (au moins dans le cas du calcul scientifique) sont clairement meilleures lorsque les threads sont fixés sur un processeur, tout simplement parce qu'un changement de contexte sur un même processeur peut se faire à un coût relativement réduit, alors que migrer un thread d'un processeur à un autre implique la recopie (et donc très certainement de l'utilisation du bus mémoire) pour recopier l'intégralité du contexte d'exécution d'un thread.
D'autre part, je parle d'ordonnancement de threads utilisateur, et pas des threads noyaux en tant que tels (par définition, c'est le noyau qui décide de la préemption ou pas), si ce n'est pour cette histoire de fixer les threads sur un proc donné.
« Bref, si tu as une machine linux avec qq centaines de processeurs, je laisserais faire l'OS. »
Honnêtement, heureusement que les gens ne t'écoutent pas sur les centres de calcul :-)
Migration de thread d'un proc à l'autre => transfert du contexte (comme dit précédemment), mais aussi pollution des caches, et en cas de modèle NUMA, accès distant à la RAM, ou alors overhead dû à la nécessité de recopier les pages mémoire vers la nouvelle mémoire locale ...
« Je n'imagine pas faire du scheduling à la main pour des raisons de "thoughput" (de bande passante), »
Si je fais de l'ordonnancement statique, c'est entre autres parce que la façon dont mes threads utilisateur sont ordonancés, j'ai une pollution plus ou moins grande des caches entre les processeurs (par exemple, l'ensemble de données sur lequel je bosse est subdivisé en sous-ensembles plus élémentaires et indépendants, mais suivant la façon dont je fais ma découpe, les différents threads vont potentiellement écrire dans les mêmes lignes de cache, et du coup un gros traffic va être mis en oeuvre pour régler la cohérence, ce qui n'arrive pas si je fais travailler mes threads sur des portions de données qui n'entrent pas en conflit dans les caches). Comme j'ai des E/S quasi-nulles, c'est le fait de devoir sortir de mes caches qui est le facteur le plus limitant (et quand tu multiplies des matrices, du genre (5000,128)x(128,5000), ça prend un certain temps. Pour te donner un ordre d'idée, en changeant ma façon d'ordonnancer les threads, je suis passé de 8-10 GFLOPS sur 4 coeurs itanium 2 à 18-22 GFLOPS (sur les 25,2 théoriques).
[^] # Re: Le fortran
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Pour ton tests, tu as aussi testé avec Linux qui fait le boulot ? (avec un noyau rescent, pas un 2.4 d'une vieille red hat !)
Concernant le découpages des données à traiter, il est évident qu'un découpage avec un minimum d'indépendance ira plus vite. Je crois même qu'il y a moyen de déclarer des variables "threads private" pour que le compilo puisse faire encore plus d'optimisation. Mais tout cela n'est plus en rapport avec l'ordonancement mais cela a voir avec la découpe des tâches.
De plus, vu l'architecture Intel, le goulot d'étranglement doit rapidement être la RAM.
"La première sécurité est la liberté"
[^] # Re: Le fortran
Posté par lasher . Évalué à 2.
cpu0 - thread 0 fait qq chose.
cpu1 - « rien » à faire.
[INT - on repasse dans l'ordonnanceur, qui s'aperçoit que cpu1 ne fait rien.]
sched: Bon, on va lui filer du boulot hein. Hey, thread 0, va donc sur cpu1 !
thread0 : Euh mais en fait, je bosse déjà sur cpu 0 moi.
sched : On ne discute pas ! On partage le travail ici, monsieur ! Il faut que tout le monde bosse la même charge ! Et n'oublie pas de remplir les formulaires de changement de bur^Wcontexte !
thread0 : OK chef.
[INT - cpu0 ne fout « rien »]
sched: Hey, thread 0, va donc bosser avec cpu0 !
thread 0 : hein ? Mais vous m'avez dit d'aller voir cpu1 !
sched: ON NE DISCUTE PAS !
thread 0 : bureaucrate à la con ...
[thread 0 change de contexte, avec remplissage des formulaires correspondants ...]
Blague à part, je ne fais que fixer un thread sur un processeur/coeur donné, rien de plus, rien de moins. L'ordonnanceur du noyau a tout loisir de préempter ce thread pour y faire passer un job de plus haute priorité s'il en a le besoin. En pratique c'est assez rare que ça arrive, parce que je bosse sur un cluster : je lance mon batch, ça attaque un noeud dont je connais par avance la topologie (important ça, parce que certains noeuds sont NUMA et d'autres non, ce qui change beaucoup la stratégie de parallélisation).
La première chose que fait l'openmp d'intel (qui n'est pas mal du tout, avec un overhead assez minime comparé à d'autres implémentations que je connais) c'est de spawner des pthreads (donc un « bête » pthread_create()) et de les fixer sur des processeurs, parce que l'objectif quand tu fais de la programmation parallèle, c'est d'optimiser à fond la localité des données, et de bien séparer les tâches/les ensemble de données sur lesquelles tu veux bosser.
Ta référence à « thread private », etc., n'est valable que pour OpenMP (qui peut être très bien hein, mais qui a aussi de sérieuses limitations).
« De plus, vu l'architecture Intel, le goulot d'étranglement doit rapidement être la RAM. »
Sur Montecito on a 12 Mo de cache L3, et une architecture plutôt très bien foutue dans le cas des calculs flottants et de calcul sur des flux de données. La bande-passante mémoire est plutôt bonne (de l'ordre de 10Gio/s), donc non, ce n'est pas particulièrement gênant.
Je crois que tu ne saisis pas bien la nature de mon travail, et les outils avec lesquels je bosse. :-) Les pthreads sont gérés par linux, mais par contre j'ai des threads de niveau utilisateur (ce qui revient peu ou prou à un ensemble de couples [pointeur de fonction, pointeur sur arguments à traiter]), qui ont donc un overhead quasi-nul pour mon calcul, mais que je peux affecter au thread noyau qui m'intéresse (et donc au processeur qui m'intéresse, puisque mes threads sont vissés sur un proc particulier). Ça me permet de faire des opérations très fines sur mes sections parallèles (et comme je suis au cycle près, j'ai besoin de ce niveau de contrôle, car même comme ça, il existe de nombreux effets indésirables qui peuvent survenir et qui sont difficiles à diagnostiquer : cache thrashing, faux partage, alignement des données ...).
[^] # Re: Le fortran
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Bien sur que non. C'est une fonctionnalité de NPTL incluse dans gcc, cela doit correspondre à un attribute particulier.
Sur Montecito on a 12 Mo de cache L3, et une architecture plutôt très bien foutue dans le cas des calculs flottants et de calcul sur des flux de données. La bande-passante mémoire est plutôt bonne (de l'ordre de 10Gio/s), donc non, ce n'est pas particulièrement gênant.
12 Mo de cache, c'est ok, tant que tu restes dans le cache ou que plusieurs processeurs n'y accède pas en même temps.
10 Goi/s c'est beaucoup pour un seul processeur mais si tu en as 8 à double coeur, cela commence à faire trés peu... Intel, n'utilise qu'un seul bus mémoire pour l'instant, au contraire des opterons. Normalement, une machine à 8 double coeurs AMD sera bien plus rapide car la bande passante par processeurs est plus élevé.
Tes threads niveau utilisateur, c'est top tant que tu ne fais aucun appel système. Mais j'imagine que tu le sais déjà. Si tu fais des appels système ( read, write ou malloc...), tu gèles tout.
D'ailleurs si l'ordonnanceur ne te convient pas, il y a moyen de le tunner pour que les taches bougent moins vite que d'habitude. Cela tue la latence, mais si tu ne fais pas de réseau, cela peut aller plus vite.
"La première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le fortran
Posté par lasher . Évalué à 3.
Ben oui. Il faudrait tester avec ifort (le compilateur d'Intel), mais en l'occurrence, g95 était loin d'être un foudre de guerre en termes d'optimisation ...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Le fortran
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Le fortran
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
J'avais lu quelques part que ifort ne respectait pas les règles 'IEEE Floating point exception' et que les respecter coutait très chère en temps de calcul.
Donc au niveau du bench annoncé, il faut voir ce qui est réellement calculé et dans quel condition.
[^] # Re: Le fortran
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Le fortran
Posté par lasher . Évalué à 2.
[^] # Re: Le fortran
Posté par mdlh . Évalué à 3.
- Certains aspects de l'IEEE ne sont pas geres materiellement, par exemple les nombres denormalises. Lorsqu'une des operandes dans une multiplication/addition contienr un nombre denormalise, l'operation est effectuee logiciellement, via une interruption, ce qui est long.
- Il existe un drapeau disant "au lieu de generer une interruption lorsqu'il y a un nombre denormalise, consider le nombre comme etant 0." Pour les applications ne necessitant pas une telle precision, cela permet d'accelerer les calculs.
- icc/ifort utilisent cette approche. Gcc aussi avec -fast-math. La difference, si cela n'a pas change, c'est que cette option est dans la liste des options utilisees par defaut lorsque l'utilisateur utilise -O3 avec les produits d'Intel.
[^] # Re: Le fortran
Posté par Troy McClure (site web personnel) . Évalué à 1.
Il y a le même phenomene sur les cpu x86, powerpc, mips etc (même si ça se passe peut etre sans interruption logicielle pour certains), les nombre denormalisés ralentissent les calculs d'un facteur compris en 100 et 1000... La première fois que ça arrive ça fait bizarre :)
# Il n'y a pas de language sécurisé.
Posté par Anonyme . Évalué à 7.
Dans le premier cas (le cas michu), effectivement, contrôler étroitement ce qu'il se passe a l'exécution (sandbox, appArmor & co) peut protéger le système et les données personnelle (du moins une partie) de la madame. Mais on ne peut pas protéger une application qui fait n'importe quoi envers elle même, ce qui nous ramène au cas n°2, si ce sont les données de ton appli que tu veux protéger, c'est l'appli elle même qui doit avoir un comportement sûr, et envers elle même. (pour illustrer, tu peux faire tout ce que tu veux pour protéger ta base de données sur un serveur, avec les sandbox, jails, appArmor SELinux et compagnie, si tu a une faille de type sql injection, tu l'as dans l'os, et sachant que c'est ta propre appli qui gère ces données, tu ne peux pas a la fois accéder a ces données et restreindre l'accès a des fins de sécurité).
Donc, bref, pour l'instant, c'est un problème que l'on ne sait pas régler autrement qu'avec des gens compétents. Rien de magique.
[^] # Re: Il n'y a pas de langage sécurisé.
Posté par totof2000 . Évalué à 10.
Sinon, svp, enlevez-moi ce "u" apres le G de langage ( Personnellement j'aime pas le guateau).
[^] # Re: Il n'y a pas de langage sécurisé.
Posté par enzbang (site web personnel) . Évalué à 2.
# ...
Posté par M . Évalué à 10.
Un langage qui ne fait rien.
# …da sur mon bidet
Posté par Sylvain Sauvage . Évalué à 10.
[^] # Re: …da sur mon bidet
Posté par lasher . Évalué à 8.
Ada est un excellent langage, mais ne rend pas les programmeurs plus intelligents ... Ce qui mène à des explosions de fusée à cause de programmeurs qui font des hypothèses erronées quant à la taille de certaines variables.
[^] # Re: …da sur mon bidet
Posté par gege (site web personnel) . Évalué à 4.
Ada force un développeur à se poser beaucoup de questions pendant qu'il code et qu'il compile (c'est assez difficile d'écrire qq lignes d'Ada sans erreur de compilation et c'est la raison pour laquelle un débutant a beaucoup de mal avec ce langage), c'est le cas pour le typage des variables (ranges,...), pour les pointeurs, pour l'orientation object, la prise en compte dans le langage du multi-tache...
Vaut mieux se les poser à la compilation qu'au runtime quand on obtient le core dump (à supposé qu'on l'obtient pendant les tests et pas en production...) et pour le moment aucun autre langage un tant soit peu utilisable industriellement (je suis sur que dans les labos ils ont des trucs mieux), ne concurrence Ada. On rajoute des régles de codage draconiennes au Java, C, C++ pour ressembler à de l'Ada, on tente de faire de l'analyse statique, bref plein de trucs lours qui sont déjà proprement prévus dans Ada...
Moralité : soyez curieux, aller faire un tour du coté d'Ada, ça va vous sembler lourd au début, mais c'est intéressant de voir ce que peut donner un langage designé pour la propreté et la sécurité.
[^] # Re: …da sur mon bidet
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Qu'est-ce que cela peut apporter de plus ?
Ada semble lourd autant que C peut paramètre léger à écrire. Mais quelles sont les vérifications statiques que fait Ada, qui aident réellement le codeur ?
"La première sécurité est la liberté"
[^] # Re: …da sur mon bidet
Posté par lasher . Évalué à 2.
De plus, même si j'aime beaucoup les langages fonctionnels [1], il n'en demeure pas moins que la machine, elle, reste bêtement impérative dans son fonctionnement et son architecture. Vouloir à tout prix passer par du fonctionnel n'est pas toujours la bonne idée.
[1] Serait-ce une sorte de syndrôme de Stockholm ? :-)
[^] # Re: …da sur mon bidet
Posté par Aldoo . Évalué à 0.
J'ai un peu de mal à voir l'intérêt du porte-plume par rapport à des outils scripteurs comme le stylo à bille ou le critérium.
[^] # Re: …da sur mon bidet
Posté par gege (site web personnel) . Évalué à 4.
Effectivement Ada n'est pas un langage de masse, mais est encore pas mal utilisé dans des domaines ou la sécurité prime (aéronautique, spatial, ferroviaire, ...). En plus il est toujours activement maintenu et étendu (environ une nouvelle norme tous les 10 ans avec Ada83, Ada95 et Ada2005 ce qui à l'échelle de temps des projets utilisateurs est convenable...)
C'est vrai qu'on est toujours tenté de se diriger vers des langages plus utilisés (plus de gens formés, plus d'outils, plus de choix de fournisseurs, ...), mais actuellement pour les applications embarqués critiques, passer de l'Ada au C est une régression (perte de l'orientation object, de l'encapsulation, du typage...) et passer de l'Ada au Java se fera peut-être un jour quand on aura résolu les problèmes du Java (Java temps réel, déterminisme du traitement des exceptions...).
Coté outils notamment avec GNAT on dispose d'une chaîne basée sur gcc donc avec tout le confort moderne (ide, debugger, ...) et coté développeurs j'aurais des doutes sur un développeur C qui ne saurait pas assez rapidement se mettre à l'Ada...
Pour les autres langages (et a fortiori les autres paradigmes de programmation comme la programmation fonctionelle), il leur faut encore franchir toutes les étapes déjà faites pour Ada, C et en cours pour JavaRT afin d'être certifiable pour des applications critiques, ce qui a ma connaissance n'est pas à l'ordre du jour... par contre OCaml, Haskell, Ruby, Python,... et consorts sont utilisés dans l'outillage autour de la production de code critique (générateurs de code, checkers, ...) là ou à mon sens ils ont un véritable intérêt...
[^] # Re: …da sur mon bidet
Posté par Aldoo . Évalué à 3.
1 - là où Ada est un langage concurrent, OCaml et Haskell sont des langages fonctionnels, donc a priori les deux ne sont pas interchangeables sans heurts (dans les mentalités des programmeurs, bien sûr, vu que les deux ont la même puissance théorique).
2 - Ada, bien que mis à jour, date, et il me semble qu'il est principalement utilisé pour des projets (et non des moindres) qui datent de la grande époque d'Ada. J'ai eu l'occasion de donner quelques cours-TD et TP d'Ada l'année dernière dans une UE qui a disparu cette année, sans doute en partie pour cela (mais je n'y mettrais pas ma main à couper : je ne suis qu'un petit moniteur qui ne participe pas à l'élaboration du programme de la licence).
Cela dit, je n'ai rien contre Ada, qui ne m'a pas l'air particulièrement mal pensé, bien au contraire ! Je le trouve tout à fait adapté à de la programmation sérieuse (je veux dire, avec séparation claire en modules pensés et prouvés indépendament les uns des autres).
Il était temps de mettre fin à la grande époque des bidouilles en C (au moins pour les projets sensibles) !
Maintenant, j'ai cru comprendre que, dans les domaines où l'on utilise traditionnellement Ada, on se dirigeait plutôt vers des langages intégrant directement les contrats dans la syntaxe (mais je n'ai pas les pieds dans le monde industriel). Or je ne crois pas que cela se fasse déjà en Ada.
Au fait, il faut quoi pour qu'un langage soit certifiable pour les applications critiques ?
OCaml est très agréable mathématiquement, et je pense pas qu'il soit plus dur de prouver une propriété sur OCaml que sur Ada.
Le problème d'OCaml, c'est plutôt son paradigme, je pense (mais des tonnes d'extensions ont été proposées pour écrire tel ou tel type d'application).
[^] # Re: …da sur mon bidet
Posté par barmic . Évalué à 0.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: …da sur mon bidet
Posté par Ontologia (site web personnel) . Évalué à 1.
Il faudrait poser la question à D. Colnet, il saurait peut être mieux nous expliquer où sont ces éventuels trous
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Object-capabilities, une solution?
Posté par Yoan B (site web personnel) . Évalué à 2.
* http://caperl.links.org/
* http://code.google.com/p/google-caja/
La présentation de caPerl par son auteur est intéressante. Et caja est open source (licence Apache).
Wikipédia contient une liste de langages avec leurs implémentations d'object-capabilities: http://wiki.erights.org/wiki/Object-capability_languages
Pour les amis de JavaScript, une présentation de Sir Crockford chez Google concernant les besoins du web en matière de sécurité: http://video.google.com/videoplay?docid=452089494323007214
# Il y a deux notions de langage securise
Posté par Matthieu Lemerre . Évalué à 3.
Dans la premiere notion, on veut surtout dire que le langage ne permet pas de faire n'importe quoi avec la memoire. Ca
comprend le bound-checks pour les tableaux, l'interdiction de faire des type casts sans verification, interdiction des unions etc.. etc.. Une autre caracteristique des langages securises est que leur execution ne peut pas s'arreter; ce qui ne veut pas dire qu'ils ne peuvent pas boucler sans rien faire, mais qu'il ne vont pas se retrouver dans des situations bloquantes du style devoir dereferencer un pointeur illegal, ou ajouter un entier et une chaine de charactere.
On dit qu'ils sont securises, parce que si j'ai le code source d'un programme dans un tel language, et que je l'execute,
je sais qu'il peut pas faire de dommage (a part boucler, mais c'est facile de s'en prevenir). C'est pour ca qu'ils sont souvent utilises comme moyen de faire des extensions securisees (par exemple, le noyau du systeme d'exploitation Spring comprend un compilateur pour un language securise, permettant l'ajout dynamique d'extensions).
En resume, dans de tels langages on sait a la compilation que le programme va se comporter "correctement".
Dans cette notion, des languages comme CaML ou Haskell sont securises par exemple, mais pas C ou Java (ce dernier ne l'est pas notamment a cause des NullPointerException)
Dans la deuxieme notion, on bride en quelque sorte la bibliotheque pour empecher des interactions malencontreuses avec l'exterieur. Par exemple on interdit la destruction de fichiers, les requetes SQL non verifiees.. Dans cette notion, on empeche l'interaction malheureuse du programme avec le reste du systeme d'exploitation.
Mais a mon avis pour cette derniere notion, il serait plus approprie de parler de "fonctionnalites de securite" du langage et de ses bibliotheques, plutot que de langage securise.
[^] # Re: Il y a deux notions de langage securise
Posté par Matthieu Lemerre . Évalué à 2.
on peut tres bien avoir un langage securise qui fournisse une commande "system" permettant ainsi de detruire tous les fichiers du disque; et un language qui fournisse des fonctionalites de securite mais qui peut planter (comme Java).
[^] # Re: Il y a deux notions de langage securise
Posté par Matthieu Moy (site web personnel) . Évalué à 0.
[^] # Re: Il y a deux notions de langage securise
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
???
Soit tu dis qu'un langage sécurisé est un language pour lequel on ne peut pas avoir de segfault ou de pointeur pointant sur autre chose qu'un objet du type qu'il est censé pointer, et Java en fait partie, soit tu dis qu'un langage sécurisé est un langage où il n'y a jamais d'erreur à l'exécution, et Caml n'en fait pas partie (essaye de calculer 1 / 0 en Caml).
[^] # Re: Il y a deux notions de langage securise
Posté par lasts . Évalué à 2.
[^] # Re: Il y a deux notions de langage securise
Posté par lasher . Évalué à 1.
Java embarque une plâtrée de lambda calcul dans son moteur, justement pour assurer une certaine sûreté des types. Le seul moment où ce n'est pas vrai, c'est avec les types de base (int, char, byte, etc.), où là par contre, on peut encore faire du cast sauvage (jusqu'à certaines limites).
[^] # Re: Il y a deux notions de langage securise
Posté par Gniarf . Évalué à 2.
[^] # Re: Il y a deux notions de langage securise
Posté par Thomas Douillard . Évalué à 2.
# Langage chiant
Posté par barmic . Évalué à -2.
Ce que j'entends le plus souvent quand on parle de langage sécurisé c'est des langage stricts pas de conversion implicite, une syntaxe la plus claire possible (pas d'affectation comme ça " = "),...
Bref un langage chiant à l'opposé même des langage de type interprété comme le PHP.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Langage chiant
Posté par Christophe Chailloleau-Leclerc . Évalué à -3.
http://michel.barret5.free.fr/dev/dev.php
http://michel.barret5.free.fr/contact.php%5C
http://michel.barret5.free.fr/linux/liens.php
http://michel.barret5.free.fr/linux/contact.php
Tous ces liens viennent de ton site, je n'ai rien modifié... Pas mal en 5 pages...
C'est sûr, en php, on peut tout faire. Et contrôler ce que l'on fait sur internet, c'est effectivement aussi de la sécurité. Par exemple contrôler les chemin des fichiers que l'on utilise...
[^] # Re: Langage chiant
Posté par timid . Évalué à 2.
[^] # Re: Langage chiant
Posté par Christophe Chailloleau-Leclerc . Évalué à 1.
Je voulais montrer que les contrôles, chiants ou pas, imposés par le langage ou pas, ça peut être nécessaire...
Je pratique (entre autres) le php, et je l'apprécie pour les usages auquel je le destine...
[^] # Re: Langage chiant
Posté par MrLapinot (site web personnel) . Évalué à 2.
Le module Eliom pour Ocsigen [http://ocsigen.org] résout le problème élégamment avec une notion de services. Enfin, naturellement, on peut toujours faire des liens manuels ou externes, dont la survie est hautement aléatoire.
Cool URI don't change...
[^] # Re: Langage chiant
Posté par benja . Évalué à 2.
[^] # Re: Langage chiant
Posté par barmic . Évalué à 1.
Ça ne m'epêche pas de m'interesser à d'autres langages comme le PHP, mais aussi le perle, le python, le java, l'eiffel, l'ada, le pl/sql, le r,.... Si je fait ce site c'est justement pour apprendre à concevoire un site tout en pouvant plus tard me servir de vitrine
Alors oui mon site est pourri j'ai envi de dire "et alors?".
Ça ne remet pas en cause que les langages non permissifs sont conçu pour embêter le programmeur avant l'exécution et pas après. Si après c'est le mot chiant qui te plait pas, je le retire. Comprend bien que je me sens mieux dans ces langages (je ne considère évidement ni le C ni le C++ comme non permissif mais l'histoire a voulu que je travail principalement avec eux) même si je leur donne un adjectif pas forcément agichants.
Lorse que la plupart des langages interprété mettent l'accent sur la facilité de développement (quitte à choper des bug), les langages non permissifs sont la voie de la rigueur et de la programmation clean.
Je continuerais à travailler sur mon site quand j'en aurais le temps merci de m'avoir fait remarquer ce que je savais déjà.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Langage chiant
Posté par timid . Évalué à 1.
Dans un cas, tu te retrouves avec un client de mauvais poil parce que son programme a des bugs. Dans l'autre tu as le compilateur qui t'insultes plus souvent.
Pour un projet professionnel, j'aurai plutot tendance à vouloir éviter éviter autant que possible le client mécontent ...
Même si aucun langage ne peut garantir l'absence de bugs il faut faire un compromis entre facilité de développement et fiabilité.
Un langage très permissif c'est bien, ca permet de développer des prototypes facilement, mais quand tu dois maintenir le projet (changer les structures de données etc) mieux vaut prévoir quelques tubes d'aspirine et pas mal d'heures de test (vécu sur un projet PHP pourtant pas trop mal codé).
# Typage
Posté par lasts . Évalué à 6.
Certains ont déjà parlé de la sécurité pour madame michu, j'y connais rien et ça ne m'intéresse pas des masses - j'ai une confiance naïve dans les quatre libertés o/
Quoi qu'il en soit, dès qu'on touche à la sécurité de l'application ("es-ce que mon code fait ce pour quoi je l'ai codé et quoi qu'il arrive"), on se retrouve confronté à deux solutions complémentaires : le typage et les batteries de tests.
Les langages fortement typés (Ada a déjà été cité, même si je préfère les langages fonctionnels, qui proposent de l'inférence de type et du polymorphisme, comme ocaml ou haskell [1]) garantissent lors de la compilation/parsage que l'ensemble du programme est cohérent. Vis à vis de php, python ou ruby (et même le c), c'est un énorme plus : pour débuger une application python, il est nécessaire de vérifier le code par la pratique (ie, de parcourir lors de l'éxecution l'ensemble des branches - ce qui n'est généralement pas possible sur de grosses applications).
(Par exemple, HaskellDB [2] propose une solution intéressante au problème des injections sql en exploitant les capacités d'haskell comme l'explique brièvement ce slide : http://www.cs.chalmers.se/~bringert/publ/haskelldb/haskelldb(...) .)
Tester son application consiste à vérifier qu'elle fait bien ce qu'elle doit faire d'une manière automatique (et en séparant les portions testées) : malheureusement, écrire les tests peut s'avérer long et chiant (tout en ne garantissant pas qu'ils mettent en évidence les bugs). À nouveau, le typage peut intervenir dans cette phase comme l'illustre QuickCheck [3] (et d'autres) en générant les tests à partir de rêgles simples. Couplé avec darcs [4], c'est une bonne solution pour garantir que le logiciel ne risque pas de se comporter bizarrement en cours de route.
Bref, un typage fort est pour moi une feature extremement intéressante dans un langage de programmation :p (et pas seulement pour l'aspect sécuritaire, mais surtout pour l'expressivité qu'il apporte).
http://fr.wikipedia.org/wiki/Typage_fort
(En dehors d'ocaml et haskell, on citera également scala [5], qui en plus de proposer une syntaxe "à la java" (peut être plus accessible ?), utilise la jvm (d'où accès aux libs java (et vice versa) et surtout, le sandboxing pour la sécurité du coté utilisateur dont tu parlais au début))
[1] http://fr.wikipedia.org/wiki/Objective_Caml & http://fr.wikipedia.org/wiki/Haskell
[2] http://haskelldb.sourceforge.net/
[3] http://en.wikipedia.org/wiki/QuickCheck
[4] http://www.haskell.org/haskellwiki/How_to_write_a_Haskell_pr(...)
[5] http://en.wikipedia.org/wiki/Scala_(programming_language)
[^] # Re: Typage
Posté par khivapia . Évalué à 3.
l'analyse statique permet de vérifier (ou pointer les défauts) d'un certain nombre de propriétés sur le code :
absence de division par zéro (ou bien alors pointer pourquoi elle pourrait arriver),
absence d'erreurs de pointeurs,
vérifier les valeurs des variables critiques (typiquement, est-ce que la puissance demandée au moteur peut devenir négative... ce qui est mauvais dans un avion ;-)
maîtrise de l'erreur dans le calcul flottant
(cf par exemple http://www.astree.ens.fr/)
Il convient également d'ajouter à cet outil des méthodes plus formelles, du type de celles exigées par les plus hautes qualifications EAL (critères communs), où des outils tels coq http://coq.inria.fr/coq-fra.html permettent de prouver mathématiquement que le code fait bien ce qu'il doit faire (modulo rayon cosmique permutant les bits tout de même ;-) ).
Le principe est d'écrire formellement les spécifications du programme, puis de les vérifier à l'aide de l'outil.
[^] # Re: Typage
Posté par Pipo Le Clown . Évalué à 1.
->[]
PS: http://www.lugnet.com/pause/scala.html
# la sécurité par la simplicité
Posté par Krunch (site web personnel) . Évalué à 7.
Cherchez l'erreur.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# personne ne parle
Posté par briaeros007 . Évalué à 3.
Je pense pourtant qu'un système formel (comme la méthode B [[méthode_B]] est ce qu'il y a de plus sécurisé non?
[^] # Re: personne ne parle
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
Si tu m'envoies un binaire et que tu me promet qu'il a été écrit en B, ça n'est pas suffisant pour moi pour l'exécuter aveuglément sur ma machine. On peut très bien écrire un programme qui fait « rm -fr $HOME » en B, on peut même essayer de prouver qu'il fait bien ce qu'il est censé faire ;-).
Paradoxalement, j'aurais bien plus confiance en une applet Java par exemple, parce que là, mon environnement d'exécution a un contrôle sur ce qu'il se passe, je sais qu'il ne touchera pas à mon système de fichiers local par exemple (sauf bug, mais bon ...).
Mais comme dit plus haut, ça dépends de ce que tu entends par « sécurité », parce qu'inversement, si c'est pour le code embarqué dans un métro, je préfère que ça soit du B que du Java ...
[^] # Re: personne ne parle
Posté par Aldoo . Évalué à 5.
Et là, aucun outil formel ne permet de réduire le décalage entre la compréhension de l'utilisateur/client et la prose, très technique, de la spécif (prendre l'exemple des machines à voter, où la certif démontre normalement un tas de truc, qui finalement ne garantit en rien un vote fiable).
Bref, pour la sécurité, tous les maillons sont importants. Il faudrait d'ailleurs des méthodes formelles pour s'assurer qu'aucun maillon n'a été laissé de côté... (hum). J'imagine qu'en pratique il existe une certaine liste de points à vérifier, établie par l'expérience.
[^] # Re: personne ne parle
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
# Les langages sécurisés ca existe !
Posté par GTof . Évalué à 4.
"Coq est un système de manipulation de preuves mathématiques formelles; une preuve réalisée avec Coq est mécaniquement vérifiée par la machine"
" Coq intègre aussi [...] un mécanisme d'extraction [qui] permet d'engendrer automatiquement des programmes certifiés en Objective Caml, Haskell ou Scheme à partir de preuves de leurs spécifications."
Niveau sécurité c'est béton, vôtre programme fait exactement ce qu'il est censé faire, vous l'avez prouvé.
Si vous trouvez cette approche trop violente, vous pouvez regarder du coté de Conqoction [2]. Concoqtion est une extention de MetaOCaml qui est elle même une extension d'Objective Caml. Elle permet d'avoir un système de type très riche appelé types indexées. Par exemple vous pouvez indexer le type des listes par le nombre d'élements dans une liste, ainsi vous pouvez spécifier une fonction sur des listes non vides, des listes qui ont un nombre pair d'élements, ect ...
La vérification des types est fait par inférence autant que possible et par des preuves que vous pouvez faire en Coq.
Il est certes plus complexe de programmer dans ces langages que de pisser du code en priant pour que ca ne merde pas mais la sécurité est bien souvent à ce prix.
[1] http://coq.inria.fr/coq-fra.html
[2] http://www.metaocaml.org/concoqtion/
[^] # Re: Les langages sécurisés ca existe !
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
J'utilise ça même assez souvent, tant en Haskell qu'en Caml...
[^] # Re: Les langages sécurisés ca existe !
Posté par GTof . Évalué à 2.
Ceci est impossible à faire en OCaml ou Haskell, c'est bien pour ca que des gens développent Concoqtion, Cayenne, Epigram, Twelf, etc .... Si c'était si trvial je pense pas que tant de gens se ferait chier pour rien.
# Mauvaise approche d'un vrai problème!
Posté par Unixfix le Gaulois . Évalué à 3.
En informatique il existe une multitude de langages ayant tous leurs qualités et leurs défauts.
Beaucoup ont tendance à croire qu'un langage ayant des méchanisme de contrôle stricts (genre ADA), une gestion de la mémoire automatisée (java, c#) ou des possibilités limitées (pas de polymorphisme dans Java par exemple) sont plus surs.
Relativement il est vrai ces langages somnt plus sûr car ils limitent les possibilités d'erreurs des programmeurs.
Cependant je ne pense pas que l'on puisse parler de langages sécurisés car la vrai sécurité est étroitement lié à la qualité du code.
La qualité du code elle ne dépend pas du langage mais de facteurs externes:
La conception du logiciel doit être bien faite et suffisament bien détaillée et surtout sans zone d'ombre permettant des interprétaions de la part du programmeur
Le logiciel doit être concu de telle sorte que l'ajout de fonctionalités non prévues au départ puisse être ajoutée sans avoir à faire des acrobaties programatiques (dynamic_cast en C++)
Le programmeur doit être particuliément discipliné (pas de variable non initialisée) et évite d'entrée des constructions complexes que lui seul comprend.
Un Warining pendant la compilation n'est certe pas une erreur mais un problème potentiel en runtime…..
Enfin le software doit être soumis à un vrai contrôle de qualité systèmatique et non du genre pas de bugs pendant 15 jours après la publication donc c'est stable……
En pratique:
Tous les langages sont surs les programmeurs par-contre sont …. Humains donc faillibles!
[^] # Re: Mauvaise approche d'un vrai problème!
Posté par TImaniac (site web personnel) . Évalué à 3.
Je penses qu'en parlant de sécurité il fait plutôt allusion à "lautre côté" du problème : l'exécution de code tiers. Comme s'assurer que le logiciel ne fais pas de bétise (erreur de programmation) voir ne tente pas de faire une action plus ou moins douteuse (virus ?) ?
C'est ce qu'apporte des environnements (plutôt que langage même si c'est lié) comme Java ou .NET en définissant une machine virtuelle premettant de contrôler à l'exécution tout ce qu'effectue le programme : contrôle des accès mémoires, des accès disques, accès réseaux, de manière plus général aux API, et ceci de manière très fine. Le développeur a accès à ces API pour définir sa propre politique de sécurité ou utiliser les politiques existantes.
Un programme plus "traditionnel" qui n'est pas exécuté dans un environnement "managé" n'a pour seul garde fou que l'OS qui fixe des limitations plus ou moins grossières là où il est capable d'effectuer des vérifications (cloisonnement mémoire, accès disque et périphérique, etc.)
Exemple concrêt : une application qui utilise des plugins les charge généralement dans son espace mémoire, en tout cas du point de vue de l'OS. Il a généralement les mêmes droits que l'application "hôte". Pourtant le plugin peut être téléchargé sur internet, et avoir un comportement plus ou moins douteux.
A moins de mettre en place un cloisonnement manuel (style fork avec utilisation de comptes avec actions restreintes) qui revient à réinventer un framework de sécurité...
Dans un environnement type Java ou .NET on peut donner des droits particuliers pour ces modules (d'ailleur un module provenant d'un composant téléchargé aura automatiquement par défaut une politique de sécurité très restrictive) et créer des cloisonnement de manière propre pour s'assurer que le plugin ne fait pas n'importe quoi sur la machine, et ne fait pas n'importe quoi dans l'application hôte (ne serais-ce que pour pouvoir décharger le module responsable sans tout péter).
Mais tout cela demande un modèle de code exécutable qui soit contrôlable, ce qui suppose un certain nombre de limitations sur les instructions qui sont exposés. C'est l'intérêt d'avoir un bytecode intermédiaire. Ce qui au passage impose un certain nombre de limitation aux langages qui sont implémentés au dessus.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.