I believe this bug is a duplicate of bug 1808977.

(In reply to Richard W.M. Jones from comment #2)
> I believe this bug is a duplicate of bug 1808977.

Sorry ignore that, it's not quite a duplicate because this is about
using Windows to network unlock the guest.  I believe this is basically
impossible unless someone comes up with a Linux client for this
Windows service, but we can leave this open ...

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

My apologies, this bug was closed in error by a process we do not
have any control over.  Reopening.

(In reply to Richard W.M. Jones from comment #3)

> I believe this is basically
> impossible unless someone comes up with a Linux client for this
> Windows service, but we can leave this open ...

It's unnecessary to leave this open; honestly.

I've read the high-level description of the feature at <https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-how-to-enable-network-unlock>.

Please refer to the diagram entitled "Bitlock Network Unlock process" there. Based on that, this is what libguestfs would have to do:

- Step#1: detect a Network Unlock protector in the BitLocker configuration. Currently done by Windows' UEFI boot manager, which is not open source. How a "Network Unlock protector in the BitLocker configuration" is represented is also not public -- note that this happens *before* disk decryption, so this is either represented on-disk in some tricky way, or even in a non-volatile UEFI variable.

- Step#3: send a vendor-specific DHCP request to the WDS server. The internals of this DHCP request are not documented.

- Step#6: parse the vendor-specific DHCP response form the WDS server. The internals of this response are not documented.

- Step#7: this step is actually what kills the idea *by design*. Namely, for unlocking the disk, the intermediate key parsed from the WDS response needs to be combined with *TPM state* (aka it needs to be "decrypted by the TPM"). Steps 1 through 6 in the protocol do not protect the disk from an attacker that physically steals (or copies) the disk, and then impersonates the original computer, talking to the DHCP and WDS servers. Step#7 is what prevents this impersonation attack: the disk encryption key is a derivative of both the WDS answer *and* the TPM state. And the TPM state on the original client computer encompasses basically the hardware configuration, the whole boot path, and so on. In this scenario, libguestfs is supposed to impersonate the original computer, but the TPM dependency, that is, step#7, is *specifically designed* by Microsoft to prevent that. Decrypting such a disk would only be possible *even in theory* if Microsoft were willing to expose an API for fetching secrets from their vTPM -- which they will obviously never do, as it would immediately undermine all their vTPM-based cloud security technologies, and become a fat target for attackers. Regarding virt-p2v in turn, the TPM in question would be a physical TPM (not a vTPM implemented by host-side software), which (again) is specifically designed and manufactured to prevent this kind of impersonation.

I'm closing this now as CANTFIX.