Windows Hyper VBS Virtualization-based Security

目錄

 

VBS介紹

VBS組件要求


VBS介紹

基於虛擬化的安全性( Virtualization-based security  VBS)使用硬件虛擬化特性來創建和隔離一個與正常操作系統隔離的安全內存區域。Windows可以使用這種“虛擬安全模式”來託管許多安全解決方案,爲它們提供了針對操作系統漏洞的大量保護,並防止試圖破壞保護的惡意攻擊的使用。

VBS使用Windows hypervisor來創建這種虛擬安全模式,並實施保護重要系統和操作系統資源的限制,或者保護安全資產(例如經過身份驗證的用戶憑證)。通過增加VBS提供的保護,即使惡意軟件獲得了對操作系統內核的訪問權,潛在的漏洞也可以被極大地限制和遏制,因爲系統管理程序可以防止惡意軟件執行代碼或訪問平臺機密。

一個這樣的安全解決方案示例是管理程序強制的代碼完整性(HVCI),它使用VBS來顯著增強代碼完整性策略的實施。內核模式代碼完整性在啓動所有內核模式驅動程序和二進制文件之前檢查它們,並防止未簽名的驅動程序或系統文件加載到系統內存中。

類似地,用戶模式可配置的代碼完整性策略在加載應用程序之前檢查它們,並且只啓動由已知的、已批准的簽名者簽名的可執行程序。HVCI利用VBS在安全的環境中運行代碼完整性服務,爲內核病毒和惡意軟件提供更強的保護。hypervisor是系統軟件的最特權級,它設置並強制跨所有系統內存的頁面權限。頁面只有在安全區域內的代碼完整性檢查通過後纔可執行,而可執行頁面是不可寫的。這樣,即使存在緩衝區溢出這樣的漏洞,允許惡意軟件試圖修改內存,也不能修改代碼頁,修改後的內存也不能執行。

 

VBS組件要求

Hardware requirement Details
64-bit CPU Virtualization-based security (VBS) requires the Windows hypervisor, which is only supported on 64-bit IA processors with virtualization extensions, including Intel VT-X and AMD-v.
Second Level Address Translation (SLAT) VBS also requires that the processor’s virtualization support includes Second Level Address Translation (SLAT), either Intel VT-X2 with Extended Page Tables (EPT), or AMD-v with Rapid Virtualization Indexing (RVI).
IOMMUs or SMMUs (Intel VT-D, AMD-Vi, ARM64 SMMUs) All I/O devices capable of DMA must be behind an IOMMU or SMMU. An IOMMU can be used to enhance system resiliency against memory attacks.
Trusted Platform Module (TPM) 2.0 TPMs, either discrete or firmware, will suffice. For more information, see Trusted Platform Module (TPM) 2.0.
Firmware support for SMM protection System firmware must adhere to the recommendations for hardening SMM code described in the Windows SMM Security Mitigations Table (WMST) specification. The WSMT specification contains details of an ACPI table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features. Firmware must implement the protections described in the WSMT specification, and set the corresponding protection flags as described in the specification to report compliance with these requirements to the operating system.
Unified Extensible Firmware Interface (UEFI) Memory Reporting UEFI firmware must adhere to the following memory map reporting format and memory allocation guidelines in order for firmware to ensure compatibility with VBS.
 
  • UEFI v2.6 Memory Attributes Table (MAT) - To ensure compatibility with VBS, firmware must cleanly separate EFI runtime memory ranges for code and data, and report this to the operating system. Proper segregation and reporting of EFI runtime memory ranges allows VBS to apply the necessary page protections to EFI runtime services code pages within the VBS secure region. Conveying this information to the OS is accomplished using the EFI_MEMORY_ATTRIBUTES_TABLE. To implement the UEFI MAT, follow these guidelines:
    1. The entire EFI runtime must be described by this table.
    2. All appropriate attributes for EfiRuntimeServicesData and EfiRuntimeServicesCode pages must be marked.
    3. These ranges must be aligned on page boundaries (4KB), and can not overlap.
  • EFI Page Protections -All entries must include attributes EFI_MEMORY_RO, EFI_MEMORY_XP, or both. All UEFI memory that is marked executable must be read only. Memory marked writable must not be executable. Entries may not be left with neither of the attributes set, indicating memory that is both executable and writable.
Secure Memory Overwrite Request (MOR) revision 2 Secure MOR v2 is enhanced to protect the MOR lock setting using a UEFI secure variable. This helps guard against advanced memory attacks. For details, see Secure MOR implementation.
Hypervisor Code Integrity (HVCI)-compatible drivers Ensure all system drivers have been tested and verified to be compatible with HVCI. The Windows Driver Kit and Driver Verifier contain tests for driver HVCI compatibility. There are four steps to verify driver compatibility:
  1. Use Driver Verifier with the new Code Integrity compatibility checks enabled.
  2. Run the Hypervisor Code Integrity Readiness Test in the Windows HLK.
  3. Test the driver on a system with VBS and HVCI enabled. This step is imperative to validate the driver's behavior with HVCI, as static code analysis tools simply aren't capable of detecting all HVCI violations possible at runtime.
  4. Use the Device Guard and Credential Guard hardware readiness tool.

 

 

轉自:

https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章