l3-ENSL/rapport-stage
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Add Flush+Reload

Browse Source
This commit is contained in:
augustin64 2024-07-12 14:45:38 +02:00
parent f78ad5147b
commit 668d70bc18
2 changed files with 31 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
figs/low-core-count.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 173 KiB

38
main.tex
View File

@ -109,15 +109,39 @@ 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{\TODO{Flush+Reload}}
\subsubsection{Flush+Flush}
\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 déterminer dans quel état était la ligne.
Flush+Flush \cite{flushflush} propose la méthode suivante :
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}
@ -130,7 +154,7 @@ Flush+Flush \cite{flushflush} propose la méthode suivante :
$total\_time \gets rdtsc() - t$\;
\end{algorithm}
Les avantages de cette méthode par rapport à Flush+Reload\cite{flushreload} sont multiples :
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.
@ -154,7 +178,7 @@ Similairement à ces autres méthodes, Flush+Flush peut extraire des données du
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} propose par exemple de récupérer
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