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] [day] [month] [year] [list]

Message-ID: <69ed5b38-830d-46d7-a84b-86787c39df7d@kernel.org>
Date: Wed, 5 Nov 2025 07:55:53 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Hardik Garg <hargar@...ux.microsoft.com>
Cc: apais@...rosoft.com, cho@...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
Subject: Re: [PATCH v4 1/2] dt-bindings: microsoft: Add vmbus
 message-connection-id property

On 05/11/2025 02:10, Hardik Garg wrote:
> 
> Each guest has a private hypervisor mailbox and cannot access any other
> guest’s communication path. Using an incorrect connection ID does not
> allow eavesdropping or cause interference — it only results in failed
> VMBus initialization because the host drops messages sent to an
> unexpected port. Thus, exposing the correct connection ID to the guest
> is safe and necessary for correct initialization.
> 
>> If different values are important for the host, then all guests should
>> use whatever 0 which will map to different values on host by other means
>> of your protocol.
>>
> 
> Using a fixed value such as 0 for all guests would not work, because the
> Hyper-V host differentiates between multiple control-plane contexts (for
> example, VTL0 vs VTL2) using distinct connection IDs. The guest must use
> the value assigned by the host, as there is no implicit mapping or
> negotiation protocol to determine it otherwise.

Sorry, I am not going back to three months old discussion.

Therefore I close this topic for me with: since the actual value does
not matter for the host - it will discard all messages which are not
intended to this guest - you can just use value 0 and your hypervisor
will map to proper port.

Best regards,
Krzysztof