Clarify Flush+Flush paragraph

Makefile

@@ -1,7 +1,7 @@
 main.pdf: main.tex refs.bib
-	pdflatex -interaction=nonstop -halt-on-error main.tex
+	pdflatex -interaction=nonstopmode -halt-on-error main.tex
 	bibtex main
-	pdflatex -interaction=nonstop -halt-on-error main.tex
+	pdflatex -interaction=nonstopmode -halt-on-error main.tex
 
 clean:
 	rm *.bbl *.bcf *.blg *.log *.run.xml *.toc *.aux *.out -f

main.tex

@@ -28,7 +28,7 @@ Université de \textsc{Rennes} 1}
 \date{3 Juin 2024 - 12 Juillet 2024}
 
 % quelques macros
-\newcommand{\TODO}[1]{\textbf{\color{red}#1}}
+\newcommand{\TODO}[1]{{\color{red}#1}}
 
 % le document lui-même
 \begin{document}
@@ -39,17 +39,7 @@ Université de \textsc{Rennes} 1}
 
 \section{\TODO{Abstract}}
 
-\TODO{Réécrire parce qu'il fallait juste que je démarre mais ça ne ressemble à rien}
-
-Les CPU modernes ont beaucoup d'instruction, et leur compréhension complète demande
-une très grande maitrise technique. De plus, le fonctionnement détaillé des instructions des leaders du domaine
-(Intel) est souvent non documenté, compliquant l'émergence de nouvelles industries dans ce secteur
-très compétitif. Certaines attaques par canaux auxiliaire sur le cache comme Flush+Flush \cite{flushflush}
-exploitent des caractéristiques très fines des processeurs, il est alors important de comprendre
-le fonctionnement intrinsèque de certaines instruction pour mieux réaliser
-ces attaques. \textit{Calibration Done right} \cite{calibrationdoneright} caractérise le fonctionnement de
-l'instruction \texttt{clflush} sur certains processeurs Intel mais a mis en évidence que le fonctionnement
-sur des systèmes à plusieurs sockets était significativement différent.
+\TODO{Réécrire parce qu'il fallait juste que je démarre mais ça ne ressemblait à rien}
 
 \section{Introduction}
 
@@ -61,7 +51,7 @@ basés sur une mémoire SRAM, plus petite mais plus rapide.
 La politique de fonctionnement du cache cherche à minimiser le nombre d'accès à la mémoire DRAM.
 Une politique optimale serait donc de charger en priorité les données qui vont être utilisées dans
 un futur proche et d'évicter les données qui seront utilisées dans plus longtemps ou qui ne sont
-plus utiles. Comme on ne peut pas aissément déterminer quels seront les prochains accès mémoire,
+plus utiles. Comme on ne peut pas aisément déterminer quels seront les prochains accès mémoire,
 une heuristique de type LRU (Least Recently Used) est généralement mise en place pour déterminer
 les données à évicter.
 
@@ -71,7 +61,7 @@ les données à évicter.
   \caption{Différents niveaux de cache}
 \end{figure}
 
-Les processeurs que nous étudions disposent de 3 niveaux de cache : L1, L2, L3. À l'instar du L1 et L2,
+Les processeurs que nous étudions disposent de 3 niveaux de cache : L1, L2, L3. À la différence du L1 et L2,
 le cache L3 est partagé et inclusif
 \footnote{Cela dépend de l'architecture considérée : à partir de SkyLake, le L3 n'est plus inclusif}:
 le L3 est le même pour tous les coeurs,
@@ -79,8 +69,8 @@ alors que chaque coeur dispose de son L1 et son L2 ; toutes les données contenu
 moins un L1 ou un L2 sont aussi dans le L3
 
 Si le L3 est partagé, il n'est cependant pas situé en un seul endroit dans le CPU
-mais est séparé en différentes slices : des tranches de mémoire accolées chacune à un coeur.
-\footnote{\TODO{c'est plus compliqué sur les nouveaux proc}}
+mais est séparé en différentes slices : des tranches de mémoire accolées chacune à un coeur. Dans le modèle
+étudié, chaque coeur a exactement une slice\footnote{\TODO{c'est plus compliqué sur les nouveaux proc}}.
 
 \begin{figure}[ht]
   \centering
@@ -89,12 +79,12 @@ mais est séparé en différentes slices : des tranches de mémoire accolées ch
 \end{figure}
 
 Lorsqu'un coeur accède à une donnée qui n'est pas encore dans son cache, c'est toute la ligne de mémoire:
-les \TODO{x bits} environnants qui sont chargés dans son L1 ou L2. Comme le L3 est inclusif,
+les 64 bytes environnants (généralement) qui sont chargés dans son L1 ou L2. Comme le L3 est inclusif,
 la ligne y est chargée également. Une fonction de hachage non documentée prenant en entrée
 l'adresse mémoire de la donnée permet de choisir dans quelle slice du L3 celle-ci sera stockée.
 Le travail de Clémentine Maurice et al.\cite{slice-reverse} a permis de révéler cette fonction.
 
-\subsection{\TODO{cache coherency protocols}}
+\subsection{\TODO{Protocoles de cohérence de cache}}
 
 \subsection{Attaques par canaux auxiliaires}
 
@@ -112,13 +102,14 @@ Lorsque l'instruction \texttt{clflush} est exécutée, l'adresse et la ligne de
 Si des modifications avaient eu lieu, les modifications sont réécrites dans la mémoire DRAM.
 
 L'instruction \texttt{clflush} est accessible à tout utilisateur non privilégié sur
-les adresses mémoires auxquelles il a accès.
+les adresses mémoires \TODO{auxquelles il a accès}.
 
 \subsubsection{Flush+Flush}
 
+\TODO{2.2 \& 2.3 of \cite{flushflush}}
+
 Le temps d'exécution de l'instruction \texttt{clflush} dépendant de l'état de cohérence de la ligne
 de cache concernée, la connaissance de son temps d'exécution permet de déterminer dans quel état était la ligne.
-La différence la plus importante étant entre un \textit{hit} dans l'état exclusif (E) et un \textit{miss} (I),
 Flush+Flush \cite{flushflush} propose la méthode suivante :
 
 \begin{algorithm}[ht]
@@ -132,35 +123,46 @@ Flush+Flush \cite{flushflush} propose la méthode suivante :
   $total\_time \gets rdtsc() - t$\;
 \end{algorithm}
 
-Les avantages de cette méthode par rapport à Prime+Probe,
-Evict+Time ou encore Flush+Reload\TODO{[?]} sont multiples :
-aucun accès mémoire n'est réalisé pour surveiller l'adresse, ce qui rend les méthodes de détection inefficaces ;
-comme aucun accès mémoire n'est réalisé, l'effet sur le CPU et la durée d'une passe de surveillance est
-bien plus faible \TODO{de combien ?}.
+Les avantages de cette méthode par rapport à Prime+Probe ou Flush+Reload\TODO{[?]} sont multiples :
+\begin{itemize}
+  \item Aucun accès mémoire n'est réalisé pour surveiller l'adresse, ce qui rend les méthodes de détection
+    qui comptent le nombre de \textit{cache miss} inefficaces.
+    \cite{flushflush} propose des solutions de détection alternatives mais montre qu'elles auraient toutes
+    un coût bien trop élevé.
+  \item Comme aucun accès mémoire n'est réalisé, la vitesse de traitement et le débit de données qui peuvent
+  être extraites est bien plus élevé : $496$KB/s contre $298$KB/s pour Flush+Reload
 
-Similairement à ces autres méthodes, Flush+Flush peut extraire des données du fonctionnement des autres processus
-en regardant les accès mémoires faits dans les bibliothèques partagés, qui occupent les mêmes zones de la mémoire physique pour différents processus.
-\TODO{[?]} propose par exemple de récupérer les bits d'une clé privée \TODO{ssh ? générique ? RSA ?}
-en regardant les zones mémoire accédées dans la bibliothèque partagée \TODO{\texttt{libcrypto.so}} pendant le
-chiffrement de données.
-La possibilité de créer un enregistreur de frappe
-(\textit{keylogger}) en se basant sur les mappages de disposition de clavier dans
-\TODO{\texttt{libclaviergtk.so}} est également mise en oeuvre dans \TODO{[?]}.
+  \TODO{what are packets in \cite{flushflush} ?}
+\end{itemize}
+
+Similairement à ces autres méthodes, Flush+Flush peut extraire des données du fonctionnement des
+autres processus en regardant les accès mémoires faits dans les bibliothèques partagés,
+qui occupent les mêmes zones de la mémoire physique pour différents processus.
+\cite{cryptoeprint:2014/140} propose par exemple de récupérer le nonce d'une clé OpenSSL avec Flush+Reload
+en regardant les zones mémoire accédées pendant le chiffrement de données.
+La possibilité de créer un enregistreur de frappe (\textit{keylogger}) en se basant sur
+les pages accédées dans la librairie \textsc{Gtk} \texttt{libgdk.so} est également
+mise en oeuvre dans \cite{cachetemplateattacks}.
 
 \subsubsection{Améliorer la précision}
 \TODO{changer le titre}
 
-Là où Flush+Reload choisit de mesurer le temps pour charger à nouveau une adresse en mémoire, Flush+Flush choisit
-de mesurer le temps nécessaire pour l'évincer : la différence entre
-un \textit{cache hit} et un \textit{cache miss} est alors beaucoup moins perceptible. De bons résultats ont
-toutefois été obtenus avec une calibration \TODO{en fonction des informations
-\textit{coeur attaquant, coeur victime, slice de L3}}\cite{flushflush}. Guillaume DIDIER et al. proposent
-une autre approche : comprendre le trajet des messages échangés dans le CPU dans le cas d'un \textit{hit} ou
-d'un \textit{miss}, afin d'en déduire \TODO{des fonctions mathématiques plus légères et claires qu'une calibration
-intensive}\cite{calibrationdoneright}.
+Là où Flush+Reload choisit de mesurer le temps pour charger à nouveau une adresse en mémoire,
+Flush+Flush choisit de mesurer le temps nécessaire pour l'évincer : la différence entre
+un \textit{cache hit} et un \textit{cache miss} est alors beaucoup moins perceptible (moins de 12 cycles de CPU).
+De bons résultats\cite{flushflush} ont toutefois été obtenus en appliquant un seuil global.
 
-Ce travail s'était intéressé à certains processeurs Intel de micro-architecture \TODO{? et ?}, mais a révélé
-que les résultats seraient plus complexes sur des systèmes à plusieurs \textit{socket}.
+Guillaume DIDIER et al.\cite{calibrationdoneright} proposent une autre approche :
+comprendre le trajet des messages échangés dans le
+CPU dans le cas d'un \textit{hit} ou d'un \textit{miss}, afin d'en déduire un modèle mathématique
+qui fera office de calibration et permettra de meilleurs résultats en connaissant le coeur attaquant, victime,
+voire la slice où est une ligne de cache. Cela permet également de trouver les paramètres avec la plus faible
+incertitude quant aux résultats et de les ajuster en conséquence si possible (le coeur attaquant est facilement
+controllable par exemple).
+
+Ce travail s'était intéressé à certains processeurs Intel de micro-architectures \textit{Coffee Lake} et
+\textit{Haswell} à une seule \textit{socket}, mais a révélé que les résultats seraient bien plus complexes
+sur des systèmes à plusieurs \textit{socket}.
 
 \section{\TODO{Systèmes multi-socket}}
 \TODO{trouver un titre approprié}
@@ -170,9 +172,13 @@ que les résultats seraient plus complexes sur des systèmes à plusieurs \texti
 
 \subsection{\TODO{Analyse des résultats}}
 
+\textbf{Aknowledgements} Experiments presented in this paper were carried out using the Grid'5000 testbed,
+supported by a scientific interest group hosted by Inria and including \textsc{Cnrs},
+\textsc{Renater} and several Universities as well as other organizations (see \url{https://www.grid5000.fr} ).
+
 \bibliographystyle{plain}
 \bibliography{refs}
 
-Experiments presented in this paper were carried out using the Grid'5000 testbed, supported by a scientific interest group hosted by Inria and including \textsc{Cnrs}, \textsc{Renater} and several Universities as well as other organizations (see \url{https://www.grid5000.fr} ).
+\TODO{\textit{Recovering OpenSSL ECDSA nonces using the FLUSH+RELOAD cache side-channel attack} lu transversalement, citable quand-même ?}
 
 \end{document}

refs.bib

@@ -59,3 +59,26 @@
   year={2023},
   url={https://www.intel.fr/content/www/fr/fr/content-details/774500/intel-64-and-ia-32-architectures-software-developer-s-manual-volume-4-model-specific-registers.html}
 }
+
+@inproceedings{cachetemplateattacks,
+  author={Daniel Gruss and Raphael Spreitzer and Stefan Mangard},
+  title={Cache Template Attacks: Automating Attacks on Inclusive {Last-Level} Caches},
+  booktitle={24th USENIX Security Symposium (USENIX Security 15)},
+  year={2015},
+  isbn={978-1-939133-11-3},
+  address={Washington, D.C.},
+  pages={897--912},
+  url={https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/gruss},
+  publisher={USENIX Association},
+  month=aug
+}
+
+
+@misc{cryptoeprint:2014/140,
+  author={Yuval Yarom and Naomi Benger},
+  title={Recovering {OpenSSL} {ECDSA} Nonces Using the {FLUSH}+{RELOAD} Cache Side-channel Attack},
+  howpublished={Cryptology ePrint Archive, Paper 2014/140},
+  year={2014},
+  note={\url{https://eprint.iacr.org/2014/140}},
+  url={https://eprint.iacr.org/2014/140}
+}