diff --git a/main.tex b/main.tex index eca4264..193a387 100644 --- a/main.tex +++ b/main.tex @@ -4,6 +4,7 @@ \usepackage[margin=1.2in]{geometry} \usepackage[french]{babel} \usepackage[T1]{fontenc} +\usepackage{algorithm2e} \usepackage{csquotes} \usepackage{hyperref} \usepackage{graphicx} @@ -11,16 +12,18 @@ \usepackage{xcolor} \usepackage{syntax} +% configuration des packages \hypersetup{colorlinks=false} \graphicspath{ {./figs/} } +\SetKwComment{Comment}{/* }{ */} % titre \title{Caractérisation de l’instruction \texttt{clflush} sur systèmes multi-socket} \author{\textsc{Augustin LUCAS}\\ENS de Lyon\\ \\Encadré par :\\ \textsc{Guillaume DIDIER}, \textsc{Angeliki KRITIKAKOU}\\ -Équipe TARAN\\ -Laboratoire IRISA\\ -RENNES} +Équipe \textsc{Taran}\\ +Laboratoire \textsc{Irisa}\\ +Université de \textsc{Rennes} 1} \date{3 Juin 2024 - 12 Juillet 2024} @@ -62,7 +65,7 @@ plus utiles. Comme on ne peut pas aissément déterminer quels seront les procha 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] +\begin{figure}[ht] \centering \includegraphics[width=0.3\textwidth]{cachehierarchy} \caption{Différents niveaux de cache} @@ -79,7 +82,7 @@ Si le L3 est partagé, il n'est cependant pas situé en un seul endroit dans le 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] +\begin{figure}[ht] \centering \includegraphics[width=0.4\textwidth]{broadwell-die-shot} \caption{Broadwell Deca-Core die shot by Intel - annotated by Wikichip \cite{broadwelldieshot}} @@ -89,7 +92,7 @@ Lorsqu'un coeur accède à une donnée qui n'est pas encore dans son cache, c'es 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. +Le travail de Clémentine Maurice et al.\cite{slice-reverse} a permis de révéler cette fonction. \subsection{\TODO{cache coherency protocols}} @@ -97,7 +100,7 @@ Le travail de Clémentine Maurice et al.\cite{slice-reverse} a permis de \TODO{d \subsubsection{L'instruction \texttt{clflush}} -D'après le manuel Intel\cite{intel-man}: +D'après le manuel Intel\cite{intel-man-vol1}: \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 @@ -111,13 +114,58 @@ Si des modifications avaient eu lieu, les modifications sont réécrites dans la 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}} +\subsubsection{Flush+Flush} +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] + \caption{Flush+Flush}\label{alg:flushflush} + \KwData{$x$ : addresse à surveiller} + \KwResult{Y a t-il eu un accès à $x$ ?} + $clflush(x)$ \Comment*[l]{$x$ est dans l'état $I$} + $sleep(n)$ \Comment*[l]{$x$ passe dans l'état $E$ si un coeur y accède} + $t \gets rdtsc()$\; + $clflush(x)$\; + $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 ?}. + +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{[?]}. + +\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}. + +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}. \section{\TODO{Systèmes multi-socket}} \TODO{trouver un titre approprié} + \subsection{\TODO{Conduite des expériences}} \subsection{\TODO{Analyse des résultats}} diff --git a/refs.bib b/refs.bib index dfc88ea..7709cb8 100644 --- a/refs.bib +++ b/refs.bib @@ -46,3 +46,16 @@ series = {RAID 2015} } +@book{intel-man-vol1, + author={Intel Corporation}, + title={Intel 64 and IA-32 Architecture Optimization Reference Manual}, + year={2024}, + url={https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf} +} + +@book{intel-man-vol4, + author={Intel Corporation}, + title={Intel 64 and IA-32 Architectures Software Developer’s Manual}, + 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} +}