VBS
参考来源
- 基于虚拟化的安全 (VBS) | Microsoft Learn — VBS 定义、硬件要求、安全解决方案
- 基于虚拟化的安全系统资源保护 | Microsoft Learn — VBS 信任模型变更、MSR 访问保护
什么是 VBS
基于虚拟化的安全功能（VBS）使用硬件虚拟化和 Windows 虚拟机监控程序来创建独立的虚拟环境，该环境将成为假定内核遭到入侵的 OS 的信任根。Windows 使用这种独立环境来托管许多安全解决方案，为它们提供了显著增强的保护，以防止操作系统中的漏洞，并防止利用恶意攻击试图破坏保护。VBS 强制实施限制，以保护重要的系统和操作系统资源，或保护安全资产（如经过身份验证的用户凭据）。
简单来说，VBS 通过 Hypervisor 在操作系统之下构建一个隔离的信任根，即使 Windows 内核被攻破，攻击者也无法触及这个隔离环境中保护的安全资产。
其中一个安全解决方案是 内存完整性，它通过在 VBS 的隔离虚拟环境中执行内核模式代码的完整性检查，来保护并增强 Windows 系统的安全性。内核模式代码完整性指的是 Windows 在启动所有内核模式驱动程序和二进制文件之前，会对其进行检查，从而防止未经签名或不可信的驱动程序或系统文件被加载到系统内存中。此外，内存完整性还限制了可能用于破坏系统性能的内核内存分配，确保内核内存页只有在通过安全运行环境中的代码完整性检查后才会被执行，而执行中的页则永远无法被修改。这样一来，即使存在如缓冲区溢出这样的漏洞，使得恶意软件试图修改内存的情况发生，执行中的代码页也无法被修改，而修改后的内存也无法被重新执行。
Info
核心保护机制：
- 可执行代码页不可写
- 可写内存不可执行
- 未签名/不受信任的驱动程序无法加载
VBS 启用要求
VBS 要求以下组件必须存在并且配置正确。
| 硬件要求 | 详细信息 |
|---|---|
| 64-bit CPU | 基于虚拟化的安全（VBS）需要 Windows 虚拟机管理程序，而该虚拟机管理程序仅支持具有虚拟化扩展的 64 位 IA 处理器，包括 Intel VT-X 和 AMD-V。 |
| 二级地址转换 (SLAT) | VBS 还要求处理器的虚拟化支持必须包括第二级地址转换 (SLAT)，即 Intel VT-X2 技术配合扩展页表（Extended Page Tables,EPT），或 AMD-V 技术配合快速虚拟化索引（Rapid Virtualization Indexing,RVI）。 |
| IOMMUs or SMMUs (Intel VT-D, AMD-Vi, Arm64 SMMUs) | 所有支持 DMA（直接内存访问）的 I/O 设备都必须位于 IOMMU(输入/输出内存管理单元) 或 SMMU(系统内存管理单元) 后面。IOMMU 可用于增强系统对内存攻击的系统复原能力。 |
| 可信平台模块 (TPM) 2.0 | 有关详细信息，请参阅 受信任的平台模块 2.0 |
| SMM 保护的固件支持 | 系统固件必须遵循有关强化 SMM 准则的建议，如 Windows SMM 安全缓解表 (WMST) 规范 所述。 WSMT 规范包含 ACPI 表的详细信息，该表是为支持 VBS 功能的 Windows 操作系统创建。 固件必须实施 WSMT 规范中所述的保护，并设置规范中所述的相应保护标志，以向操作系统报告是否符合这些要求。 |
| 统一可扩展固件接口 (UEFI) 内存报告 | UEFI 固件必须遵循以下内存映射报告格式和内存分配准则，这样固件才能确保与 VBS 兼容。 - UEFI v2.6 内存属性表 (MAT) - 为了确保与 VBS 兼容，固件必须将代码和数据的 EFI 运行时内存范围完全分开，并向操作系统报告此情况。 通过对 EFI 运行时内存范围进行正确分隔和报告，VBS 可以将必要的页面保护应用于 VBS 安全区域内的 EFI 运行时服务代码页。 将此信息传达给 OS 是使用 EFI_MEMORY_ATTRIBUTES_TABLE 完成的。 若要实现 UEFI MAT，请遵循以下准则： 1. 整个 EFI 运行时必须由此表进行描述。 2. 必须标记 EfiRuntimeServicesData 和 EfiRuntimeServicesCode 页的所有相应属性。 3. 这些范围必须在页面边界 (4KB) 上对齐，并且不能重叠。 - EFI 页面保护 - 所有项都必须包含属性 EFI_MEMORY_RO 和/或 EFI_MEMORY_XP。 标记为可执行的全部 UEFI 内存都必须为只读。 标记为可写的内存不能是可执行文件。 不得保留这两项属性均未设置的项（两项属性均未设置表明内存既可执行，又可写入）。 |
| 安全内存覆盖请求 (Memory Overwrite Request,MOR) 修订版 2 | 安全 MOR v2 已增强，以使用 UEFI 安全变量保护 MOR 锁设置。 这有助于防范高级内存攻击。 有关详细信息，请参阅 安全 MOR 实现。 |
| 与内存完整性兼容的驱动程序 | 确保所有的系统驱动程序都经过测试并验证与内存完整性兼容。 Windows 驱动程序工具包 和 驱动程序验证程序 包含驱动程序兼容性与内存完整性的测试。 验证驱动程序兼容性有三个步骤： 1. 在启用代码完整性兼容性检查的情况下使用驱动程序验证程序。 2. 在 Windows HLK 中运行 虚拟机监控程序代码完整性就绪情况测试。 3. 在启用 VBS 和内存完整性的系统上测试驱动程序。 这一步骤对于验证具有内存完整性的驱动程序行为至关重要，因为静态代码分析工具根本无法在运行时检测到所有可能的内存完整性冲突。 |
| 安全启动 (Secure Boot) | 必须在利用 VBS 的设备上启用安全启动。 有关详细信息，请参阅 安全启动 |
VBS 适用于启用了嵌套虚拟化支持的 VM 或启用了来宾 VSM 的 。 后者在 Hyper-V 的第 2 代 VM 上默认启用。 这还包括 Microsoft Azure 上的所有第 2 代 VM，以及启用了嵌套虚拟化的第 1 代 VM。下表详细介绍了受支持的 Azure VM 系列。
| VM 系列名称 | 嵌套虚拟化 | VM Gen |
|---|---|---|
| Av2 | 是 | 1（某些内部大小支持第 2 代） |
| B | 否 | 1 和 2 |
| Dsv2/Dv2/Dv3/Ev3 | 是 | 1 |
| Dsv3/Ddsv3 | 是 | 1 和 2 |
| Dsv4/Ddsv4 | 是 | 1 和 2 |
| Esv3/Edsv3 | 是 | 1 和 2 |
| Esv4/Edsv4 | 是 | 1 和 2 |
| Ev4/Edv4 | 是 | Ev4 - 仅 1 Edv4 -1 和 2 |
| Dv4/Ddv4 | 是 | 1 和 2 |
| Dv5/Ddv5/Dsv5/Ddsv5 | 是 | 1 和 2 |
| Ev5/Edv5/Esv5/Edsv5 | 是 | 1 和 2 |
| Dasv5/Dadsv5/Easv5/ Eadsv5 | 是 | 1 和 2 |
| Ebsv5/Edbsv5 | 是 | 1 和 2 |
| Fsv2 | 是 | 1 和 2 |
| Fx | 是 | 2 |
| Lsv2 | 是 | 1 和 2 |
VBS 信任模型变更
虽然 VBS 极大地提高了平台安全性，但 VBS 也会更改 Windows PC 中的信任边界。借助 VBS，Windows 虚拟机监控程序可以控制底层硬件的许多方面，这些硬件为 VBS 安全环境提供了基础。虚拟机监控程序必须假定 Windows 内核可能会受到恶意代码的破坏，因此必须保护关键系统资源不受在内核模式下运行的代码的操纵，以免危及安全资产。
| 传统模型 | VBS 模型 | |
|---|---|---|
| 信任根 | Windows 内核 (Ring 0) | Hypervisor（内核之下） |
| 内核地位 | 最高可信 | 不可信，需被保护 |
| 保护目标 | 无 | 系统资源不被内核模式代码操纵 |
MSR 访问保护
VBS 资源保护的一个重要方面是对处理器模型特定寄存器 (MSR) 的保护。
为什么需要保护 MSR
新式处理器支持大量 MSR，其中许多 MSR 控制处理器行为的关键方面。MSR 只能从内核模式代码读取或写入 (即 CPL0)。更改由 MSR 控制的设置可能会允许恶意内核模式代码更改系统的行为，并允许攻击者获得控制，从而损害安全性。此外，许多 MSR 都包含有关系统操作的数据，例如跟踪或诊断数据，这些数据也可用于显示或计算安全资产。
MSR 通过索引访问，索引是每个 MSR 的唯一标识符。 过去，许多 MSR 已建立为体系结构；也就是说，它们的存在和功能在多个处理器代次之间在体系结构上保持一致。 在这种情况下，可以依赖具有已记录 MSR 索引和定义的已知 MSR 来控制一组已知的已发布功能。 但是，还有一些 MSR 因处理器而异，并且在某些情况下，MSR 索引随时间而重新设定用途，需要重新定义以引用新的控件集。 对于系统级软件来说，这些问题非常棘手，因为很难在广泛可用的商业软件中编码和维护这些控件的知识。
虚拟机监控程序如何保护 MSR
虚拟机监控程序监视和控制对所有 MSR 的访问。虚拟机管理程序维护已知 MSR 索引的列表，并且仅允许内核模式代码访问已知合理且被视为安全的 MSR 或 MSR 中的特定位。虚拟机监控程序将阻止访问虚拟机监控程序未知的任何 MSR，或通过其已发布定义已知的任何 MSR 来表示安全风险。在某些情况下，可能允许部分访问。
查看 MSR 阻止事件
虚拟机监控程序阻止 MSR 访问时会记录事件，可在系统日志中查看。
若要确定虚拟机监控程序是否阻止了对 MSR 的访问，请从 Microsoft-Windows-Hyper-V-Hypervisor 查看 Windows 系统日志中的事件 ID 12550。
事件信息：
- 事件来源：
Microsoft-Windows-Hyper-V-Hypervisor - 事件 ID：
12550 - 说明： Hyper-V 检测到对受限制的 MSR 的访问
- 包含字段： Msr、IsWrite、MsrValue、AccessStatus、Pc、ImageBase、ImageChecksum、ImageTimestamp、ImageName
可在「事件查看器 → Windows 日志 → 系统」中筛选来源 Hyper-V-Hypervisor、事件 ID 12550 查看。
查看 VBS 状态
方式一：系统信息
按 Win 键打开搜索框，输入 msi 打开 System Information（系统信息）页面，向下滑动，查看 Virtualization-based security（基于虚拟化的安全性）的状态为 Running（运行中）。
方式二：PowerShell
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select -ExpandProperty VirtualizationBasedSecurityStatus| 值 | 描述 |
|---|---|
| 0 | VBS 未启用。 |
| 1 | VBS 已启用但尚未运行。 |
| 2 | VBS 已启用且正在运行。 |
方式三：注册表
reg query "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity
0x1 = 启用，0x0 = 禁用。
关闭 VBS
手动关闭 VBS 需要以下步骤：
-
Windows Defender 中关闭内存完整性
Memory integrity功能，参考 内存完整性 > 关闭内存完整性功能 -
注册表将
EnableVirtualizationBasedSecurity修改为 0
-
注册表将 Scenarios 下 Enabled 值修改为 0
对于 SCPC，Scenarios 下除了内存完整性 HypervisorEnforcedCodeIntegrity 之外，还有其它关于 security 的注册表值名称中包含 Enabled 的也需要改为 0，不然 VBS 关闭不彻底，Virtualization-based security 状态会显示为 Enabled but not running 之类的，不是 Not enabled
查询命令如下
reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard" /s
注册表路径
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios
| 值名称 | 可修改值 | 功能 |
|---|---|---|
| HypervisorEnforcedCodeIntegrity | 0 = Disabled1 = Enabled | 内存完整性 (HVCI) 的启用和关闭 |
| SecureBiometrics | 0 = Disabled1 = Enabled | ESS(Fingerprint/Camera) 的启用和关闭 SCPC |
| SystemGuard | 0 = Disabled1 = Enabled | Firmware protection 的启用和关闭 SCPC |
- 启动配置中将
hypervisorlaunchtype改为 off
bcdedit /set hypervisorlaunchtype off
- 将以上 3 步执行完成后，重启计算机，打开系统信息查看
Virtualization-based security（基于虚拟化的安全性）的状态为Not enabled（未启用）