GPUHammer → GPUBreach → GPUThor: Το Rowhammer σκότωσε την εμπιστοσύνη στις GPUs

01Γιατί αυτό πρέπει να σε ξυπνήσει

Ολόκληρη η βιομηχανία του AI τρέχει πάνω σε shared GPUs: cloud, πανεπιστήμια, ερευνητικά labs, MIG partitions, containers στην ίδια φυσική κάρτα. Η de facto υπόθεση ήταν πάντα η ίδια: «οι εφαρμογές είναι απομονωμένες· ο γείτονας δεν αγγίζει τα δικά μου δεδομένα».

Τρία διαδοχικά papers από το Πανεπιστήμιο του Τορόντο έσπασαν αυτή την υπόθεση σε τρία βήματα — το καθένα απαξίωσε και τη λύση του προηγούμενου:

• GPUHammer (USENIX Security 2025) — πρώτο Rowhammer σε GPU: καταστρέφει μοντέλα με ένα bit-flip.
• GPUBreach (IEEE S&P 2026) — το ίδιο primitive φτάνει σε root shell στον CPU, ακόμα και με IOMMU ενεργό.
• GPUThor (ACM CCS 2026, disclosure 25 Αυγούστου 2026) — εξουδετερώνει και το ECC, τη «λύση» που πρότεινε η NVIDIA για τα δύο πρώτα.

02Rowhammer σε 60 δευτερόλεπτα

Η DRAM είναι πυκνά τοποθετημένες «κυψέλες» σε σειρές (rows). Όταν προσπελάσεις μια σειρά εκατοντάδες χιλιάδες φορές πολύ γρήγορα, η ηλεκτρική διαρροή «χτυπάει» τις γειτονικές σειρές — και ένα 0 γίνεται 1, ή αντιστρόφως. Δεν είναι σφάλμα λογισμικού: είναι φυσική του πυριτίου.

Σε CPUs το γνωρίζουμε από το 2014 (Drammer, Throwhammer, Blacksmith…). Στις GPUs όλοι πίστευαν ότι δεν είναι πρακτικό: οι χάρτες μνήμης είναι ιδιόκτητοι, η καθυστέρηση μεγαλύτερη, το refresh πιο συχνό, και υπάρχουν κρυφές άμυνες. Η ομάδα του Τορόντο έλυσε και τα τρία — ανακατασκευάζοντας τους χάρτες των banks, αξιοποιώντας τον GPU parallelism και παρακάμπτοντας τα in-DRAM φίλτρα (TRR).

03GPUHammer — το πρώτο bit-flip σε GPU

Πώς το έφτιαξαν

• Αντίστροφη μηχανική των μη-τεκμηριωμένων mappings φυσικής μνήμης → banks/rows.
• Πολλαπλά warps «σφυροκοπούν» συγχρονισμένα με το refresh (≈500.000 ενεργοποιήσεις ανά παράθυρο).
• Παρακάμπτουν τα ατεκμηρίωτα in-DRAM TRR του GDDR6 με n-sided (n=8…24) «δολώματα».

Δοκιμάστηκε σε NVIDIA RTX A6000 (48GB GDDR6) και σε RTX 3060 (12GB GDDR6), όπου η ομάδα κατέγραψε έως 1.171 bit-flips. Απάντηση NVIDIA: «ενεργοποιήστε ECC». Ο υπόλοιπος κόσμος πίστεψε ότι το θέμα είχε κλείσει.

04GPUBreach — από GPU bit-flip σε root shell

Η επίθεση «φθείρει» τα page tables της GPU (PTEs) με bit-flips, ανακατευθύνοντας τη GPU σε περιοχές μνήμης του CPU. Τα υφιστάμενα memory-safety λάθη του driver ολοκληρώνουν το άλμα. Δηλαδή: ένας χρήστης χωρίς προνόμια, σε ένα shared GPU, τελειώνει με πλήρη έλεγχο της μηχανής.

05GPUThor — το ECC έπεσε (25 Αυγούστου 2026)

Το κρίσιμο σημείο: το SecDED ECC που η NVIDIA είχε προτείνει ως «λύση» διορθώνει μόνο single-bit. Το GPUThor παράγει double- και triple-bit errors μέσα στο ίδιο ECC chunk — το ECC τα ανιχνεύει αλλά δεν τα διορθώνει, και στο triple-bit δεν τα ανιχνεύει καν (σιωπηλή διαφθορά δεδομένων).

