Date: Fri, 04 Jul 2014 17:04:56 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-standards@FreeBSD.org Subject: [Bug 191586] FreeBSD doesn't validate negative edgecases in bind(2)/connect(2)/listen(2) like POSIX requires Message-ID: <bug-191586-15-cC2TFSUiGp@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-191586-15@https.bugs.freebsd.org/bugzilla/> References: <bug-191586-15@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191586 --- Comment #4 from Terry Lambert <lambert.tr@gmail.com> --- Since this isn't a "MAY", this is a "SHALL", I still *totally agree* with you that it's a missing mandatory check, and can't be ignored, but this is not necessarily the proper place for it, without the side effect testing. -- It's reasonable, but it would need some better testing. My initial objection to a "just make it all work" was only based on the unit test not testing what it claimed it was testing. -- Extra unit testing would be needed because doing the test in in_pcbbind_setup() like this also impacts other callers besides in_pcbbind(): in_pcbbind() in_pcbconnect_setup(() and, as a consequence, their callers: tcp_connect() <- this is where you want it to hit udp_output() udp6_bind() div_bind() <- specifically references that it will be passed a valid address ...and any other third party connection oriented protocols layered on top of IP. I also think that POSIX is not specifically concerned with AF_INET, so doing the check at this specific location might be simultaneously too narrow in scope. It's arguable that the check should actually be happening in a higher level protocol family function, or even based on protocol family metadata at one higher level than that, where the dispatch to the protocol family via AF_INET as the value got it into the protocol family code in the first place. In other words, the upper layer bind/connect code prior to the protocol dispatch, based on a "check address family first" bit in the protocol family descriptor. A valid argument against that approach might be that this would add general code path overhead for protocols that don't care/don't want the check by adding a single bit check and an interior dereference to get the flag bit and compare family, but it'd let you throw the right error for "AF_MAX + 10" EAFNOSUPPORT, which the code doesn't do, before or after the patch, in some circumstances. FFR: One of the reasons Mac OS X ignored optional ("MAY RETURN") error codes where they were not already implemented when we did the POSIX conformance certification was that overhead. A second reason we didn't add some simple checks we could have added was due to the fact that the behaviour was tied between APIs for the VSX test suite, i.e. you couldn't pick one "MAY" "here" and not pick it "there", and it can take 3-6 months to argue a test suite deficiency, and it's often more important to be compliant than right. NB: Sorry to be something of a downer on this; I was tech load on the Mac OS X POSIX conformance for Apple for the entire project, and there's a really narrow tight rope you have to walk between making as few changes as possible, and as many as absolutely necessary. I'm in the middle of moving my house right now, but I'm pretty sure I can be more genuinely helpful with actual code changes some time after that. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-191586-15-cC2TFSUiGp>