netdev - Re: AF_VSOCK connection refused errno

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: <7CCDA4D3-7683-4E5C-95ED-97B2FC9DFF33@vmware.com>
Date:   Wed, 13 Dec 2017 10:28:30 +0000
From:   "Jorgen S. Hansen" <jhansen@...are.com>
To:     Stefan Hajnoczi <stefanha@...hat.com>
CC:     Dexuan Cui <decui@...rosoft.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: AF_VSOCK connection refused errno


> On Dec 12, 2017, at 4:53 PM, Stefan Hajnoczi <stefanha@...hat.com> wrote:
> 
> When connect(2) fails because the peer is not listening the virtio vsock
> transport returns ECONNRESET.  I believe the VMCI transport does the
> same (based on code inspection).
> 
> Jorgen: Can you confirm this VMCI transport behavior?

Yes, that is correct.

> I'd like to change to ECONNREFUSED for all transports because developers
> will be surprised when they get ECONNRESET.  It makes porting AF_INET
> code harder.
> 
> On the other hand, it may be too late to fix this if there userspace
> applications that rely on ECONNRESET?  I'm not aware of any such
> applications myself.

In the past, I’ve explained to customers that an ECONNRESET error on connect
can indicate that the peer isn’t listening on the dest address. Whether they went
and used that information isn’t clear, but changing this behavior now would
risk breaking applications. While it is unfortunate that we deviate from INET in
this case, I would prefer it to stay as is.

Thanks,
Jorgen