• DoS: σε A6000 με ECC, ένα DUE ≈ κάθε 2 ώρες → GPU reset + τερματισμός όλων των workloads. Σε επανάληψη: η κάρτα επισημαίνεται για αντικατάσταση.
• Root: corruption των GPU page tables δίνει σε ένα unprivileged CUDA πρόγραμμα αυθαίρετη πρόσβαση σε μνήμη — και root shell στον host.

06Exposure-checker: πόσο εκτεθειμένη είναι η GPU σου;

Διάλεξε το μοντέλο σου. Η αξιολόγηση βασίζεται στα δημοσιευμένα ευρήματα GPUHammer / GPUBreach / GPUThor (έως 27 Αυγούστου 2026) — δεν εκτελεί επίθεση, μόνο χαρτογραφεί την έκθεση από τον τύπο μνήμης, την αναφορά σε έρευνες και την υποστήριξη ECC.

07Ποια μοντέλα κινδυνεύουν πραγματικά

* «Χαμηλός» σημαίνει: δεν παρατηρήθηκε με τα tested patterns μέχρι σήμερα — όχι «αποδεδειγμένα ασφαλές». Οι ερευνητές τονίζουν ότι δεν υπάρχει (ακόμη) αρχιτεκτονική εγγύηση· τα HBM3e/GDDR7 με on-die ECC μπορούν να γίνουν ευάλωτα αν προκύψουν multi-bit flips.

08Τι κάνεις πραγματικά — σήμερα

Δεν υπάρχει patch. Η ρίζα είναι στο πυρίτιο. Αλλά υπάρχει διατεταγμένη άμυνα — με τη σωστή σειρά προτεραιότητας:

• Μην συν-τοποθετείς untrusted workloads στην ίδια φυσική GPU. Η co-tenancy είναι ο πολλαπλασιαστής κινδύνου. Στο cloud: ζήτα αποκλειστικά instances ή dedicate GPUs.
• Κράτα το SYS-ECC ενεργό. Δεν αρκεί πλέον από μόνο του, αλλά ανεβάζει τον πήχη — και CVE-free ή όχι, είναι το μόνο «δωρεάν» buffer.
• IOMMU/DMA isolation (host). Η NVIDIA το ορίζει ρητά — χωρίς αυτό, ένα bit-flip στη GPU οδηγεί πιο εύκολα σε DMA access στον host.
• Παρακολούθησε το telemetry. Επανάληψη uncorrectable errors, unexpected resets, row-remapping events: αυτές είναι οι «σφήνες» του GPUThor. Σύνδεσέ τα με alerting.
• Περιόρισε το CUDA όπου μπορείς. Οποιοσδήποτε τρέχει user-level CUDA σε shared GPU μπορεί να «σφυροκοπήσει». Μην δίνεις compute σε μη-έμπιστο κώδικα.
• Κατέγραψε το «μοντέλο-αντίκτυπο». Αν τρέχεις AI σε co-tenancy, πρόβλεψε έλεγχο ακεραιότητας μοντέλων (checksum/attestation) — όχι μόνο τελικό F1.

Τίποτα από αυτά δεν είναι δωρεάν

• SYS-ECC: πληρώνεις 6–12% χωρητικότητα και bandwidth («τρώει» μια σημαντική τομή από την ήδη εμπορευματοποιημένη μνήμη). Σε inference ταχύτητα η διαφορά είναι μικρή, αλλά στα training loops κάθε πρόσθετη ανάγνωση/γραφή έχει κόστος.
• Αποκλειστικά instances / dedicated GPUs: στο cloud κοστίζουν αισθητά περισσότερο από shared (συχνά 30–70% premium ανά ώρα), και «αποκλειστικός» δεν σημαίνει απαραίτητα φυσικά απομονωμένος από άλλους μισθωτές — ρώτα τον πάροχο για το πραγματικό πλάνο co-tenancy.
• IOMMU/DMA isolation + telemetry + checksumming: εδώ το κόστος είναι κυρίως operational — ρυθμίσεις, πόροι μηχανικής, alert fatigue. Εξακολουθεί να είναι το φτηνότερο «ασφαλιστήριο» από τα τρία.
• Καμία από τις παραπάνω δεν δίνει εγγύηση: μειώνουν την έκθεση, δεν την εξαλείφουν. Η ειλικρινής συμβουλή είναι: σχεδίασε σαν το GPUThor να έχει ήδη δημοσιευτεί.

