linux-kernel - Re: [PATCH v4 1/2] dt-bindings: microsoft: Add vmbus message-connection-id property

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6d3b5d1e-de1b-4d3b-ba14-7029c51b8e05@kernel.org>
Date: Wed, 23 Jul 2025 08:18:17 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Hardik Garg <hargar@...ux.microsoft.com>
Cc: apais@...rosoft.com, conor+dt@...nel.org, decui@...rosoft.com,
 devicetree@...r.kernel.org, haiyangz@...rosoft.com, hargar@...rosoft.com,
 krzk+dt@...nel.org, kys@...rosoft.com, linux-hyperv@...r.kernel.org,
 linux-kernel@...r.kernel.org, robh@...nel.org, ssengar@...ux.microsoft.com,
 wei.liu@...nel.org, cho@...rosoft.com
Subject: Re: [PATCH v4 1/2] dt-bindings: microsoft: Add vmbus
 message-connection-id property

On 23/07/2025 05:08, Hardik Garg wrote:
>> Host is supposed to have multiple guests, so this feels like you are
>> going to prepare for each guest different DTS with different connection
>> ID. This feels like poor design. DTS is supposed to be relatively static
>> configuration, not runtime choice vmguestid+1.
> 
>> The guest cannot access other configuration channels, can it? If it can,
>> it would mean it can eavesdrop on other guests? So obviously it cannot.
>> Therefore from guest point of view this is completely redundant. Guest
>> cannot use any other value, thus guest should not configure it. The
>> guest has only one channel and uses only this one which gets to right
>> place to the host.
> 
> Thank you for your feedback. Let me explain the connection ID in more detail:
> 
> 1. Message Port Architecture:
>    - The connection ID specifies which Hyper-V hypervisor message port (mailbox slot) to use for communication between the host and guest
>    - The hypervisor has multiple message ports, but historically VMBus only used one
>    - With the introduction of VTL2 (Virtual Trust Level 2), the control plane can now be hosted in VTL2, requiring different message ports for communication
> 
> 2. Control Plane Communication:
>    - The VMBus control plane on the host needs to communicate with the VMBus driver in the guest
>    - When the control plane is hosted in VTL2, it requires a different message port than the standard communication path
>    - The connection ID tells the guest whether to use the standard or alternate message port for this control plane communication
> 
> 3. Message Processing:
>    - Each message is tagged with an ID
>    - If the guest uses an incorrect ID, the host won't recognize the message and will drop it
>    - This is not about choosing between multiple available channels - it's about using the correct mailbox slot for communication
> 

Don't paste me specs in response to questions, but answer specific
questions.

> 4. Security and Isolation:
>    - Each guest has its private hypervisor mailbox
>    - Multiple guests using the same connection ID cannot interfere with each other

Then all guests can use the same value, 0, making this property redundant.

>    - The connection ID is more like a "root ID" that helps enumerate devices on the bus, not a channel selector between guests
> 
> 5. Dynamic Nature:
>    - The connection ID is specified when the guest starts running
>    - The host can change it during VM lifecycle events (reset/reboot)

So not suitable for DT. DT is a static data. You cannot just keep
changing existing DT to match whatever you want runtime.

>    - This is why the VMBus driver needs to know the connection ID every time the kernel starts
>    - The ID might be different from what it was during the last guest run
Best regards,
Krzysztof