[gull] Above Meltdown & Spectre

[Yves Martin]

On Mon, 2018-01-15 at 12:25 +0100, Marc Mongenet wrote:
> Bonjour
> 
> Le 14 janvier 2018 à 21:46, Yves Martin <ymartin59 at free.fr> a écrit :
> >   Bonjour
> > 
> > De ce que j'ai compris, la défaillance vient du fait que
> > l'exécution
> > anticipée se fait sans appliquer les contrôles de sécurité sur les
> > accès mémoire.
> 
> Les contrôles sont effectués, sinon il n'aurait pas fallu tant de
> temps
> pour trouver les problèmes. Mais ils sont effectués après exécution
> spéculative. Or l'exécution spéculative, comme toute exécution,
> utilise les mémoires caches. Et elle peut donc causer le chargement
> ou l'invalidation de lignes de de cache. En mesurant le temps d'accès
> à des adresses bien choisies après l'exécution spéculative, il est
> possible de reconstruire les données sur lesquelles il y a eu
> spéculation.

Ce problème de mesure des temps d'accès et d'exécution est connu depuis
longtemps notamment en cryptanalyse lors des tests de robustesse des
algorithmes sur des cartes à puce, avec en plus surveillance de la
consommation... La nouveauté est d'appliquer cette technique
d'inspection à un CPU classique.

De mon point de vue, si les contrôles de sécurité sont appliquées avant
les instructions même en exécution spéculative, les données en mémoire
n'entreront plus dans le cache - puisque l'exécution spéculative est
interrompue par exception/interruption.

Je pense au microcode pour tenter de palier ces attaques car j'ai
entendu parlé de problèmes de "fonderie" de lots de CPUs qui ont été
contournés en désactivant par microcode les parties défectueuses, donc
avec des performances moindres... Ces CPUs sont vendus au rabais mais
cette méthode évite une perte sèche.

-- 
Yves Martin