misc: corrections supplémentaires

chapters/linux_file_descriptor.tex

@@ -5,20 +5,20 @@ différents processus. Nous allons donc lister rapidement les méthodes
 utilisables.
 
 \begin{itemize}
-    \item Les tubes unix ou pipes unix permettent de réaliser une communication
+    \item Les canaux unix ou pipes unix permettent de réaliser une communication
         multi-processus unidirectionnel. D'un côté, un producteur écrit dans le
         tube, ou bloque jusqu'à ce qu'il puisse avoir la place d'écrire. De
         l'autre côté, un consommateur lit dans le tube ou bloque si aucune
-        données n'est disponible. Les tubes unix ont l'avantage d'être très
+        données n'est disponible. Les canaux unix ont l'avantage d'être très
         facile à manipuler et être globalement disponible sur toutes les
         plateformes importantes sans exception. Néanmoins, il ne s'agit que du
         transfert de données et il faut donc un mécanisme d'accès pour les
-        ressources. Les tubes Unix peuvent être créés de façon anonymes avec la
+        ressources. Les canaux Unix peuvent être créés de façon anonymes avec la
         fonction \inltype{pipe}, soit être nommés via la fonction
         \inltype{mknode} ou \inltype{mkfifo}.
 
     \item Les files de message POSIX, ou message queues sont assez proches des
-        tubes unix, mais sont forcément nommées et permettent d'ajouter des
+        canaux unix, mais sont forcément nommées et permettent d'ajouter des
         priorités tout en segmentant les messages. Ici la propriété de
         segmentation est très intéressante pour pouvoir déboguer et parser les
         messages envoyés d'une partie de l'application à l'autre. Néanmoins,
@@ -104,6 +104,7 @@ struct msghdr {
 };
 \end{code}
 
+% TODO reformuler
 Il y a en réalité deux types de buffers envoyés via cette structure. Le premier
 type concerne \inltype{msg_iov} qui est en réalité un tableau de
 \inltype{iovec}. Chaque \inltype{iovec} contient un pointeur vers un buffer et

chapters/other_android_mediacodec.tex

@@ -8,6 +8,7 @@ base prévu pour Youtube qui n'est jamais très loin du format Webm.
 Le webm est un format utilisant une sous-partie du format Matroska, en étant
 spécialement dédié à la diffusion de vidéo sur le web et dans un navigateur.
 
+% TODO: expliquer demuxage
 L'idée pour intégrer les sous-titres lors de la diffusion est donc de démuxer
 les fichiers, puis de rendre ces sous-titres avant directement sur la vidéo
 avant de remuxer puis envoyer au chromecast, le tout en temps réel.
@@ -20,7 +21,7 @@ vite.
 On peut alors utiliser plutôt les circuits d'encodage intégrés sur presque tous
 les téléphones. Ces derniers consomment beaucoup moins d'énergie que leur
 pendant logiciel, mais leurs fonctionnalités sont matériellement figées dans les
-circuits qui les composent. Ils sont également limités en nombre de session
+circuits qui les composent. Ils sont également limités en nombre de sessions
 possible, et peuvent avoir des comportements différents entre chaque téléphone
 ou faire crasher le programme, voire le téléphone en cas d'utilisation
 incorrecte.
