free2.org a écrit 2367 commentaires

En tant que lecteur assidu de Secunia, je peux te dire que ça fait des mois que je n'ai pas vu un jour sans faille de sécurité non corrigée cruciale et connue dans XP.

La typo était évidente :)

2. Après un test and set réussi, le lock est pris !
Comme tu es très pointilleux sur les mots, je corrige le point "2."

2. Après un test and set réussi, la variable est modifiée ! Donc il n'y a aucun risque qu'un autre process puisse posséder la resssource en même temps. Cet autre process devra faire de l'attente active (par définition d'un spin-lock) s'il veut posséder la ressource. S'il veut être sûr de ne pas faire d'attente active, alors il doit utiliser un syscall semaphore au lieu du spinlock.
Mais dans le cas de Linux, les futex permettent d'éviter ce dilemne sans utiliser un sous-scheduler interne

On peut [échanger des données sans recopie, entre 2 entités avec des privilèges différents, avec un signal], mais c'est très con.
Peut-on avoir une indication pour éclairer notre lanterne ?

Ceci étant je croyais que le but était de séparer les privilèges, dans ce cas là ca marche très bien.
Là aussi, peux-tu expliquer comment 2 threads d'un meme process peuvent séparer leur privilèges ?

Pour être complet, il faut ajouter que les brevets pharmaceutiques sur les antiviraux ont aussi une lourde responsabilité dans le coût inabordable des traitements en Afrique.

L'espérance de vie en Afrique, où il y a de nombreux catholiques, a chuté fortement à cause de la mortalité massive du SIDA.

Un pape non intégriste doit reconnaitre que l'adultère c'est humain (sans compter les autres modes de contamination, nombreux en Afrique par manque d'hygiène), et que par conséquent il faut mettre des capotes.

La séparation des privilèges ne nécessite pas forcément la séparation des process. Il existe un autre système d'IPC qui s'apelle les signaux.

Les signaux sont des interruptions, pas un échange de donnée. Tu fais comment pour échanger des données sans recopie entre 2 entités ayant des privilèges différents , avec un signal ?

En tant que lecteur assidu de Secunia, je peux te dire que ça fait des mois que je n'ai pas vu de faille de sécurité cruciale et connue dans XP:
http://secunia.com/product/22/(...)

Boucle atomique.... ??? Mais pourquoi aurait-elle besoin d'être atomique ?

Test_and_set atomique signifie il y a 1. "avant" et 2. "après", mais pas "pendant":

1. Avant: Si le process est suspendu par le noyau avant que le test_and_set atomique réussisse, il n'y a pas de problème puisque la ressource (le lock) n'est pas possédé.
2. Après un test and set réussi, le lock est pris ! Donc il n'y a aucun risque qu'un autre process puisse posséder la resssource en même temps. Cet autre process devra faire de l'attente active (par définition d'un spin-lock) s'il veut posséder la ressource. S'il veut être sûr de ne pas faire d'attente active, alors il doit utiliser un syscall semaphore au lieu du spinlock.
Mais dans le cas de Linux, les futex permettent d'éviter ce dilemne sans utiliser un sous-scheduler interne:
"It is typically used to implement the contended case of a lock in shared memory"

"When a futex operation did not finish uncontended in userspace, a call needs to be made to the kernel to arbitrate. Arbitration can either mean putting the calling process to sleep or, conversely, waking a waiting process"

Pour toutes les threads d'un même processus, le registre CR3 est le même
Ceci est surtout obligatoire dans le cas où la libpthread organise un sous-scheduler pour les threads à l'intérieur d'un process (changements de threads qui peuvent donc se faire sans passer par l'OS, donc sans la possibilité pour l'OS de modifier la page table).

D'un autre coté il est pas en user space et risque pas de se faire interrompre par le noyau. Ca aide.
Les SMP peuvent gêner les locks non atomiques autant qu'un appel système !

Là il va falloir que tu me donne ta définition de spinlock
Je crois que c'est la même que celle de Galactic B:
Un spinlock consiste à boucler sur une instruction "test&set" atomique du processeur.

la majorite de la planete utilise des threads plutot qu'une archi multi-processus
Tu jettes ton masque :)
Justement, beaucoup d'utilisateurs de windows aimeraient bien que l'architeture multithread de win déconne moins souvent, et avec moins de failles de sécurité publiques non corrigées depuis trop longtemps. Pourquoi ne sont-elles pas corrigées rapidement ? Parce que le moindre changement peut perturber la dynamique des threads, cf l'article que l'on commente, et fait apparaitre de nouveaux bugs. C'est ça l'enfer des threads.

