rapport-stage/main.tex

179 lines
8.3 KiB
TeX
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

\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 linstruction \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]{\textbf{\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 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.
\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 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}[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. À 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,
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.
\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 \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 révéler cette fonction.
\subsection{\TODO{cache coherency protocols}}
\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 processors 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 auxquelles il a accès.
\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}}
\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} ).
\end{document}