diff --git a/tutorial/3/Makefile b/tutorial/3/Makefile
index 2065b17..6974482 100644
--- a/tutorial/3/Makefile
+++ b/tutorial/3/Makefile
@@ -1,7 +1,9 @@
-SOURCES = tutorial.md installation.md chroot.md pseudofs.md mount.md capabilities.md cgroups.md oom.md project-intro.md project-body.md project-rendu.md
-PANDOCOPTS = --pdf-engine=xelatex \
+SOURCES = tutorial.md installation.md chroot.md pseudofs.md capabilities.md cgroups.md oom.md seccomp.md project-intro.md project-body.md project-rendu.md
+PANDOCOPTS = --latex-engine=xelatex \
--standalone \
+ --normalize \
--number-sections \
+ --smart \
-M lang=fr-FR \
-M fontsize=12pt \
-M papersize=a4paper \
diff --git a/tutorial/3/cgroups.md b/tutorial/3/cgroups.md
index 401de90..146c345 100644
--- a/tutorial/3/cgroups.md
+++ b/tutorial/3/cgroups.md
@@ -29,7 +29,7 @@ procédure suivante :
```
-Cette dernière commande monte le groupe de processus racine, pour le *cgroup*
+Cette dernière commande monte l'arborescence de groupes relative à ce *cgroup*
*freezer*. Tous les dossiers contenus dans cette racine sont donc des
sous-groupes.
@@ -144,11 +144,12 @@ l'installer sur notre machine) :
Il nous faut ensuite créer une base de données pour y stocker nos
-métriques. Voici comment on s'était débrouillé dans un précédent TP :
+métriques. Voici comment on s'était débrouillé dans un précédent TP pour
+interagir avec InfluxDB :
```shell
- docker container exec -i mytsdb <
:
+
:
```
diff --git a/tutorial/3/oom.md b/tutorial/3/oom.md
index 44291c7..3376324 100644
--- a/tutorial/3/oom.md
+++ b/tutorial/3/oom.md
@@ -36,7 +36,8 @@ au système de disposer à nouveau de mémoire disponible. Si cela n'est pas
suffisant, un ou plusieurs autres processus peuvent être tués à tour de rôle,
jusqu'à ce que le système retrouve sa sérénité.
-[^oom-algo]: ```c
+[^oom-algo]: \
+```
/*
* oom_badness - calculate a numeric value for how bad this task has been
* @p: task struct of which task we should calculate
@@ -54,7 +55,8 @@ jusqu'à ce que le système retrouve sa sérénité.
* 5) we try to kill the process the user expects us to kill, this
* algorithm has been meticulously tuned to meet the principle
* of least surprise ... (be careful when you change it)
- */```
+ */
+```
## Esquiver l'OOM killer
diff --git a/tutorial/3/project-rendu.md b/tutorial/3/project-rendu.md
index 366da47..5c67ed5 100644
--- a/tutorial/3/project-rendu.md
+++ b/tutorial/3/project-rendu.md
@@ -30,5 +30,9 @@ pour chaque exercice) :
login_x-TP3/view_caps.c
login_x-TP3/monitor.sh
login_x-TP3/monitor_init.sh
+ login_x-TP3/syscall_filter.c
```
+
+Les premières étapes du projet ne sont pas à rendre et feront l'objet
+d'un rendu à part.
diff --git a/tutorial/3/pseudofs.md b/tutorial/3/pseudofs.md
index 968cf18..6171cbd 100644
--- a/tutorial/3/pseudofs.md
+++ b/tutorial/3/pseudofs.md
@@ -121,25 +121,16 @@ afficher des informations sur un processus donné :
-### `batinfo.sh`
+### `rev_kdb_leds.sh`, `batinfo.sh`, `cpuinfo.sh`
Explorons le pseudo système de fichiers `/sys` pour écrire un script
-qui va nous renvoyer des statistiques sur votre batterie.
+qui va, en fonction de ce que vous avez de disponible :
+* inverser l'état des diodes de notre clavier ;
+* nous afficher des statistiques sur notre batterie ;
+* nous afficher des statistiques la fréquence de notre CPU.
-Voici un exemple d'utilisation :
-
-
-```shell
- 42sh$ ./rev_kdb_leds.sh input20
-```
-
-
-
-### `rev_kdb_leds.sh`
-
-Explorons le pseudo système de fichiers `/sys` pour écrire un script
-qui va inverser l'état des diodes de notre clavier.
+#### `rev_kdb_leds.sh`
Si vous avez :
@@ -160,3 +151,55 @@ Voici un exemple d'utilisation :
42sh$ ./rev_kdb_leds.sh input20
```
+
+
+#### `batinfo.sh`
+
+Voici un exemple d'utilisation :
+
+
+```shell
+ 42sh$ ./batinfo.sh
+ BAT0 Discharging
+ ====
+ Capacity: 83% (Normal)
+ Voltage: 11.972000 V (minimal: 11.400000 V)
+ Energy: 18.290000/21.830000 Wh
+ Power: 7.937000 W
+ Remaining time: 2.304 h
+
+ BAT1 Unknown
+ ====
+ Capacity: 83% (Normal)
+ Voltage: 11.972000 V (minimal: 11.400000 V)
+ Energy: 18.290000/21.830000 Wh
+ Power: 0.0 W
+ Remaining time: N/A
+```
+
+
+
+#### `cpuinfo.sh`
+
+Voici un exemple d'utilisation :
+
+
+```shell
+ 42sh$ ./cpuinfo.sh
+ cpu0
+ ====
+ Current frequency: 2100384 Hz
+ Current governor: powersave
+ Allowed frequencies: between 500000 - 2100000 Hz
+ Thermal throttle count: 0
+
+ cpu1
+ ====
+ Current frequency: 2099871 Hz
+ Current governor: powersave
+ Allowed frequencies: between 500000 - 2100000 Hz
+ Thermal throttle count: 0
+```
+
+
+N'hésitez pas à rajouter toute sorte d'information intéressantes !
diff --git a/tutorial/3/seccomp.md b/tutorial/3/seccomp.md
new file mode 100644
index 0000000..111194e
--- /dev/null
+++ b/tutorial/3/seccomp.md
@@ -0,0 +1,92 @@
+\newpage
+
+Secure Computing Mode
+=====================
+
+Plus connue sous l'acronyme *seccomp*, cette fonctionnalité du noyau Linux
+permet de restreindre les appels systèmes qu'un processus est autorisé à
+utiliser. En cas d'appel non autorisé, le processus fautif est directement tué
+(`SIGKILL`) par le noyau, ou, lorsque c'est précisé, un code `errno`
+particulier peut être renvoyé au programme.
+
+Depuis la version 3.17 du noyau, l'appel système `seccomp(2)` permet de faire
+entrer le processus courant dans ce mode. En effet, c'est le processus lui-même
+qui déclare au noyau qu'il peut désormais se contenter d'une liste réduite
+d'appel système ; à l'inverse des politiques de sécurité comme SELinux ou
+AppArmor, qui encapsulent les programmes pour toute la durée de leur exécution.
+
+*Seccomp* est particulièrement utile lorsqu'un processus a terminé son
+initialisation (ne dépendant en général pas de données sujettes à
+l'exploitation de vulnérabilité) et doit commencer à entrer dans des portions
+de code promptes aux vulnérabilités : c'est notamment le cas des moteurs de
+rendus des navigateurs Firefox et Chrome.
+
+
+## Prérequis
+
+L'utilisation de `seccomp` nécessite d'avoir un noyau compilé avec l'option
+`CONFIG_SECCOMP`.
+
+Vous aurez également besoin de la bibliothèque `libseccomp` car l'appel système
+`seccomp(2)` n'a pas de *wrapper* dans la libc, vous devrez donc passer par
+cette bibliothèque.
+
+
+## `MODE_STRICT`
+
+Le mode traditionnel de *seccomp* est de ne permettre uniquement l'utilisation
+des appels système `read(2)`, `write(2)` (sur les descripteurs de fichier déjà
+ouvert), `_exit(2)` et `sigreturn(2)`.
+
+Historiquement, avant la création de l'appel système `seccomp(2)`, on activait
+ce mode via :
+
+
+```c
+ prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT);
+```
+
+
+Une fois passé cet appel système, toute entrée dans un appel système non
+autorisé conduit à un `SIGKILL` du processus.
+
+
+## `MODE_FILTER`
+
+Plus modulable que le mode strict, le mode de filtrage permet une grande
+amplitude en permettant au programmeur de définir finement quels appels
+systèmes le programme est autorisé à faire ou non, et quel sentence est
+exécutée en cas de faute.
+
+Notons que les processus fils issus (`fork(2)` ou `clone(2)`) d'un processus
+auquel est appliqué un filtre `seccomp`, héritent également de ce filtre.
+
+La construction de ce filtre est faite de manière programatique, via
+des règles BPF (`Berkeley Packet Filter`). On passe ensuite ce filtre BPF en
+argument de l'appel système :
+
+
+```c
+ struct sock_filter filter[];
+ struct sock_fprog prog = {
+ .len = (unsigned short) (sizeof(filter) / sizeof(filter[0])),
+ .filter = filter,
+ };
+ seccomp(SECCOMP_SET_MODE_FILTER, 0, &prog);
+```
+
+
+
+### Exercice
+
+Écrivez un programme filtrant un appel système, à l'aide de `seccomp` :
+
+
+```
+ 42sh$ ./syscall_filter sleep 5
+ sleep: cannot read realtime clock: Operation not permitted
+ 42sh$
+```
+
+
+Dans cet exemple, l'appel système filtré est `nanosleep(2)`.