VMware Workstation 和 Device/Credential Guard 不兼容 [英] VMware Workstation and Device/Credential Guard are not compatible
问题描述
去年我一直在运行 VMware，没有任何问题，今天我打开它以启动我的一个 VM 并收到一条错误消息，请参阅屏幕截图.
我确实按照链接并完成了步骤，在第 4 步中，我需要使用mountvol"安装一个卷.当我尝试使用 mountvol X: \?Volume{5593b5bd-0000-0000-0000-c0f373000000} 挂载卷时，它一直说 目录不是空的. 我什至创建了一个 2GB 的分区，但仍然是相同的消息.
我的问题:
如何挂载非空的卷，即使它是空的?
为什么这个 Device/Credential Guard 会自动启用，我该如何摆脱或禁用它.
CMD:
... VSM 实例与正常运行的系统功能并受到尝试读取信息的保护那种模式.保护是硬件辅助的，因为管理程序要求硬件以不同方式处理这些内存页.这同一个主机上的两个虚拟机的方式是一样的不能彼此互动；它们的内存是独立的和硬件的以确保每个虚拟机只能访问自己的数据.
从这里开始，我们现在有一个保护模式，我们可以在其中运行安全敏感操作.在撰写本文时，我们支持三个可以驻留在此处的功能:本地安全机构 (LSA)，和内核模式代码形式的代码完整性控制功能完整性 (KMCI) 和管理程序代码完整性控制本身，这称为管理程序代码完整性 (HVCI).
<块引用>当这些功能由 VSM 中的 Trustlets 处理时，主机操作系统只需通过标准渠道与他们沟通，操作系统内部的功能.虽然这个 Trustlet 特定的允许通信，主机中有恶意代码或用户操作系统尝试读取或操作 VSM 中的数据将显着比没有配置的系统更难，提供安全福利.
在 VSM 中运行 LSA，导致 LSA 进程本身(LSASS)留在主机操作系统，以及一个特殊的、附加的 LSA 实例(称为 LSAIso– 代表 LSA 隔离)被创建.这是为了让所有对 LSA 的标准调用仍然成功，提供优秀的遗产和向后兼容性，即使对于服务或功能需要与 LSA 直接通信.在这方面，你可以认为主机操作系统中剩余的 LSA 实例作为代理"或存根"简单地与隔离版本通信的实例规定的方式.
Hyper-V 和 VMware 不能同时工作，直到 2020 年，当 VMware 使用 Hyper-V 平台与 Hyper-V 共存时 从 15.5.5 版.
15.5.5 版之前的 VMware Workstation 如何工作?
VMware Workstation 传统上使用虚拟机监视器(VMM) 在特权模式下运行，需要直接访问CPU 以及访问 CPU 的内置虚拟化支持(英特尔的 VT-x 和 AMD 的 AMD-V).当 Windows 主机启用基于虚拟化的安全 (VBS") 功能，Windows 添加了一个硬件和Windows之间基于Hyper-V的hypervisor层.任何运行 VMware 传统 VMM 的尝试都失败了，因为在里面Hyper-V VMM 不再可以访问硬件的虚拟化支持.
介绍用户级别监视器
为了解决这个 Hyper-V/Host VBS 兼容性问题，VMware 的平台团队重新构建了 VMware 的 Hypervisor 以使用 Microsoft 的 WHP API.这意味着将我们的 VMM 更改为在用户级别运行而不是在特权模式，以及修改它以使用 WHP API 来管理执行来宾而不是使用底层硬件直接.
这对您意味着什么?
VMware Workstation/Player 现在可以在启用 Hyper-V 时运行.你没有不再需要在运行 VMware Workstation 和 Windows 之间做出选择WSL、Device Guard 和 Credential Guard 等功能.当 Hyper-V 是启用，将自动使用 ULM 模式，以便您可以运行 VMware工作站正常. 如果您根本不使用 Hyper-V，VMwareWorkstation 足够智能，可以检测到这一点，并且将使用 VMM.
系统要求
要使用 Windows 管理程序 API 运行工作站/播放器，最低要求的 Windows 10 版本是 Windows 10 20H1 版本19041.264.VMware Workstation/Player 最低版本为 15.5.5.
为避免该错误，请将您的 Windows 10 更新到版本 2004/Build 19041(Mai 2020 更新)并至少使用 VMware 15.5.5.
I have been running VMware for the last year no problems, today I opened it up to start one of my VM and get an error message, see screen shot.
I did follow the link and went through the steps, on step 4 I need to mount a volume using "mountvol".
when I try to mount a volume using mountvol X: \?Volume{5593b5bd-0000-0000-0000-c0f373000000} it keeps saying The directory is not empty. I even created a partition with 2GB and still the same message.
My Questions:
How can I mount the volume that is not empty even though it is?
Why did this Device/Credential Guard auto enable itself and how can I get rid of it or disable it.
CMD:
Device/Credential Guard is a Hyper-V based Virtual Machine/Virtual Secure Mode that hosts a secure kernel to make Windows 10 much more secure.
...the VSM instance is segregated from the normal operating system functions and is protected by attempts to read information in that mode. The protections are hardware assisted, since the hypervisor is requesting the hardware treat those memory pages differently. This is the same way to two virtual machines on the same host cannot interact with each other; their memory is independent and hardware regulated to ensure each VM can only access it’s own data.
From here, we now have a protected mode where we can run security sensitive operations. At the time of writing, we support three capabilities that can reside here: the Local Security Authority (LSA), and Code Integrity control functions in the form of Kernel Mode Code Integrity (KMCI) and the hypervisor code integrity control itself, which is called Hypervisor Code Integrity (HVCI).
When these capabilities are handled by Trustlets in VSM, the Host OS simply communicates with them through standard channels and capabilities inside of the OS. While this Trustlet-specific communication is allowed, having malicious code or users in the Host OS attempt to read or manipulate the data in VSM will be significantly harder than on a system without this configured, providing the security benefit.
Running LSA in VSM, causes the LSA process itself (LSASS) to remain in the Host OS, and a special, additional instance of LSA (called LSAIso – which stands for LSA Isolated) is created. This is to allow all of the standard calls to LSA to still succeed, offering excellent legacy and backwards compatibility, even for services or capabilities that require direct communication with LSA. In this respect, you can think of the remaining LSA instance in the Host OS as a ‘proxy’ or ‘stub’ instance that simply communicates with the isolated version in prescribed ways.
And Hyper-V and VMware didn't work the same time until 2020, when VMware used Hyper-V Platform to co-exist with Hyper-V starting with Version 15.5.5.
How does VMware Workstation work before version 15.5.5?
VMware Workstation traditionally has used a Virtual Machine Monitor (VMM) which operates in privileged mode requiring direct access to the CPU as well as access to the CPU’s built in virtualization support (Intel’s VT-x and AMD’s AMD-V). When a Windows host enables Virtualization Based Security ("VBS") features, Windows adds a hypervisor layer based on Hyper-V between the hardware and Windows. Any attempt to run VMware’s traditional VMM fails because being inside Hyper-V the VMM no longer has access to the hardware’s virtualization support.
Introducing User Level Monitor
To fix this Hyper-V/Host VBS compatibility issue, VMware’s platform team re-architected VMware’s Hypervisor to use Microsoft’s WHP APIs. This means changing our VMM to run at user level instead of in privileged mode, as well modifying it to use the WHP APIs to manage the execution of a guest instead of using the underlying hardware directly.
What does this mean to you?
VMware Workstation/Player can now run when Hyper-V is enabled. You no longer have to choose between running VMware Workstation and Windows features like WSL, Device Guard and Credential Guard. When Hyper-V is enabled, ULM mode will automatically be used so you can run VMware Workstation normally. If you don’t use Hyper-V at all, VMware Workstation is smart enough to detect this and the VMM will be used.
System Requirements
To run Workstation/Player using the Windows Hypervisor APIs, the minimum required Windows 10 version is Windows 10 20H1 build 19041.264. VMware Workstation/Player minimum version is 15.5.5.
To avoid the error, update your Windows 10 to Version 2004/Build 19041 (Mai 2020 Update) and use at least VMware 15.5.5.
这篇关于VMware Workstation 和 Device/Credential Guard 不兼容的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