@@ -59,6 +60,7 @@ L'encodeur est définit par la structure suivante dans le core de VLC.
 \section{Implémentation de l'encodeur}
 
 Des problèmes arrivent dès le début de l'implémentation. Il n'est en effet pas
-possible de modifier le format de sortie de l'encodeur après son Open. Or les
-informations sur le codec -- codec specific data -- ne sont disponibles qu'après
-avoir commencé à encoder les premières images.
+possible de modifier le format de sortie de l'encodeur après son initialisation
+dans la fonction \inltype{OpenEncoder}. Or les informations sur le codec --
+codec specific data -- ne sont disponibles qu'après avoir commencé à encoder les
+premières images.

chapters/sandbox_architecture.tex

@@ -7,9 +7,9 @@ traitement dynamique, créé au fur et à mesure de la lecture des flux multimé
 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.
+ce concept du côté de l'API publique de la sandbox, on crée la notion d'étage,
+ou «stages», qui permet de ne pas forcément indiquer comment sera créée la
+partie du pipeline demandée par le client.
 
 \section{Le modèle broker}
 
@@ -24,20 +24,21 @@ 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.
 
+% TODO: expliauer IPC
 Les avantages du modèle broker sont qu'il est généralement le modèle le plus
 simple à implémenter, et n'a pas besoin de fonctionnalité particulière du point
 de vue du système, à part pour créer les IPC. Il est également bien plus simple
 à comprendre, à développer, à isoler et à suivre étant donné que tous les
 échanges passent par le broker avant d'être transmis au bon processus. Ce
 modèle constitue ainsi un cadre privilégié pour développer la sandbox et
-l'amener sur tous les système, à condition de garder en tête les contraintes
+l'amener sur tous les systèmes, à condition de garder en tête les contraintes
 des autres modèles.
 
 Le processus broker sera initialisé dans le processus principal et sera donc
 père de tous les autres processus de la sandbox. Cela permettra d'utiliser des
-techniques comme \texttt{ptrace} sous Linux ou d'avoir les droits sur les objets
-des autres processus sous Windows sans avoir à recourir à des droits de
-superutilisateur.
+techniques comme \texttt{ptrace} sous Linux ou de pouvoir créer des objets
+destinés aux processus fils et de leur associer des droits d'accès sous Windows
+sans avoir à recourir à des droits de superutilisateur.
 
 \section{Le modèle orchestrateur}
 
@@ -47,7 +48,7 @@ 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
+fonctionner indépendamment après, du moment que tous les éléments qui
 sont liés à l'étage ont été créés.
 
 %TODO: schéma orchestrateur-worker
@@ -64,24 +65,26 @@ 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.
 
+% TODO expliquer et détailler ASLR et android
 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.
+officieusement disponible sur les versions Windows 10 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.
+systématique de libération de tous les descripteurs associés au processus si
+l'on ne souhaite pas utiliser ce processus pour des raisons de performances
+également.
 
 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.
+appel à \inltype{fork}. Dans l'architecture que j'ai construite, nous réalisons
+les opérations de façon synchrone, même entre deux processus, ce qui permettra
+d'attacher des débogueurs au processus Zygote et basculer directement sur le
+processus enfant à chaque création de nouveau processus.

chapters/sandbox_eventloop.tex

@@ -98,7 +98,7 @@ réalisation, tandis que dans un modèle par disponibilité l'appel à
 Une fois cette abstraction en place, chaque worker va pouvoir recevoir des
 messages venant de plusieurs sources.  On peut commencer à tracer les premières
 communications entre modules, mais il n'est pas encore possible d'effectuer des
-RPC. En effet, les messages que l'on envoient et le découpage que l'on a fait
+RPC.\@ En effet, les messages que nous envoyons et le découpage que l'on a fait
 en eventloop ne permettent pas de recevoir une réponse. Or cette réponse est
 cruciale autant pour garder un modèle synchrone là où il est synchrone dans VLC
 de base que pour pouvoir récupérer le résultat de l'appel de la fonction dans
@@ -118,13 +118,13 @@ un autre module qui ferait une RPC vers le premier module, qui ne pourra pas
 répondre sans la boucle événementielle.
 
 Une autre idée est donc de copier une technique déjà utilisée dans d'autres
-projets, en particulier XCB, et dans des protocoles bien connus comme TCP.  Nous
-allons introduire un compteur de RPC envoyés dans chaque processus, et prendre
-en compte valeur de ce compteur dans les messages.  Lorsqu'un module voudra
-lancer une nouvelle RPC vers un autre module, il utilisera la valeur de ce
-compteur en début de message puis l'incrémentera. Lorsqu'un autre module voudra
-répondre à une requête, il réutilisera la valeur de ce compteur en début de
-réponse.  Du point de vue du proxy, on peut récupérer un
+projets, en particulier XCB, et dans des protocoles bien connus comme TCP.\@
+Nous allons introduire un compteur de RPC envoyés dans chaque processus, et
+prendre en compte valeur de ce compteur dans les messages.  Lorsqu'un module
+voudra lancer une nouvelle RPC vers un autre module, il utilisera la valeur de
+ce compteur en début de message puis l'incrémentera. Lorsqu'un autre module
+voudra répondre à une requête, il réutilisera la valeur de ce compteur en début
+de réponse.  Du point de vue du proxy, on peut récupérer un
 \inltype{vlc_msg_cookie_t} en utilisant \inltype{vlc_msg_SendMsgReply}, qui
 contiendra les détails de la requête, et il sera alors possible d'envoyer autant
 de requêtes que nécessaire puis attendre que les cookies soient utilisés par la
@@ -132,12 +132,12 @@ boucle événementielle pour récupérer les réponses.
 
 % https://xcb.freedesktop.org/manual/structxcb__void__cookie__t.html
 Le mécanisme est analogue à celui de \inltype{xcb_void_cookie_t}, allant jusqu'à
-en reprendre le nom, mais n'est pas basé sur de la génération de code et ne done
-pas de cookie différent par type de requête. En réalité, les cookies devraient
-être pouvoir alloués sur la pile, par exemple, sans que cela soit gênant du
-point de vue de l'API. L'unique liberté qui doit être interdite est de
-transférer le cookie à d'autres fonctions ou stocker le cookie en dehors de la
-fonction dans laquelle le RPC a été effectué. En effet, ce système donne
+en reprendre le nom, mais n'est pas basé sur de la génération de code et ne
+donne pas de cookie différent par type de requête. En réalité, les cookies
+devraient être pouvoir alloués sur la pile, par exemple, sans que cela soit
+gênant du point de vue de l'API.\@ L'unique liberté qui doit être interdite est
+de transférer le cookie à d'autres fonctions ou stocker le cookie en dehors de
+la fonction dans laquelle le RPC a été effectué. En effet, ce système donne
 l'impression de pouvoir faire de la programmation complètement asynchrone, mais
 le contexte dans lequel s'exécute le RPC n'est pas asynchrone. L'appel a lieu
 dans une architecture prévue pour être synchrone et la fonction devra retourner

chapters/sandbox_init_links.tex

@@ -3,11 +3,12 @@ architecture broker ou une architecture orchestrateur. C'est-à-dire qu'on peut
 de toute façon facilement passer d'une architecture non broker à une
 architecture broker avec la construction suivante.
 
-On représente chaque lien entre processus par une IPC du point de vue des
-workers. Il s'agit du cas avec orchestrateur. Si on passe en sandbox avec modèle
-broker, chaque lien est cassé en deux avec une paire worker-broker et une autre
-paire broker-worker, et le broker s'assure ainsi de faire le routage et vérifier
-les accès. On a donc découplé le fonctionnement du worker de la politique
-d'accès choisie. Cette propriété est très importante pour la suite, car elle
-permet de construire le modèle puis d'adapter l'implémentation à ce qui se
-rapproche le plus du fonctionnement du système sous-jacent.
+On représente chaque lien entre processus par un objet
+\inltype{vlc_process_ipc_t}, qui appartiendront aux workers et au broker. Il
+s'agit du cas avec orchestrateur. Si on passe en sandbox avec modèle broker,
+chaque lien est cassé en deux avec d'abord une connexion worker-broker puis une
+autre connexion broker-worker, et le broker s'assure ainsi de faire le routage
+et vérifier les accès. On a donc découplé le fonctionnement du worker de la
+politique d'accès choisie. Cette propriété est très importante pour la suite,
+car elle permet de construire le modèle puis d'adapter l'implémentation à ce qui
+se rapproche le plus du fonctionnement du système sous-jacent.

chapters/sandbox_ipc.tex

@@ -8,11 +8,13 @@ autorisations de chaque processus.
 
 La communication entre les processus est importante car il s'agit de la base
 pour pouvoir effectuer des appels de fonctions distants -- ou RPC pour Remote
-Procedure Call.  Cela va notamment nous servir à calquer l'architecture
-actuelle de VLC pour la faire progressivement évoluer vers un modèle plus
-découplé et moins contraint.
+Procedure Call.  Cela va notamment nous servir à reproduire le modèle
+d'exécution actuel de VLC pour le faire progressivement évoluer vers une
+architecture plus découplée et moins contrainte.
 
-Bien entendu, calquer l'architecture de VLC implique que les RPCs peuvent renvoyer des valeurs et il faut donc que la communication entre deux étages soit bidirectionnelle dès lors que l'un puisse parler à l'autre.
+Bien entendu, reproduire l'architecture de VLC implique que les RPCs puissent
+renvoyer des valeurs et il faut donc que la communication entre deux étages soit
+systématiquement bidirectionnelle si elle existe.
 
 La situation n'est pas totalement la même entre une architecture broker et une
 architecture orchestrateur, mais nous verrons dans la suite qu'on peut se

chapters/sandbox_pattern_modules.tex

@@ -15,8 +15,8 @@ Comme on l'a vu dans les premières parties, VLC fonctionne à travers libvlccor
 en instanciant des modules, stockés dans des \inltype{vlc_object_t}. Chaque
 module étant créé puis détruit par le core, tout en fournissant une API commune
 au type de module, il peut être tentant de proposer de nouveaux modules avec un
-type similaire à celui demandé, tout en implémentant la passerelle vers un
-autre module à l'intérieur même.
+type similaire à celui demandé mais qui jouerait le rôle de passerelle vers le
+module réel dans un autre processus.
 
 Avec cette technique, le sandboxing est plus facile à intégrer dans
 l'application mais moins efficace.

chapters/windows_ipc.tex

@@ -1,3 +1,4 @@
+% TODO: remplacer confiant
 Après les présentations des objectifs liés aux communications inter-processus et
 de l'implémentation Linux, nous pouvons être assez confiant sur l'implémentation
 Windows. Malheureusement celle-ci vient nous rappeler qu'un changement de
@@ -22,14 +23,14 @@ citer:
     passage de descripteur de fichiers.
     https://blogs.technet.microsoft.com/wincat/2012/12/05/fast-tcp-loopback-performance-and-low-latency-with-windows-server-2012-tcp-loopback-fast-path/
 
-    \item Les pipes anonymes, qui donnent un moyen de communication
+    \item Les canaux anonymes, qui donnent un moyen de communication
     unidirectionnel avec un écrivain et un lecteur. Il faut donc utiliser une
     paire de pipe anonyme pour pouvoir discuter en full-duplex.
 
-    \item Les pipes nommés, qui sont capables de fonctionner en duplex
+    \item Les canaux nommés, qui sont capables de fonctionner en duplex
 \end{itemize}
 
-Ici, on va d'abord s'intéresser aux pipes nommés et voir comment on peut les
+Ici, on va d'abord s'intéresser aux canaux nommés et voir comment on peut les
 utiliser pour transmettre des messages et des ressources.
 
 \begin{code}{c}{Prototype de \inltype{CreateNamedPipe}}
@@ -51,10 +52,11 @@ processus. Les ressources sont représentées par des objets \inltype{HANDLE}.
 La première méthode est l'héritage, qui a lieu lors de la création d'un nouveau
 processus. Les descripteurs de fichiers marqués comme héritable, ou bien aucun
 si \inltype{bInheritHandles} est précisé à \inltype{FALSE} lors de l'appel de
-\inltype{CreateProcess}. Lorsqu'un \inltype{HANDLE} est hérité, il garde la même
-valeur dans le nouveau processus et il faut donc le transmettre soit par IPC,
-soit par paramètre de la ligne de commande, soit par injection de code dans le
-nouveau processus.
+\inltype{CreateProcess}, seront récupérés dans le nouveau processus avec la même
+valeur. Lorsqu'un \inltype{HANDLE} est hérité, il garde la même valeur dans le
+nouveau processus et il faut donc le transmettre soit par IPC, soit par
+paramètre de la ligne de commande, soit par injection de code dans le nouveau
+processus.
 
 La seconde méthode utilise la fonction \inltype{DuplicateHandle} pour injecter
 le descripteur de fichier dans le nouveau processus. Dans ce cas-là, si l'appel
@@ -75,8 +77,9 @@ BOOL WINAPI DuplicateHandle(
 \end{code}
 
 Enfin, la troisième méthode consiste à utiliser les objets nommées qui sont
-créés d'un côté par le processus parent, puis ouvert par les processus enfants.
+créés d'un côté par le processus parent, puis ouvert par les processus enfants
+en les référençant par leur nom.
 
-Dans le prototype, j'ai utilisé des pipes nommés pour faciliter la mise en place
-mais j'ai également essayé d'utiliser des paires de pipes anonymes dans d'autres
+Dans le prototype, j'ai utilisé des canaux nommés pour faciliter la mise en place
+mais j'ai également essayé d'utiliser des paires de canaux anonymes dans d'autres
 codes isolés.