Skip to content

ASID-based TLB tagging (guest TLB isolation)

TLB entry'lerini bir Address Space ID (AMD ASID / Intel VPID) ile etiketlemek; böylece CPU guest ile host (ve guest'ler arası) translation'larını ayrı tutar, VM entry/exit'te tam TLB flush'tan kaçınırken address-space izolasyonunu korur.

Mechanism

Note

Bir TLB, virtual-to-physical translation'ları cache'ler. Tagging olmadan, guest ile host (ve guest'ler) arasındaki her world switch'te TLB'nin flush edilmesi gerekirdi ki bir address space'in translation'ı başkasında kullanılmasın — bu hem performans maliyeti hem de yanlış yönetilirse bir correctness/izolasyon tehlikesidir. AMD-V, VMCB'ye ASID alanını ekler; Intel VT-x ise VMCS'e VPID (Virtual Processor Identifier) ekler. Her cache'lenen translation kendi ASID/VPID'siyle etiketlenir; böylece CPU yalnızca mevcut context'e ait entry'leri match eder. AMD'de ASID 0 host için rezervedir. İzolasyon invariant'ı şudur: bir tag altında oluşan TLB entry'si asla başka bir tag altındaki translation'ı karşılamamalıdır; host bunu, ayrı ve doğru yönetilen tag'ler atayarak ve bir guest'in mapping'leri değiştiğinde doğru tag'i flush ederek zorlar.

Tag'lerin yanlış yönetimi gerçek bir bug class'ıdır: bir ASID/VPID'yi flush etmeden guest'ler arasında yeniden kullanmak, ya da bir EPT/NPT değişikliğinden sonra flush etmemek, bir guest'in stale translation'lara çarpmasına yol açabilir — cross-domain bir bilgi veya integrity tehlikesi (bkz. cross-domain hypervisor exploitation).

Walkthrough

Public reference: AMD64 APM Vol. 2 (ASID / TLB control) ve Intel SDM Vol. 3C (VPID ve INVVPID). Kavramsal host sorumlulukları:

  1. Her guest/vCPU context'ine sıfır olmayan bir ASID (AMD) ya da VPID (Intel) ata.
  2. VM entry'de CPU yeni TLB fill'lerini o ID ile etiketler; host (ASID 0 / VPID 0) translation'ları ayrı kalır, dolayısıyla world switch'te tam flush gerekmez.
  3. Guest'in address space'i ya da nested page table'ları değiştiğinde host hedefli bir flush yapar — AMD'de VMCB'deki TLB_CONTROL, Intel'de yalnızca etkilenen tag için INVVPID / INVEPT.
  4. Bir ASID/VPID'yi yeni bir guest için geri dönüştürürken host önce o tag'i flush etmelidir.

Beklenen gözlem: blanket TLB flush'ı olmadan VM entry/exit'ler; guest paging ya da EPT/NPT güncellemeleriyle korele hedefli invalidation'lar.

Warning

Geri dönüştürülen bir tag'i flush etmeyi unutmak, ya da bir nested EPT/NPT mapping değişmişken ASID tagging'e güvenmek, tam olarak stale-translation guest bug'larını üreten state-confusion türüdür. Tag izolasyonu, etrafındaki flush disiplini kadar güçlüdür.

Detection

  • Host tarafı: ASID/VPID atamasının her canlı context için unique olduğunu ve her NPT/EPT mutasyonunun doğru invalidation ile eşleştiğini denetle. Eksik flush'lar, guest memory tutarsızlıkları ya da introspection'ın stale view görmesi olarak ortaya çıkar.
  • Bir guest tag'leri doğrudan okuyamaz, ama stale-translation belirtileri (bir remap sonrası eski data dönen read'ler) probe edilebilir.

Mitigation

  • Sıkı flush-on-recycle ve flush-on-mapping-change disiplini sürdür; doğal eviction'a güvenmek yerine per-tag hedefli invalidation'ı (INVVPID/INVEPT, TLB_CONTROL) tercih et.
  • Her vCPU için ayrı VPID/ASID kullan ve sıfır olmayan bir tag'i asla guest'ler arasında paylaşma.
  • Nested virtualization'da, L1'in EPT/NPT'sini shadow'larken L0'ın doğru tag'leri flush etmesini sağla ki bir L2 stale L0 translation'larını tutamasın.

References