VmBus: add OpenHCL support for confidential external memory in a CVM

[SvenGroot]

This change adds a new offer flag which indicates that a device can use encrypted memory for additional GPADLs (other than the ring buffer) and GPA Direct packets. VmBus devices can specify they are capable of using encrypted memory when they create a new offer, and the flag will be sent to the guest if the guest uses the confidential_channels feature flag.

Since there are currently no devices that support this feature, an environment variable is added to force the use of encrypted memory for all non-relay channels. This works with the NVMe driver (which can perform bounce buffering in OpenHCL), but if used with the MANA driver it will cause OpenHCL to crash. Enabling this option with a Windows or UEFI client that supports confidential channels but has not been updated to support the new flag will also cause issues.

This change also updates the policy regarding confidential and host-visible memory to enforce that the correct type is used by the guest. If an offer uses the confidential ring or confidential external memory flags, the guest is now required to actually use encrypted memory for the respective buffers.

[mattkur]

Looks good from storage side. Do you have some more context in where this change is heading?

[SvenGroot]

@mattkur From VmBus's side, this change is now complete. Once we have devices that support using encrypted memory (because the hardware supports it, or because they wish to do bounce buffering in OpenHCL), they can set the allow_confidential_external_memory flag in their offer to indicate to VmBus they support this behavior.

[jstarks]

I think we will also want to improve the double buffering story so that devices don't have to individually implement double buffering code. Even without TDISP, there may be configurations where we prefer double buffering for security, e.g. to get the netvsc control messages and packet descriptor headers out of shared memory.