jiegec/loongbleedPreuve de concept démontrant une fuite de données microarchitecturale dans les processeurs Loongson LA464/LA664 via les bits supérieurs non définis des registres vectoriels LASX, similaire à ZenBleed.
LoongBleed est une vulnérabilité matérielle, conceptuellement similaire à ZenBleed (CVE-2023-20593) — affectant les processeurs Loongson LA464/LA664 qui implémentent à la fois LSX (SIMD 128 bits) et LASX (SIMD 256 bits).
Sur LoongArch, les registres LSX $vr (128 bits) aliasent la moitié inférieure des registres LASX
$xr (256 bits). Les instructions LSX et les opérations de base en virgule flottante
sont uniquement définies pour opérer sur les 128 bits inférieurs (ou un sous-ensemble de ceux-ci) ; les
bits supérieurs du registre $xr correspondant sont indéfinis. Cependant, en raison
d'un défaut microarchitectural, ces opérations peuvent fuiter des données via les
128 bits supérieurs de $xr, exposant des données sensibles à travers les frontières de privilèges ou
entre les frères SMT.
Note sur la découverte indépendante — Le même défaut matériel sous-jacent a été découvert et publié indépendamment par des chercheurs du CISPA Helmholtz Center for Information Security sous le nom de LoongLeak (https://loongleakattack.com/), présenté à USENIX Security 2026 sous le titre « LoongLeak: Architectural Cross-Privilege-Boundary Data Leakage on LoongArch CPUs ». Notre travail a été développé indépendamment de l'équipe LoongLeak ; les deux groupes sont parvenus à la même conclusion : les processeurs Loongson LA464/LA664 fuientent des données via les bits supérieurs indéfinis des registres LASX
$xr. Notez que les instructions que nous utilisons pour déclencher la fuite ne sont pas identiques à celles rapportées dans l'article LoongLeak : notre PoC repose sur un ensemble différent de gadgets (vor.v,vld,fld.d,fld.s) pour reproduire le même défaut matériel sous-jacent. De plus, comme la fuite peut être déclenchée par de pures instructions registre-registre telles quevor.v(aucun chargement mémoire impliqué), notre analyse suggère que la cause racine est probablement la réutilisation de registres physiques : les bits supérieurs d'un registre physique réutilisé ne sont pas effacés, fuitant des données résiduelles d'un occupant précédent du registre. Cela diffère de l'analyse de l'article LoongLeak, qui attribue les données fuitées au cache de données L1.
La preuve de concept fonctionne comme suit :
$xrN via xvld.xvst.Le PoC exécute ce gadget de manière répétée sur 16 registres vectoriels architecturaux
($xr0–$xr15) sur des threads épinglés à des cœurs physiques. Les valeurs non nulles qui
apparaissent après l'instruction indiquent que la microarchitecture a propagé des données
résiduelles ou inter-contextes dans l'état des registres architecturaux.
Le PoC prend en charge plusieurs instructions de test, sélectionnables via --gadget :
| Gadget | Instruction | Description | Fuit sur LA664 | Fuit sur LA464 |
|---|---|---|---|---|
vor | vor.v $vrN, $vrN, $vrN | OU bit à bit de $vrN avec lui-même | Oui | Non |
vld | vld $vrN, … | Chargement 128 bits depuis la mémoire vers $vrN | Oui | Oui |
fld.d | fld.d $fN, … | Chargement virgule flottante 64 bits vers $fN (alias des 64 bits inférieurs de $vrN) | Oui | Oui |
fld.s | fld.s $fN, … | Chargement virgule flottante 32 bits vers $fN (alias des 32 bits inférieurs de $vrN) | Oui | Oui |
Sur LA664, les quatre gadgets exposent la fuite, fuitant au maximum 192 bits par
vecteur. Sur LA464, vld, fld.d et fld.s fuitent (au maximum 224 bits par
vecteur) ; le gadget par défaut vor.v ne fuit pas sur LA464.
Usage: ./loongbleed_poc [OPTIONS]
Options:
-a, --all Launch one thread pinned to each physical core.
By default only thread on CPU 0 is launched.
-g, --gadget [vor|vld|fld.d|fld.s]
Use different instructions for testing.
-h, --help Show this help and exit.
# Single-thread mode on CPU 0
./run.sh
# Single-thread mode with vld gadget (required for LA464)
./run.sh --gadget vld
# All physical cores, default gadget
./run.sh -a
# All cores with fld.d gadget
./run.sh --all --gadget fld.d
Un thread victime traite des données sensibles sur un CPU logique tandis que le PoC sonde les registres sur son frère SMT. Le thread espion peut observer des fragments des données de la victime dans les bits supérieurs fuités.
# Terminal 1 — start LoongBleed on CPU 0
./run.sh
# Terminal 2 — victim workload on the SMT sibling (CPU 1)
while true; do numactl -C 1 sort < /etc/shadow > /dev/null; done
Pour une configuration automatisée, utilisez le script fourni :
./poc_la664.sh
Cela lance une charge de travail sort sur le CPU 1 (le frère SMT du CPU 0) et démarre
LoongBleed sur le CPU 0 avec le gadget par défaut.
Un thread victime traite des données sensibles sur un CPU tandis que le PoC sonde
les registres sur le même cœur. Nécessite --gadget vld car le gadget par défaut vor.v
ne fuit pas sur LA464.
# Terminal 1 — start LoongBleed on CPU 0
./run.sh --gadget vld
# Terminal 2 — victim workload on the same core
while true; do numactl -C 0 sort < /etc/shadow > /dev/null; done
Pour une configuration automatisée :
./poc_la464.sh
Cela lance une charge de travail sort sur le CPU 0 et démarre LoongBleed avec --gadget vld.
Le PoC est un programme C++ en un seul fichier sans dépendances externes.
g++ -std=c++11 -O2 -march=native -pthread -o loongbleed_poc loongbleed_poc.cpp
Ou utilisez le script fourni :
./run.sh
# or, on LA464:
./run.sh --gadget vld
Lorsqu'une fuite est détectée et que les octets fuités contiennent une séquence d'au moins 8 caractères ASCII imprimables contigus (0x20–0x7e), le PoC affiche :
[cpu 0] LEAK chunk=14 data=0x7461646e756f4620_6572617774666f53_0000000000000000_0000000000000000 ascii=............Software Foundat