Correctly handle `panic()` in the Rust deadline handler
This was submitted for an "advanced" L3 internship. French description at the bottom.
Although it's good practice to avoid them, panic()
can still occur in the deadline handler of tansiv-client. Since this is code called from C, this does not even lead to a clean crash. To make this cleaner, three alternatives:
- make the process abort on
panic()
; - catch the
panic()
and find a way to cleanly handle and report the error if not recoverable; - remove all possible
panic()
and cleanly report errors that are not recoverable.
Ideas about how to cleanly catch panic()
:
- [tanqemu] catch
panic()
while still inside the Rust domain, maybe at the root of the deadline handler; - [tanproc] catch
panic()
while still inside the deadline handler (which is a signal handler); - avoid that the lock protecting the deadline handler gets poisoned:
- useful for non regression tests,
- required to recover from the error (although no error seems simply recoverable for now).
Assuming that we can stop stack unwinding inside the deadline handler, cleanly handling the error would mean:
- [not good for non-reg tests] either displaying the error and aborting the process;
- or reporting the error (kind of clean abort) and cleaning up for next tests.
Internship description in French
Contexte
Afin de simuler un environnement réseau réaliste pour un outil d'analyse dynamique de malware, nous nous penchons sur l'aspect performance du réseau environnant le malware analysé. Nous avons ainsi un prototype de couplage de l'émulateur de PC Qemu avec le simulateur de réseau à grande échelle Simgrid. Ce couplage passe par une bibliothèque écrite en Rust qui fait le lien entre une carte réseau émulée par Qemu et le simulateur de réseau.
Objectif
Une bonne pratique dans un code de bibliothèque Rust, surtout quand il est utilisé par du code écrit dans un autre langage (C dans le cas de Qemu), est d'éviter l'occurrence de panic(). Dans notre prototype les panic() gênent également le déroulement des tests automatiques. Cependant dans notre prototype seules les erreurs les plus probables sont gérées en évitant les panic(). Pour les autres cas, une compréhension du fonctionnement du mécanisme de panic() permettrait d'intercepter les panic() restant pour les traiter proprement.