[hyperv-next,0/6] Confidential VMBus

Message

Roman Kisel April 9, 2025, 12:08 a.m. UTC

Logically, there are two parts to this patch series:

1. The first part is to add the support for the confidential VMBus
   protocol, patches 1-4.
2. The second part is to avoid the bounce-buffering when the pages
   aren't shared with the host, patches 5-6.

Let us discuss the motivation and present the value proposition.

The guests running on Hyper-V can be confidential where the memory and the
register content are encrypted, provided that the hardware supports that
(currently AMD SEV-SNP and Intel TDX) and the guest is capable of using
these features. The confidential guests cannot be introspected by the host
nor the hypervisor without the guest sharing the memory contents upon doing
which the memory is decrypted.

In the confidential guests, neither the host nor the hypervisor need to be
trusted, and the guests processing sensitive data can take advantage of that.

Not trusting the host and the hypervisor (removing them from the Trusted
Computing Base aka TCB) ncessitates that the method of communication
between the host and the guest be changed. Below there is the breakdown of
the options used in the both cases (in the diagrams below the server is
marked as S, the client is marked as C):

1. Without the paravisoor the devices are connected to the host, and the
host provides the device emulation or translation to the guest:

+---- GUEST ----+       +----- DEVICE ----+        +----- HOST -----+
|               |       |                 |        |                |
|               |       |                 |        |                |
|               |       |                 ==========                |
|               |       |                 |        |                |
|               |       |                 |        |                |
|               |       |                 |        |                |
+----- C -------+       +-----------------+        +------- S ------+
       ||                                                   ||
       ||                                                   ||
+------||------------------ VMBus --------------------------||------+
|                     Interrupts, MMIO                              |
+-------------------------------------------------------------------+

2. With the paravisor, the devices are connected to the paravisor, and
the paravisor provides the device emulation or translation to the guest.
The guest doesn't communicate with the host directly, and the guest
communicates with the paravisor via the VMBus. The host is not trusted
in this model, and the paravisor is trusted:

+---- GUEST ------+                                   +-- DEVICE --+
|                 |                                   |            |
| +- PARAVISOR -+ |                                   |            |
| |             ==+====================================            |
| |   OpenHCL   | |                                   |            |
| |             | C=====================              |            |
+-+---- C - S --+-+                   ||              +------------+
        ||  ||                        ||
        ||  ||      +-- VMBus Relay --||--+           +--- HOST ---+
        ||  ||=======   Interrupts, MMIO  |           |            |
        ||          +---------------------+           +---- S -----+
        ||                                                  ||
+-------||----------------- VMBus --------------------------||------+
|                     Interrupts, MMIO                              |
+-------------------------------------------------------------------+

Note that in the second case the guest doesn't need to share the memory
with the host as it communicates only with the paravisor within their
partition boundary. That is precisely the raison d'etre and the value
proposition of this patch series: equip the confidential guest to use
private (encrypted) memory and rely on the paravisor when this is
available to be secure.

I'd like to thank the following people for their help with this
patch series:

- Dexuan for help with the patches 4-6, validation and the fruitful
  discussions,
- Easwar for reviewing the refactoring of the page allocating and
  freeing in `hv.c`,
- John and Sven for the design,
- Mike for helping to avoid pitfalls when dealing with the GFP flags,
- Sven for blazing the trail and implementing the design in few
  codebases.

Roman Kisel (6):
  Documentation: hyperv: Confidential VMBus
  drivers: hyperv: VMBus protocol version 6.0
  arch: hyperv: Get/set SynIC synth.registers via paravisor
  arch: x86, drivers: hyperv: Enable confidential VMBus
  arch, drivers: Add device struct bitfield to not bounce-buffer
  drivers: SCSI: Do not bounce-bufffer for the confidential VMBus

 Documentation/virt/hyperv/vmbus.rst |  41 +++
 arch/arm64/hyperv/mshyperv.c        |  19 ++
 arch/arm64/include/asm/mshyperv.h   |   3 +
 arch/x86/include/asm/mshyperv.h     |   3 +
 arch/x86/kernel/cpu/mshyperv.c      |  51 ++-
 arch/x86/mm/mem_encrypt.c           |   3 +
 drivers/hv/channel.c                |  36 ++-
 drivers/hv/channel_mgmt.c           |  29 +-
 drivers/hv/connection.c             |  10 +-
 drivers/hv/hv.c                     | 485 ++++++++++++++++++++--------
 drivers/hv/hyperv_vmbus.h           |   9 +-
 drivers/hv/ring_buffer.c            |   5 +-
 drivers/hv/vmbus_drv.c              | 152 +++++----
 drivers/scsi/storvsc_drv.c          |   2 +
 include/asm-generic/mshyperv.h      |   1 +
 include/linux/device.h              |   8 +
 include/linux/dma-direct.h          |   3 +
 include/linux/hyperv.h              |  71 ++--
 include/linux/swiotlb.h             |   3 +
 19 files changed, 696 insertions(+), 238 deletions(-)


base-commit: 628cc040b3a2980df6032766e8ef0688e981ab95