RE: [PATCH hyperv-next v2 1/4] Documentation: hyperv: Confidential VMBus
> From: Roman Kisel Sent: Sunday, May 11, 2025 > 4:08 PM >> >> Define what the confidential VMBus is and describe what advantages >> it offers on the capable hardware. >> >> Signed-off-by: Roman Kisel >> --- >> Documentation/virt/hyperv/vmbus.rst | 41 + >> 1 file changed, 41 insertions(+) >> >> diff --git a/Documentation/virt/hyperv/vmbus.rst >> b/Documentation/virt/hyperv/vmbus.rst >> index 1dcef6a7fda3..ca2b948e5070 100644 >> --- a/Documentation/virt/hyperv/vmbus.rst >> +++ b/Documentation/virt/hyperv/vmbus.rst >> @@ -324,3 +324,44 @@ rescinded, neither Hyper-V nor Linux retains any state >> about >> its previous existence. Such a device might be re-added later, >> in which case it is treated as an entirely new device. See >> vmbus_onoffer_rescind(). >> + >> +Confidential VMBus >> +-- >> + >> +The confidential VMBus provides the control and data planes where >> +the guest doesn't talk to either the hypervisor or the host. Instead, >> +it relies on the trusted paravisor. The hardware (SNP or TDX) encrypts >> +the guest memory and the register state also measuring the paravisor >> +image via using the platform security processor to ensure trusted and >> +confidential computing. >> + >> +To support confidential communication with the paravisor, a VMBus client >> +will first attempt to use regular, non-isolated mechanisms for >> communication. >> +To do this, it must: >> + >> +* Configure the paravisor SIMP with an encrypted page. The paravisor SIMP is >> + configured by setting the relevant MSR directly, without using GHCB or >> tdcall. >> + >> +* Enable SINT 2 on both the paravisor and hypervisor, without setting the >> proxy >> + flag on the paravisor SINT. Enable interrupts on the paravisor SynIC. >> + >> +* Configure both the paravisor and hypervisor event flags page. >> + Both pages will need to be scanned when VMBus receives a channel >> interrupt. >> + >> +* Send messages to the paravisor by calling HvPostMessage directly, without >> using >> + GHCB or tdcall. >> + >> +* Set the EOM MSR directly in the paravisor, without using GHCB or tdcall. >> + >> +If sending the InitiateContact message using non-isolated HvPostMessage >> fails, >> +the client must fall back to using the hypervisor synic, by using the >> GHCB/tdcall >> +as appropriate. >> + >> +To fall back, the client will have to reconfigure the following: >> + >> +* Configure the hypervisor SIMP with a host-visible page. >> + Since the hypervisor SIMP is not used when in confidential mode, >> + this can be done up front, or only when needed, whichever makes sense for >> + the particular implementation. >> + >> +* Set the proxy flag on SINT 2 for the paravisor. > >I'm assuming there's no public documentation available for how Confidential >VMBus works. If so, then this documentation needs to take a higher-level >approach and explain the basic concepts. You've provided some nitty-gritty >details about how to detect and enable Confidential VMBus, but I think that >level of detail would be better as comments in the code. > >Here's an example of what I envision, with several embedded questions that >need further explanation. Confidential VMBus is completely new to me, so >I don't know the answers to the questions. I also think this documentation >would be better added to the CoCo VM topic instead of the VMBus topic, as >Confidential VMBus is an extension/enhancement to CoCo VMs that doesn't >apply to normal VMs. > >-- > >Confidential VMBus is an extension of Confidential Computing (CoCo) VMs >(a.k.a. "Isolated" VMs in Hyper-V terminology). Without Confidential VMBus, >guest VMBus device drivers (the "VSC"s in VMBus terminology) communicate >with VMBus servers (the VSPs) running on the Hyper-V host. The >communication must be through memory that has been decrypted so the >host can access it. With Confidential VMBus, one or more of the VSPs reside >in the trusted paravisor layer in the guest VM. Since the paravisor layer also >operates in encrypted memory, the memory used for communication with >such VSPs does not need to be decrypted and thereby exposed to the >Hyper-V host. The paravisor is responsible for communicating securely >with the Hyper-V host as necessary. [Does the paravisor do this in a way >that is better than what the guest can do? This question seems to be core to >the value prop for Confidential VMBus. I'm not really clear on the value >prop.] > >A guest that is running with a paravisor must determine at runtime if >Confidential VMBus is supported by the current paravisor. It does so by first >trying to establish a Confidential VMBus connection with the paravisor using >standard mechanisms where the memory remains encrypted. If this succeeds, >then the guest can proceed to use Confidential VMBus. If it fails, then the >guest must fallback to establishing a non-Confidential VMBus connection with >the Hyper-V host. > >Confident
RE: [PATCH hyperv-next v2 1/4] Documentation: hyperv: Confidential VMBus
From: Roman Kisel Sent: Sunday, May 11, 2025 4:08 PM > > Define what the confidential VMBus is and describe what advantages > it offers on the capable hardware. > > Signed-off-by: Roman Kisel > --- > Documentation/virt/hyperv/vmbus.rst | 41 + > 1 file changed, 41 insertions(+) > > diff --git a/Documentation/virt/hyperv/vmbus.rst > b/Documentation/virt/hyperv/vmbus.rst > index 1dcef6a7fda3..ca2b948e5070 100644 > --- a/Documentation/virt/hyperv/vmbus.rst > +++ b/Documentation/virt/hyperv/vmbus.rst > @@ -324,3 +324,44 @@ rescinded, neither Hyper-V nor Linux retains any state > about > its previous existence. Such a device might be re-added later, > in which case it is treated as an entirely new device. See > vmbus_onoffer_rescind(). > + > +Confidential VMBus > +-- > + > +The confidential VMBus provides the control and data planes where > +the guest doesn't talk to either the hypervisor or the host. Instead, > +it relies on the trusted paravisor. The hardware (SNP or TDX) encrypts > +the guest memory and the register state also measuring the paravisor > +image via using the platform security processor to ensure trusted and > +confidential computing. > + > +To support confidential communication with the paravisor, a VMBus client > +will first attempt to use regular, non-isolated mechanisms for communication. > +To do this, it must: > + > +* Configure the paravisor SIMP with an encrypted page. The paravisor SIMP is > + configured by setting the relevant MSR directly, without using GHCB or > tdcall. > + > +* Enable SINT 2 on both the paravisor and hypervisor, without setting the > proxy > + flag on the paravisor SINT. Enable interrupts on the paravisor SynIC. > + > +* Configure both the paravisor and hypervisor event flags page. > + Both pages will need to be scanned when VMBus receives a channel interrupt. > + > +* Send messages to the paravisor by calling HvPostMessage directly, without > using > + GHCB or tdcall. > + > +* Set the EOM MSR directly in the paravisor, without using GHCB or tdcall. > + > +If sending the InitiateContact message using non-isolated HvPostMessage > fails, > +the client must fall back to using the hypervisor synic, by using the > GHCB/tdcall > +as appropriate. > + > +To fall back, the client will have to reconfigure the following: > + > +* Configure the hypervisor SIMP with a host-visible page. > + Since the hypervisor SIMP is not used when in confidential mode, > + this can be done up front, or only when needed, whichever makes sense for > + the particular implementation. > + > +* Set the proxy flag on SINT 2 for the paravisor. I'm assuming there's no public documentation available for how Confidential VMBus works. If so, then this documentation needs to take a higher-level approach and explain the basic concepts. You've provided some nitty-gritty details about how to detect and enable Confidential VMBus, but I think that level of detail would be better as comments in the code. Here's an example of what I envision, with several embedded questions that need further explanation. Confidential VMBus is completely new to me, so I don't know the answers to the questions. I also think this documentation would be better added to the CoCo VM topic instead of the VMBus topic, as Confidential VMBus is an extension/enhancement to CoCo VMs that doesn't apply to normal VMs. -- Confidential VMBus is an extension of Confidential Computing (CoCo) VMs (a.k.a. "Isolated" VMs in Hyper-V terminology). Without Confidential VMBus, guest VMBus device drivers (the "VSC"s in VMBus terminology) communicate with VMBus servers (the VSPs) running on the Hyper-V host. The communication must be through memory that has been decrypted so the host can access it. With Confidential VMBus, one or more of the VSPs reside in the trusted paravisor layer in the guest VM. Since the paravisor layer also operates in encrypted memory, the memory used for communication with such VSPs does not need to be decrypted and thereby exposed to the Hyper-V host. The paravisor is responsible for communicating securely with the Hyper-V host as necessary. [Does the paravisor do this in a way that is better than what the guest can do? This question seems to be core to the value prop for Confidential VMBus. I'm not really clear on the value prop.] A guest that is running with a paravisor must determine at runtime if Confidential VMBus is supported by the current paravisor. It does so by first trying to establish a Confidential VMBus connection with the paravisor using standard mechanisms where the memory remains encrypted. If this succeeds, then the guest can proceed to use Confidential VMBus. If it fails, then the guest must fallback to establishing a non-Confidential VMBus connection with the Hyper-V host. Confidential VMBus is a characteristic of the VMBus connection as a whole, and of each VMBus channel that is created. When a C
Re: [PATCH hyperv-next v2 1/4] Documentation: hyperv: Confidential VMBus
On 5/11/2025 10:22 PM, ALOK TIWARI wrote: On 12-05-2025 04:37, Roman Kisel wrote: Define what the confidential VMBus is and describe what advantages it offers on the capable hardware. Signed-off-by: Roman Kisel --- Documentation/virt/hyperv/vmbus.rst | 41 + 1 file changed, 41 insertions(+) diff --git a/Documentation/virt/hyperv/vmbus.rst b/Documentation/virt/ hyperv/vmbus.rst index 1dcef6a7fda3..ca2b948e5070 100644 --- a/Documentation/virt/hyperv/vmbus.rst +++ b/Documentation/virt/hyperv/vmbus.rst @@ -324,3 +324,44 @@ rescinded, neither Hyper-V nor Linux retains any state about its previous existence. Such a device might be re-added later, in which case it is treated as an entirely new device. See vmbus_onoffer_rescind(). + +Confidential VMBus +-- + The purpose and benefits of the Confidential VMBus are not clearly stated. for example: "Confidential VMBus provides a secure communication channel between guest and paravisor, ensuring that sensitive data is protected from hypervisor-level access through memory encryption and register state isolation." +The confidential VMBus provides the control and data planes where +the guest doesn't talk to either the hypervisor or the host. Instead, +it relies on the trusted paravisor. The hardware (SNP or TDX) encrypts +the guest memory and the register state also measuring the paravisor s/alos/while and s/via using/using "register state while measuring the paravisor image using the platform security" +image via using the platform security processor to ensure trusted and +confidential computing. + +To support confidential communication with the paravisor, a VMBus client +will first attempt to use regular, non-isolated mechanisms for communication. +To do this, it must: + +* Configure the paravisor SIMP with an encrypted page. The paravisor SIMP is + configured by setting the relevant MSR directly, without using GHCB or tdcall. + +* Enable SINT 2 on both the paravisor and hypervisor, without setting the proxy + flag on the paravisor SINT. Enable interrupts on the paravisor SynIC. + +* Configure both the paravisor and hypervisor event flags page. + Both pages will need to be scanned when VMBus receives a channel interrupt. + +* Send messages to the paravisor by calling HvPostMessage directly, without using + GHCB or tdcall. + +* Set the EOM MSR directly in the paravisor, without using GHCB or tdcall. + +If sending the InitiateContact message using non-isolated HvPostMessage fails, +the client must fall back to using the hypervisor synic, by using the GHCB/tdcall +as appropriate. + +To fall back, the client will have to reconfigure the following: + +* Configure the hypervisor SIMP with a host-visible page. + Since the hypervisor SIMP is not used when in confidential mode, + this can be done up front, or only when needed, whichever makes sense for + the particular implementation. "SIMP is not used in confidential mode, this can be done either upfront or only when needed, depending on the specific implementation." + +* Set the proxy flag on SINT 2 for the paravisor. Alok, thanks for you continued interest and support! I'll incorporate your suggestions in the next version of the patchset, great points! Thanks, Alok -- Thank you, Roman
Re: [PATCH hyperv-next v2 1/4] Documentation: hyperv: Confidential VMBus
On 12-05-2025 04:37, Roman Kisel wrote: Define what the confidential VMBus is and describe what advantages it offers on the capable hardware. Signed-off-by: Roman Kisel --- Documentation/virt/hyperv/vmbus.rst | 41 + 1 file changed, 41 insertions(+) diff --git a/Documentation/virt/hyperv/vmbus.rst b/Documentation/virt/hyperv/vmbus.rst index 1dcef6a7fda3..ca2b948e5070 100644 --- a/Documentation/virt/hyperv/vmbus.rst +++ b/Documentation/virt/hyperv/vmbus.rst @@ -324,3 +324,44 @@ rescinded, neither Hyper-V nor Linux retains any state about its previous existence. Such a device might be re-added later, in which case it is treated as an entirely new device. See vmbus_onoffer_rescind(). + +Confidential VMBus +-- + The purpose and benefits of the Confidential VMBus are not clearly stated. for example: "Confidential VMBus provides a secure communication channel between guest and paravisor, ensuring that sensitive data is protected from hypervisor-level access through memory encryption and register state isolation." +The confidential VMBus provides the control and data planes where +the guest doesn't talk to either the hypervisor or the host. Instead, +it relies on the trusted paravisor. The hardware (SNP or TDX) encrypts +the guest memory and the register state also measuring the paravisor s/alos/while and s/via using/using "register state while measuring the paravisor image using the platform security" +image via using the platform security processor to ensure trusted and +confidential computing. + +To support confidential communication with the paravisor, a VMBus client +will first attempt to use regular, non-isolated mechanisms for communication. +To do this, it must: + +* Configure the paravisor SIMP with an encrypted page. The paravisor SIMP is + configured by setting the relevant MSR directly, without using GHCB or tdcall. + +* Enable SINT 2 on both the paravisor and hypervisor, without setting the proxy + flag on the paravisor SINT. Enable interrupts on the paravisor SynIC. + +* Configure both the paravisor and hypervisor event flags page. + Both pages will need to be scanned when VMBus receives a channel interrupt. + +* Send messages to the paravisor by calling HvPostMessage directly, without using + GHCB or tdcall. + +* Set the EOM MSR directly in the paravisor, without using GHCB or tdcall. + +If sending the InitiateContact message using non-isolated HvPostMessage fails, +the client must fall back to using the hypervisor synic, by using the GHCB/tdcall +as appropriate. + +To fall back, the client will have to reconfigure the following: + +* Configure the hypervisor SIMP with a host-visible page. + Since the hypervisor SIMP is not used when in confidential mode, + this can be done up front, or only when needed, whichever makes sense for + the particular implementation. "SIMP is not used in confidential mode, this can be done either upfront or only when needed, depending on the specific implementation." + +* Set the proxy flag on SINT 2 for the paravisor. Thanks, Alok
