| 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465 |
- \section{La notion d'étage}
- L'architecture que nous allons construire se place contextuellement dans celle
- de VLC. Celle-ci se base fortement sur la réalisation d'un pipeline de
- traitement dynamique, créé au fur et à mesure de la lecture des flux multimédia.
- Les différents éléments de ce pipeline seront créés éventuellement dans la même
- zone de privilège, éventuellement dans une zone de privilège déjà existante ou
- même donnera lieu à la création d'une nouvelle zone de privilège. Pour désigner
- cette nouvelle réalité du point de vue du client, on crée la notion d'étage, ou
- «stages», qui permet de ne pas forcément indiquer comment sera créé la partie du
- pipeline demandée par le client.
- \section{Le modèle broker}
- Dans ce modèle, on considère un processus privilégié qu'on appelle broker, qui
- va contrôler tous les échanges entre les différents processus qu'on appelle
- workers, mais également leur cycle de vie et leurs permissions et accès.
- Le broker est donc en charge de faire le routage des différents messages, de
- transmettre les ressources et faire la vérification d'accès. Il est également
- utile pour vérifier que les processus workers sont encore en vie et signaler les
- erreurs.
- \section{Le modèle orchestrateur}
- Dans ce modèle, on considère un processus privilégié qu'on appelle
- orchestrateur. Celui-ci n'est plus au centre des communications inter-processus
- mais permet d'initialiser les connexions entre deux workers qui vont ensuite
- discuter directement. On doit donc s'attendre à de meilleures performances étant
- donné qu'on diminue les changements de contexte et appels systèmes. On garde cet
- «orchestrateur» pour initialiser chaque nouvel étage mais les modules peuvent
- fonctionner de façon indépendante après, du moment que tous les éléments qui
- sont liés à l'étage ont été créés.
- \section{La notion de processus Zygote}
- Afin d'optimiser le démarrage de nouveaux processus, beaucoup de systèmes
- utilisent un processus spécial, appelé «Zygote». Ce processus est responsable de
- créer les nouveaux processus et permet un démarrage plus rapide en
- préchargeant toutes les bibliothèques et préparant toutes les initialisations
- au préalable.
- Les nouveaux processus sont alors créés à partir d'un appel système
- \inltype{fork} qui est moins coûteux que la création complète d'un processus
- depuis rien. Mais n'est pas officiellement disponible sous Windows,
- officieusement disponible sur les versions Windows 10 professionnels via les
- détails internes liés à l'implémentation des pico-processus, et ne permet pas de
- pouvoir efficacement faire de l'ASLR entre les différents processus de
- l'application. Ce dernier point existe notamment sur Android, même si des
- mitigations existent.
- Le processus Zygote permet également d'efficacement cloisonner les descripteurs
- de fichier à hériter. Mais cela peut être préférée à une méthode plus
- systématique de libération de tous les descripteurs associés au processus.
- Néanmoins, la partie la plus intéressante du Zygote concerne le débogage de la
- sandbox. Sous Linux, \texttt{gdb} n'est capable de s'accrocher qu'à un seul
- processus à la fois. Il faut alors choisir avec \texttt{set follow-fork-mode} si
- l'on veut déboguer le processus parent ou bien le processus enfant lors d'un
- appel à \inltype{fork}. Dans l'architecture que l'on va construire, on sera
- suffisament dépendant de la bonne réalisation des opérations demandées pour
- pouvoir attacher des débogueurs au processus Zygote et basculer directement sur
- le processus enfant à chaque création de nouveau processus.
|