ça y'est... j'avais pas encore fini de taper :)

Je répond ici à Kha sur le scheduler interne:

Si tes estimations sont exactes, c'est en effet un scheduler interne performant.

Mais faire du sous-scheduling n'est vraiment utile que quand les flux concurents s'échangent en permanence de touts petits bouts de données. Dans le cas de nombreux algorithmes où des processus s'échangent de gros blocs par pipe ou socket, le principal gaspillage est la recopie de ces blocs, évitable par shm.

En attendant que mon reve se réalise, avoir des threads avec des variables privées protégées par sigsegv, je pense qu'il y a plusieurs niveaux de compromis entre la sécurité et les performances:

1. Pour la plupart des programmes d'un Unix qui passent l'essentiel du temps à dormir, il n'y a clairement pas besoin de s'embetter avec des threads. Ni avec les shm.

2. Pour les programmes plus gourmands et qui communiquent habituellement par sockets ou pipe, un shm peut nettement améliorer les performances en évitant les recopies userspace/kernelspace.

3. Quand on veut des bêtes de course fiables (genre les serveurs web Zeus, ou thttpd/mathopd en libre) on peut éventuellement avoir recours à quelques taches ou quelques process (en nombre suffisant pour faire travailler tous les procs d'un SMP), mais surtout à select pour éviter des taches/process inutiles.

La séparation des privilèges, qui nécessite la séparation des process, peut aider à avoir bon niveau de sécurité, malgré une concurence massive.

Ou, si on est prêt à se casser la tête pour démontrer l'absence de tout overflow dans un programme concurent (bonne chance), faire du multithread masssif. Avoir des variables read-only protégées par mprotect peut aider un peu dans ce cas.

4. Enfin quand la fiabilité/sécurité est peu importante, mais la consommation CPU grosse (streams vidéos, jeux locaux ou en réseau...) alors faire du multithread sans démonstration, donc obligatoirement buggé vu la complexité pour gérer des threads.

je te réponds plus bas

Oui, et pendant 50 ans les voitures n'ont pas eu d'airbags,
Exemple parfait.
Justement, Unix a toujours a toujours eu un airbag très fiable: les variables privées sont inacessibles. C'est exactement ce qui assure sa sécurité.

Quand à comparer à une "invention" la communication par mémoire partagée des threads, la shared memory existait déjà pour les processus. Je ne vois pas en quoi ne plus pouvoir avoir de variables vraiment privées serait un progrès.

Surtout si c'est pour économiser quelques instructions de contextes (quasi identiques dans le cas d'un père shm et ses fils) tous les dixièmes de seconde (selon la slice). Je ne suis pas prêt à sacrifier la fiablité de mon système pour un gain aussi négligeable !

mais il faut que ce test&set soit atomique au niveau du cpu sinon c'ets le mur direct.
Le noyau ne ferait certainement pas de spinlock si c'était le mur direct ! Et de toutes façons le noyau peu difficilement faire un appel système pour se synchroniser :)
Les processeurs puissants actuels sont tous capables de faire des spinlocks atomiques.

C'est pas en devenant insultant que tes arguments passeront mieux. Au contraire.

Unix a 35 ans. Il a acquis sa réputation de fiabilité et d'efficacité en utilisant surtout des process indépendants et communiquant par pipe ou socket. C'est encore vrai aujourd'hui. Et les 20 premières années d'Unix étaient complètement dépourvues de threads.

Je dis simplement que nous devons tirer les leçons de fiabilité de l'histoire d'Unix, et tout simplement remplacer les pipe et les sockets par des shm qui sont plus rapides.

Si tu veux encore une réponse, essaye d'être un peu plus correct.

Pas du tout, un spinlock process est un while(1) ou équivalent. Un pthread_spinlock est un event catcher. Si l'évènement ne c'est pas présenté le thread passe la main au thread suivant. Ca change beaucoup de choses.
Si tu arrives à faire tout ça sans faire d'apple système, cela veut dire que tu as un mini-systeme avec scheduler coopératif à l'intérieur de ton process et que tu fais un appel à ce système qui consomme forcément du CPU supplémentaire.

La nouvelle libpthread (nptl) permet ainsi de faire de la synchro entre threads d'applications différentes grâce à des futex placés dans une zone de mémoire partagé (cf pthread_mutexattr_setpshared())
Donc rien n'empeche 2 processus communiquant par shm de se servir de la libpthread pour se synchroniser par futex !

