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: The entire EFI runtime must be described by this table. All appropriate attributes for EfiRuntimeServicesData and EfiRuntimeServicesCode pages must be marked. 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: Use Driver Verifier with the new Code Integrity compatibility checks enabled. Run the Hypervisor Code Integrity Readiness Test in the Windows HLK. 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. Use the Device Guard and Credential Guard hardware readiness tool.

转自：

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