rapport-stage/main.tex

\documentclass[10pt]{article}

% import des packages nécessaires
\usepackage[margin=1.2in]{geometry}
\usepackage[french]{babel}
\usepackage[T1]{fontenc}
\usepackage{algorithm2e}
\usepackage{csquotes}
\usepackage{hyperref}
\usepackage{graphicx}
\usepackage{amsmath}
\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 \textsc{Taran}\\
Laboratoire \textsc{Irisa}\\
Université de \textsc{Rennes} 1}

\date{3 Juin 2024 - 12 Juillet 2024}

% quelques macros
\newcommand{\TODO}[1]{{\color{red}#1}}

% le document lui-même
\begin{document}
\maketitle
\tableofcontents
\newpage


\section{\TODO{Abstract}}

\TODO{Réécrire parce qu'il fallait juste que je démarre mais ça ne ressemblait à rien}

\section{Introduction}

\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 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 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.

\begin{figure}[ht]
  \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. À 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,
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 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. 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
  \includegraphics[width=0.4\textwidth]{broadwell-die-shot}
  \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 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{Protocoles de cohérence de cache}}

\subsection{Attaques par canaux auxiliaires}

\subsubsection{L'instruction \texttt{clflush}}

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
  hierarchy, and it is broadcast throughout the cache coherency domain.
\end{displayquote}

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 \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.
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 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

  \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 (moins de 12 cycles de CPU).
De bons résultats\cite{flushflush} ont toutefois été obtenus en appliquant un seuil global.

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é}


\subsection{\TODO{Conduite des expériences}}

\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}

\TODO{\textit{Recovering OpenSSL ECDSA nonces using the FLUSH+RELOAD cache side-channel attack} lu transversalement, citable quand-même ?}

\end{document}