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

Date:   Wed, 13 Dec 2017 14:58:28 +0000
From:   Stefan Hajnoczi <stefanha@...hat.com>
To:     "Jorgen S. Hansen" <jhansen@...are.com>
Cc:     Dexuan Cui <decui@...rosoft.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: AF_VSOCK connection refused errno

On Wed, Dec 13, 2017 at 10:28:30AM +0000, Jorgen S. Hansen wrote:
> 
> > 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.

That's fine.  Thanks for confirming.

Stefan

Download attachment "signature.asc" of type "application/pgp-signature" (456 bytes)