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{footmisc}
\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-\ang{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}}
\newcommand{\ang}[1]{\emph{#1}} % texte anglais

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

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

\tableofcontents
\newpage


\section{Introduction}

\TODO{
  Points à aborder
  \begin{itemize}
    \item NUMA balancing
    \item Low Core Count, possibilité cores fantôme
    \item Pourquoi nombre de coeurs = puissance de 2 ?
  \end{itemize}
}

\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. Stocker en cache les éléments accédés
le plus fréquemment permet donc de réduire le nomre d'appels à la mémoire et donc le temps d'exécution.

Les processeurs que nous étudions disposent de 3 niveaux de cache : L1, L2, L3.
Chaque processeur possède, au premier niveau, un L1i (cache des instructions) et
un L1d (cache des données). Au second niveau, il possède un L2 qui contient potentiellement
des données et des instructions. Au dernier niveau, le L3 est partagé entre tous les coeurs de la
\ang{socket}, et celui-ci est inclusif de tous les caches de niveau inférieur : toute ligne
stockée dans le cache L1 ou L2 est également dans le L3.

Si le L3 est partagé, il n'est cependant pas situé en un seul endroit dans le CPU
mais est réparti en différentes \ang{slices} : des tranches de mémoire accolées chacune à un coeur. Dans le modèle
étudié, chaque coeur a exactement une \ang{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}}
  % L'espace vide l'est bien sur le die-shot, donc sûrement "Intel being stupid"
\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 octets 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 attribue à chaque adresse
physique une unique \ang{slice} dans laquelle elle peut être mise en cache.
Différents travaux\cite{slice-reverse, practicalTiming} ont permis de déterminer cette fonction.

\subsection{\TODO{Protocoles de cohérence de cache}}

\TODO{
  \begin{enumerate}
    \item Problème à résoudre
    \item Expliquer la solution par "directory"
    \item Expliquer le snooping
  \end{enumerate}
}

\subsection{Attaques par canaux auxiliaires}

\TODO{Expliquer le concept général}

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

D'après le manuel Intel\cite{intel-man-vol1}:
\begin{displayquote}
  \sffamily \emph{
    CLFLUSH (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, et cela dans tous les
\ang{sockets} du système. 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{Flush+Reload}

\TODO{2.2 \& 2.3 of \cite{flushflush}}

Le temps de chargement d'une donnée est largement influencé par sa présence en cache.
Mesurer le temps de chargement d'une adresse permet donc de déterminer aisément si la ligne de
cache associée était déjà présente en cache.

Flush+Reload\cite{flushreload} propose donc la méthode suivante:

\begin{algorithm}[ht]
  \caption{Flush+Reload}\label{alg:flushreload}
  \KwData{$x$ : addresse à surveiller}
  \KwResult{Y a t-il eu un accès à $x$ ?}
  $clflush(x)$ \Comment*[l]{$x$ n'est plus en cache}
  $sleep(n)$ \Comment*[l]{Si un coeur accède à $x$, $x$ est à nouveau dans le L3}
  $t \gets rdtsc()$\;
  $read(x)$\;
  $total\_time \gets rdtsc() - t$\;
\end{algorithm}

La différence entre le temps de lecture depuis le cache et depuis la DRAM étant conséquent,
cette méthode permet de déterminer avec un faible taux d'erreur si un accès a été fait à une adresse,
le grand nombre de \ang{reload} effectués par les \texttt{clflush} et \texttt{read} successifs est
cependant visible via des compteurs de performance et donc détectable,
et ne permet pas une haute fréquence d'observation.

\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 la même manière
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 unique coeur y accède en lecture}
  $t \gets rdtsc()$\;
  $clflush(x)$\;
  $total\_time \gets rdtsc() - t$\;
\end{algorithm}

Les avantages de cette méthode par rapport à Flush+Reload 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 \ang{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} ?
    $\rightarrow$ j'ai eu une réponse il faut que je regarde}

  \item Comme l'opération mesurée agit sur tous les caches du système et pas seulement sur ceux
      utilisés par l'attaquant, Flush+Flush peut opérer dans un système avec une
      hiérarchie de cache non inclusive. Ce qui est le cas des systèmes à deux
      \ang{sockets} notamment, alors que Flush+Reload nécessite de partager un cache en commun
      (le L3 par exemple).
\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.

Daniel Gruss et al.\cite{cachetemplateattacks} proposent 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.
Un enregistreur de frappe (\ang{keylogger}) basé sur
les pages accédées dans la librairie \textsc{Gtk} \texttt{libgdk.so} y est également mis en oeuvre.

\section{Motivation}

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 \ang{cache hit} et un \ang{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 \textsc{Didier} et Clémentine \textsc{Maurice}~\cite{calibrationdoneright}
proposent une autre approche : comprendre les messages échangés en fonction de l'état de cohérence
du cache ainsi que les autres sources de variabilité pour bien étalonner sur
l'ensemble des combinaisons pertinentes et choisir les bons seuils en fonction.
Ce travail s'était intéressé à certains processeurs Intel de micro-architectures \ang{Coffee Lake} et
\ang{Haswell} à une seule \ang{socket}, mais a révélé que les résultats seraient bien plus complexes
sur des systèmes à plusieurs \ang{sockets}.

\section{Organisation des expériences}

Les expériences ont été faites sur 6 machines différentes,
via la plateforme \href{https://www.grid5000.fr/}{Grid'5000} afin d'échantillonner au moins une machine
par processeur répondant aux critères suivants:
\begin{itemize}
  \item Processeur Intel ;
  \item Exactement 2 \ang{socket} ;
  \item Nombre de coeurs par \ang{socket} est une puissance de
    deux \footnote{\TODO{l'expliquer en amont et le rappeler ici}} ;
  \item Micro-architecture antérieure à SkyLake\footnote{Le L3 n'est plus inclusif
    sur les processeurs serveur à partir de SkyLake}
\end{itemize}

Les machines suivantes ont donc été utilisées\cite{g5k-nodes}

\begin{center}
  \begin{tabular}{|c||c|c|c|}
    \hline
    Nom & Nombre de coeurs & Processeur & Micro-architecture \\
    \hline
    rennes/roazhon11 & 16 & Xeon E5-2660 & Sandy Bridge \\
    rennes/roazhon12 & 16 & Xeon E5-2660 & Sandy Bridge \\
    rennes/parasilo & 16 & Xeon E5-2630 v3 & Haswell \\
    rennes/paravance & 16 & Xeon E5-2630 v3 & Haswell \\
    lyon/nova & 16 & Xeon E5-2620 v4 & Broadwell \\
    rennes/abacus2 & 16 & Xeon E5-2609 v4 & Broadwell \\
    \hline
  \end{tabular}
\end{center}

Le turbo a été désactivé sur toutes les machines.
La fréquence des coeurs fixée : à la fréquence minimale supportée par les processeurs ;
le mode performance ne donnant pas le même résultat que sur les machines \ang{Intel Core}.
Le \ang{NUMA balancing} a également été désactivé (à l'échelle du système),
ce qui peut se faire pour le processus courant sans
privilèges\footnote{\TODO{à vérifier ! voir les "À faire"}}.

Les fichiers de résultats bruts sont accessibles en ligne\cite{g5k-results}.

\section{Analyse des résultats}


\begin{figure}[ht]
  \centering
  \includegraphics[width=0.5\textwidth]{low-core-count}
  \caption{Topologie LCC Haswell EP d'après \cite{tuningXeon} \TODO{schéma à déplacer}}
\end{figure}

Les schémas de présentation d'Intel suggèrent une topologie en anneau, avec un CPU divisé en deux grandes parties.

Pour la numérotation des coeurs, les premiers tests semblent révéler une numérotation
suivant ce schéma\footnote{Il est possible que la numérotation soit en fait tournée à 180°. Comme nous
avons appliqué la même rotation aux \ang{slice}, cela n'affecterait que les positions respectives
du QPI et du \ang{Home Agent}}:

\begin{center}
  \begin{tabular}{|c|c|}
    \hline
    0 & 1 \\ \hline
    2 & 3 \\ \hline
    4 & 5 \\ \hline
    6 & 7 \\ \hline
  \end{tabular}
\end{center}

Pour simplifier les interprétations, nous les avons renumérotés de la sorte,
c'est la numérotation que nous utiliserons pour la suite:

\begin{center}
  \begin{tabular}{|c|c|}
    \hline
    0 & 7 \\ \hline
    1 & 6 \\ \hline
    2 & 5 \\ \hline
    3 & 4 \\ \hline
  \end{tabular}
\end{center}


Pour trouver la numérotation des \ang{slices}, deux méthodes sont possibles:
\begin{itemize}
  \item Utiliser les compteurs de performance pour déterminer la \ang{slice} d'une adresse. Cela nécessite
    de lire les MSR correspondants donc d'avoir un accès \ang{root}. Nous avons suivi cette méthode
    afin d'être sûr que les numéros de \ang{slice} correspondent aux numéros de coeurs ;
  \item Utiliser la fonction de hachage (linéaire)\cite{slice-reverse} pour
    déterminer la \ang{slice} de chaque adresse. Comme la
    fonction est appliquée sur l'adresse virtuelle et non pas physique, l'ordre des \ang{slices} n'est pas le
    bon mais deux adresses sont envoyées dans la même \ang{slice} uniquement si elles le sont réellement.
    \TODO{clarifier, le côté math est mal expliqué}

    Il serait envisageable de donner une méthode permettant de réordonner automatiquement les \ang{slices},
    et donc d'exploiter ceci depuis un utilisateur non privilégié
    \TODO{à réécrire aussi}
\end{itemize}


\subsection{Topologie Miss}

\TODO{graphiques comparaison prédiction/réel}

\TODO{Je ne sais plus, en enlevant $S_R$,
est-ce que le modèle marchait bien avec socket(A) = socket(V) ?}

Les résultats obtenus quand le \ang{socket} attaquant et victime diffèrent suggèrent l'échange des messages suivant lors d'un \texttt{clflush} qui provoque un \ang{cache miss}:
\begin{enumerate}
  \item Le coeur attaquant contacte la \ang{slice} locale suivant \ref{figs:topology-miss}.
  \item La \ang{slice} locale contacte la \ang{slice} distante en passant par le QPI.
    Le trajet de la \ang{slice} locale au QPI se fait dans le sens horaire,
    celui du QPI à la \ang{slice} distante dans le sens anti-horaire.
  \item Si le \ang{Home Agent} distant doit être contacté, cela se fait à ce moment, en faisant
    un tour complet de la \ang{socket} pour revenir à la \ang{slice} distante.
    Nous n'avons effectivement pas trouvé d'élément permettant de montrer un trajet différent.
  \item Le chemin est parcouru à l'envers pour repasser par la \ang{slice} locale jusqu'au coeur attaquant
\end{enumerate}

\TODO{À quel point faut-il justifier ce qui est avancé ici ? La progression qui suggère le 2.
vient du \texttt{optimize.curve\_fit} et affichait qqchose d'étrange (les coeurs 2 par 2).
J'imagine que c'est toujours bon à préciser}

\begin{figure}[ht]
  \centering
  \rotatebox{270}{
    \includegraphics[width=0.7\textwidth]{topology-miss}
  }
  \caption{\TODO{schéma propre}}
  \label{figs:topology-miss}
\end{figure}

Ainsi, le chemin privilégié pour le trajet coeur attaquant - \ang{slice} locale serait assez proche du plus court, mais tenterait de limiter les passages
par le \ang{Home Agent} possiblement pour éviter de ralentir les opérations qui ont besoin de
passer par lui.

\subsection{\TODO{Topologie Hit}}


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

%\nocite{*}
\bibliographystyle{plain}
\bibliography{refs}

\section{À faire pour continuer le stage}

\TODO{rédiger mieux qu'une liste}
\begin{itemize}
  \item vérifier que \texttt{numactl} permet de verrouiller les pages "partagées"
  \item modèle hit : coût des sauts $A \rightarrow S$ cohérent avec $S_L \rightarrow S_R$ ?
  \item \TODO{en plottant A=S=V pour toutes les valeurs possibles, ça ne montrait pas de preuve
    du trajet \ang{slice}\_l-\ang{slice}\_r}
\end{itemize}

\TODO{Faire un passage sur le code : qu'est-ce que j'ai apporté,
qu'est-ce qui était déjà fait. Où le trouver}

\TODO{Passage sur le labo, l'équipe, l'ambiance}

\end{document}