J'aimerais bien savoir techniquement, comment un thread peut-il faire de l'attente passive (pas de consommation CPU, il n'est donc plus shédulé du tout par le système) sans faire un appel système pour dire: je rend la main tant qu'il y a ce lock, schédulez quelqu'un d'autres à ma place.

Ou sinon tu utilises un scheduler coopératif customisé à l'intérieur de ton process, avec consommation de CPU supplémentaire pour gérer ce scheduling interne.

Par exemple, je sais que mon prog en charge pleine bouffe 200Mo. Donc je fais dans mon thread un malloc de 200Mo d'entrée de jeu (et même le plus souvent un calloc par choix perso) et après je gère ma mémoire en interne sans refaire le moindre malloc ni le moindre appel a des signaux systèmes. J'ai fait un malloc et je distribue ensuite au threads qui ont en besoins ce qu'ils me demandent quand ils le demandent. Niveau vitesse je gagne en perf un maximum.
Il faut que tu expliques ça à pbpg ! Car son principal argument contre shm c'est qu'on peut pas utiliser le malloc standard :) Je suis entierement d'accord que c'est la méthode la plus rapide, et tu peux aussi gérer toi-même de très gros segments partagés avec shm sans avoir besoin de passer par un équivalent de malloc !

Quand je sous alloue d'un process vers un de ses threads je fais exactement 0 appels systèmes
Quand je sous-alloue à l'intérieur d'un gros shm, 0 appels systemes.

Quand je lock un segment via un thread encore 0 appels.
Alors tu utilises forcément un spinlock, bien que tu ne les aimes pas d'après un de tes messages un peu plus haut. Sache que le principe des spinlocks fonctionne exactement pareil dans un shm. Aucune différence.

Encore une fois, en regardant les page tables du systèmes, il est facile de voir que des process communiquants avec de gros shm, et des threads communiquant avec de gros mallocs, c'est exactement pareil.

Sauf que les process ont le droit d'avoir des variables strictement privées !

XSI Interprocess Communication, Realtime, shmat(), shmctl(), shmdt(), shm_open(), shm_unlink(), the Base Definitions volume of IEEE Std 1003.1-2001, <sys/shm.h>

UNIX ® is a registered Trademark of The Open Group.
POSIX ® is a registered Trademark of The IEEE.

Je pensais surtout au mappage d'un segment déjà partagé ailleurs via shm
mmap MAP_SHARED|MAP_ANONYMOUS a deja été évoqué pour partager de la mémoire entre un père et sa descendance: aucun syscall de type shmget, aucun fichier ou filesystem lié, pas de RMID/nattch: bref aucun surcout en utilisant cette méthode mmap ANONYMOUS.

C'est toi qui a parlé de l'obligation d'utiliser de syscall pour synchroniser 2 process.
Je t'ai juste rappelé que c'est faux: on peut aussi utiliser un spinlock même si c'est rarement plus efficace à cause du bouclage, en effet. Les spinlocks ont des inconvénients, et je ne les aime pas plus que toi. Et les spinlocks des threads ont exactement les memes inconvénients que ceux de processus partageant leur mémoire.

Comme quelqu'un l'a suggéré un peu plus bas, il n'y a aucune différence au niveau OS entre la synchro de processus partageant de la memoire, et la synchro des threads. C'est juste les bibliothèques en surcouche qui ont l'air différentes. Dans les 2 cas ont peut choisir de faire de l'attente active (boucler) ou passive (syscall).

Si tu n'utilises que mmap sur un segment non.
Il n'y a pas non plus de RMID si utilise mmap dsur plusieurs segments. RMID est une api spécifique à shm.

Si c'est pour shooter le segment à vue quand tout le monde l'a détaché je ne vois pas trop l'intérret de déranger mmap.
??? je parlais du travail de gestion de la VM effectué par l'OS, pour toutes les pages, pas seulement celles issues de mmap, qui n'y changent rien.

De toute façon au moindre changement il faudra que tous les process fassent un syscall pour connaitre l'état du segment avant de faire quoique ce soit d'un peu cavalier dedans.
Prenons le cas d'un segment qui sert de buffer d'échange permanent entre 2 process (une sorte de pipe instantané): le syscall_sémaphore est remplaçable par un spinlock stocké en début de shm.

Voir ma conclusion sur la fiabilité d'Unix, un peu plus haut