Incident response — αν υποψιάζεσαι ότι έχεις ήδη πληγεί

1. Row-remapping events & ECC counters (αξίζει να ψάξεις πρώτα): Επανάληψη uncorrectable/CE errors σε συγκεκριμένο bank, αυξανόμενα remapped rows (already-bad-row / POISON counter, `dmesg`/`nvidia-smi -q` per memory catalogue), unexpected resets χωρίς power event. Σε bare-metal: `journalctl -xe`, `dmesg` για ECC/GPU errors, και τα datasheet-επηρεαζόμενα logs του driver.
2. GPU telemetry & utilization anomalia: spike σε memory bandwidth χωρίς workload, φάσεις «hammering» με 100% utilization χωρίς έργο. `nvidia-smi dmon` δείχνει per-process/related utilization — ψάξε για ανεριμηνεύσιμο χρόνο.
3. Model integrity: αν έτρεχες inference σε shared GPU, ελέγξε checksums/weights των artifacts. Ένα flipped bit στον exponent δεν φαίνεται σε loss curves πάντα — κράτα hash πριν την είσοδο στον pipeline.
4. Εξέτασε ξανά τη co-tenancy: αν δεν έχεις απόδειξη «φυσικής απομόνωσης» από τον πάροχο, θεώρησε ότι είχες γείτονα. Κατέγραψε ποια workloads έτρεχαν δίπλα όταν συνέβη η ανωμαλία.
5. Αν επιβεβαιώσεις ή δεν μπορείς να αποκλείσεις: απομόνωσε τον workload, κράτησε snapshot των logs (dmesg, driver logs, `nvidia-bug-report`), κι επικοινώνησε με τον πάροχο για τα row-remap/ECC counters μόλις γίνει «εβδομάδα». Το mitigation δεν είναι forensic — είναι τερματισμός συν-κατοίκησης.

Κρατήσου από τον κανόνα: βλέπεις ανωμαλία → μαζεύεις στοιχεία → απομονώνεις → ρωτάς τον πάροχο. Το αντίστροφο (reboot + «μήπως ήταν τίποτα;») είναι ακριβώς αυτό που σε αφήνει χωρίς εικόνα την επόμενη φορά.

09Τι έρχεται μετά — και η εικόνα μνήμης

• 15 Νοεμβρίου 2026 — ACM CCS (Χάγη): παρουσίαση GPUThor και δημοσιοποίηση του εκμεταλλεύσιμου code.
• Blackwell RAS Repair: καθυστερεί το DoS route, δεν το αποτρέπει. Τα server Ampere (A100) παραμένουν σε SecDED — το escalation path ισχύει.
• Η πραγματική λύση είναι στο μέλλον: ισχυρότερο multi-bit ECC, per-row Activation Counting (PRAC/RFM) και σχεδιασμός μνήμης που βάζει την ασφάλεια πριν την πυκνότητα. Μέχρι τότε, ο νόμος του Μουρ παίζει εναντίον μας: όσο πυκνότερη η μνήμη, τόσο πιο εύκολο το Rowhammer.
• Δεν είναι «GPU-only»: η ίδια φυσική — η DRAM — υπάρχει παντού: HBM σε accelerators, LPDDR στα laptops. Κάθε νέα μελέτη μειώνει την απόσταση μέχρι τον επόμενο, «ασφαλέστερο» τύπο μνήμης.

Γρήγορα λόγια ισορροπίας: ο ισχυρισμός «το Cloud Computing δεν είναι ασφαλές» δεν είναι σε καμία περίπτωση λόγος πανικού — είναι λόγος για υγιή παράνοια. Αλλά αν χτίζεις AI pipeline σε shared GPUs και θεωρούσες το ECC «δεδομένο», αυτό το άρθρο υπάρχει για να αλλάξει τη default σου.