Add clflush paragraph

.gitignore

@@ -5,5 +5,6 @@
 *.log
 *.run.xml
 *.toc
+*.out
 
 *.pdf

Makefile

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

main.tex

@@ -1,15 +1,15 @@
 \documentclass[10pt]{article}
 
 % import des packages nécessaires
+\usepackage[margin=1.2in]{geometry}
+\usepackage[french]{babel}
 \usepackage[T1]{fontenc}
-\usepackage{xcolor}
-\usepackage[french]{babel}
-\usepackage{syntax}
-\usepackage{listings}
-\usepackage{amsmath}
-\usepackage[french]{babel}
+\usepackage{csquotes}
 \usepackage{hyperref}
 \usepackage{graphicx}
+\usepackage{amsmath}
+\usepackage{xcolor}
+\usepackage{syntax}
 
 \hypersetup{colorlinks=false}
 \graphicspath{ {./figs/} }
@@ -34,7 +34,7 @@ RENNES}
 \newpage
 
 
-\section{Abstract}
+\section{\TODO{Abstract}}
 
 \TODO{Réécrire parce qu'il fallait juste que je démarre mais ça ne ressemble à rien}
 
@@ -53,24 +53,31 @@ sur des systèmes à plusieurs sockets était significativement différent.
 \subsection{Hiérarchie de cache}
 
 La mémoire DRAM d'un ordinateur est lente comparée à la fréquence du CPU. Le CPU dispose donc de caches,
-basés sur une mémoire SRAM, plus petite mais plus rapide. La politique de fonctionnement du cache
-cherche à minimiser le temps d'exécution qui est bloqué par les accès à la mémoire. 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 déterminer cela aisément, une heuristique de type LRU (Least Recently Used) est
-généralement mise en place pour déterminer les données à évicter.
+basés sur une mémoire SRAM, plus petite mais plus rapide.
 
-\begin{center}
-  \includegraphics{cachehierarchy}
-\end{center}
+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,
+une heuristique de type LRU (Least Recently Used) est généralement mise en place pour déterminer
+les données à évicter.
+
+\begin{figure}[h]
+  \centering
+  \includegraphics[width=0.3\textwidth]{cachehierarchy}
+  \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,
-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,
+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,
 alors que chaque coeur dispose de son L1 et son L2 ; toutes les données contenues dans au
 moins un L1 ou un L2 sont aussi dans le L3
 
-Si le L3 est partagé, il n'est cependant pas composé d'un unique \TODO{espace mémoire} 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}}.
+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}}
 
 \begin{figure}[h]
   \centering
@@ -78,16 +85,42 @@ Si le L3 est partagé, il n'est cependant pas composé d'un unique \TODO{espace
   \caption{Broadwell Deca-Core die shot by Intel - annotated by Wikichip \cite{broadwelldieshot}}
 \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,
+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 \TODO{dévoiler} cette fonction.
+
+\subsection{\TODO{cache coherency protocols}}
+
+\subsection{Attaques par canaux auxiliaires}
+
 \subsubsection{L'instruction \texttt{clflush}}
 
-\subsection{Attaques par canaux auxiliaires: Flush+Flush}
+D'après le manuel Intel\cite{intel-man}:
+\begin{displayquote}
+  (flush cache line) instruction writes and invalidates the cache line associated
+  with a specified linear address. The invalidation is for all levels of the processor’s cache
+  hierarchy, and it is broadcast throughout the cache coherency domain.
+\end{displayquote}
 
-\section{Systèmes multi-socket}
+Lorsque l'instruction \texttt{clflush} est exécutée, l'adresse et la ligne de cache associée sont
+évincés de tous les caches L1, L2 et L3 où elles se trouvaient possiblement.
+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.
+
+\subsubsection{\TODO{Flush+Flush}}
+
+
+
+\section{\TODO{Systèmes multi-socket}}
 \TODO{trouver un titre approprié}
 
-\subsection{Conduite des expériences}
+\subsection{\TODO{Conduite des expériences}}
 
-\subsection{Analyse des résultats}
+\subsection{\TODO{Analyse des résultats}}
 
 \bibliographystyle{plain}
 \bibliography{refs}

refs.bib

@@ -26,3 +26,23 @@
   title={Broadwell - Microarchitectures - Intel - WikiChip (2024)},
   url={https://en.wikichip.org/wiki/intel/microarchitectures/broadwell_(client)#Deca-core_Broadwell},
 }
+
+
+@inproceedings{slice-reverse,
+  author = {Maurice, Cl\'{e}mentine and Scouarnec, Nicolas and Neumann, Christoph and Heen, Olivier and Francillon, Aur\'{e}lien},
+  title = {Reverse Engineering Intel Last-Level Cache Complex Addressing Using Performance Counters},
+  year = {2015},
+  isbn = {9783319263618},
+  publisher = {Springer-Verlag},
+  address = {Berlin, Heidelberg},
+  url = {https://doi.org/10.1007/978-3-319-26362-5_3},
+  doi = {10.1007/978-3-319-26362-5_3},
+  abstract = {Cache attacks, which exploit differences in timing to perform covert or side channels, are now well understood. Recent works leverage the last level cache to perform cache attacks across cores. This cache is split in slices, with one slice per core. While predicting the slices used by an address is simple in older processors, recent processors are using an undocumented technique called complex addressing. This renders some attacks more difficult and makes other attacks impossible, because of the loss of precision in the prediction of cache collisions.In this paper, we build an automatic and generic method for reverse engineering Intel's last-level cache complex addressing, consequently rendering the class of cache attacks highly practical. Our method relies on CPU hardware performance counters to determine the cache slice an address is mapped to. We show that our method gives a more precise description of the complex addressing function than previous work. We validated our method by reversing the complex addressing functions on a diverse set of Intel processors. This set encompasses Sandy Bridge, Ivy Bridge and Haswell micro-architectures, with different number of cores, for mobile and server ranges of processors. We show the correctness of our function by building a covert channel. Finally, we discuss how other attacks benefit from knowing the complex addressing of a cache, such as sandboxed rowhammer.},
+  booktitle = {Proceedings of the 18th International Symposium on Research in Attacks, Intrusions, and Defenses - Volume 9404},
+  pages = {48–65},
+  numpages = {18},
+  keywords = {Side channel, Reverse engineering, Last level cache, Cross-Core, Covert channel, Complex addressing},
+  location = {Kyoto, Japan},
+  series = {RAID 2015}
+}
+