[Bug 191586] FreeBSD doesn't validate negative edgecases in bind(2)/connect(2)/listen(2) like POSIX requires

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191586

--- Comment #4 from Terry Lambert <lambert.tr at 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.