179 lines
8.3 KiB
TeX
179 lines
8.3 KiB
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]{\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 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 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}
|