Skip to content

Restrict indirect branch prediction / RIBP

ARM's family of context-isolation controls for indirect/branch-history predictors — the AArch64 counterpart to x86 IBRS/STIBP that stops one execution context from training another's indirect-branch targets and driving a Spectre-v2 / branch-target-injection leak.

Mechanism

Note

Spectre-v2 (branch target injection) çalışır çünkü indirect-branch predictor'ları ve branch-history state'i çoğu zaman context'ler arasında paylaşılır — privilege level'ları, process'ler ya da SMT sibling'leri. Bir saldırgan predictor'ı eğitir ki bir victim'in indirect branch'i spekülatif olarak saldırgan-seçimli bir hedefe atlasın ve bir cache side channel üzerinden sır sızdıran bir transient gadget execute etsin.

"Restrict indirect branch prediction" (RIBP), ARM'ın cevabının şemsiyesidir: bir context'te oluşturulan prediction state'inin daha-ayrıcalıklı ya da farklı bir context'teki indirect branch'leri etkilemesini engelleyen kontroller. Kavramsal olarak bu, x86'nın IBRS'ini (privilege arasında indirect branch'lerin spekülasyonunu kısıtla), STIBP'ini (bir sibling thread'in prediction'larını yönlendirmesine izin verme) ve IBPB'sini (önceki eğitimi atan bir barrier) yansıtır. Sınır tutar çünkü predictor, trust transition'larında cross-context eğitimi unutmaya ya da yok saymaya zorlanır.

ARM'da gerçekleştirme core'a göre değişir. Bazıları mimari context kontrolleri uygular (örn. FEAT_CSV2 / context-number register'ları, böylece prediction'lar context'e göre tag'lenir); diğerleri herhangi bir sonraki indirect branch'ten önce branch-history/indirect-predictor state'ini temizlemek için context switch'te branch predictor'ı invalidate etmeyi, bir clearbhb tarzı diziyi ya da bir firmware çağrısını — SMCCC_ARCH_WORKAROUND_3 — gerektirir. İlgili Branch History Buffer (BHB) saldırıları (Spectre-BHB) aynı predictor-isolation felsefesiyle mitigate edilir.

Walkthrough

Kavramsal; ARM'ın Spectre-BHB whitepaper'ından ve Linux'un arm64 proton-pack mitigation'ından alınmıştır.

  1. Eğitim. Context A'daki saldırgan kodu, paylaşılan predictor/BHB belirli history'leri saldırgan-seçimli hedeflerle ilişkilendirsin diye indirect branch'leri tekrar tekrar execute eder.

  2. Geçiş. Kontrol context B'ye geçer (kernel entry, process switch ya da SMT sibling victim'i çalıştırır).

  3. Mis-speculation. İzolasyon olmadan, B'nin indirect branch'i A'nın eğitimini miras alır ve saldırgan-seçimli bir gadget'ı spekülatif olarak execute eder; cache'te sır-bağımlı bir iz bırakır.

  4. RIBP bağlantıyı keser. Kısıtlanmış indirect branch prediction ile, geçiş ya prediction'ları context'e göre tag'ler, ya predictor'ı invalidate eder, ya da bir barrier/firmware workaround'u çıkarır — böylece B'nin branch'i artık A tarafından yönlendirilemez. Sınırdaki temsili kernel mantığı:

on_context_switch / kernel_entry:
    apply_indirect_branch_isolation()   # CSV2 context tag, clearbhb,
                                         # or SMCCC_ARCH_WORKAROUND_3 firmware call

Warning

Bu kontrollerin bir performans maliyeti vardır (sıcak geçişlerde barrier'lar/flush'lar), bu yüzden satıcılar bunları etkilenen core başına seçici olarak uygular. Branch Privilege Injection gibi araştırmalar, hardware predictor mitigation'larının kendilerinin race barındırabileceğini gösterir — predictor isolation transient-execution sızıntısını azaltır, ama kanıtlanabilir şekilde ortadan kaldırmaz.

Detection

Transient-execution saldırıları tasarımı gereği mimari olarak görünmezdir, bu yüzden doğrudan host tespiti zayıftır. Savunucular bunun yerine konfigürasyon attestation'ına güvenir: platformun ilgili indirect-branch / Spectre-v2 mitigation'ını aktif olarak bildirdiğini doğrulayın (Linux'ta, spectre_v2 / BHB için vulnerabilities sysfs entry'leri), firmware'in SMCCC_ARCH_WORKAROUND_3'ü sunduğunu doğrulayın ve "Vulnerable" ya da "mitigation forced off" bildiren host'ları işaretleyin. Microarchitectural side-channel denemeleri yalnızca anormal yüksek oranlı cache-timing / mispredict aktivitesi olarak yüzeye çıkabilir; bu da gürültülüdür ve tek başına nadiren eyleme geçirilebilir.

Mitigation

  • Yığını konuşlandır: CPU firmware/microcode ve OS güncellemelerini uygulayın ki kernel doğru per-core mitigation'ı seçsin (context tagging, switch'te predictor invalidation, clearbhb ya da firmware workaround'u).
  • Yazılım disipliniyle eşle: retpoline tarzı call dönüşümü ve barrier eklemesi, hardware kontrollerinin yok ya da eksik olduğu yerlerde hâlâ geçerlidir.
  • Hardening / uyarılar: tehdit modeli izin vermedikçe mitigation'ı performans için devre dışı bırakmayın; izolasyon Spectre-v1'i (bounds-check bypass) ya da data-only kanalları kapsamaz ve yeni açıklanan predictor race'leri taze firmware gerektirebilir. "Mitigation mevcut"u bir garanti değil, attest edilecek bildirilmiş bir durum olarak görün.

References