Re: [PATCH 2/3] network: recvmsg and sendmsg standard compliance (BZ#16919)

[Zack Weinberg <zackw@panix.com>]

On 03/28/2016 10:34 AM, Adhemerval Zanella wrote:
> POSIX specifies that both msghdr::msg_iovlen and msghdr::msg_controllen
> to be of size int and socklen_t respectively.  However Linux defines it as
> both size_t and for 64-bit it requires some adjustments to make the
> functions standard compliance.

I expressed objections to the follow-up patch to this (tackling the same
type inconsistency within cmsgbuf) and, on reflection, my objection
applies as well (with somewhat less force) to this patch, so I'm going
to explain myself once here.

send/recv(m)msg are kernel primitives, and the fundamental basis of my
objection is that I think the C library should always faithfully expose
all the true kernel interfaces, *even if they are in some way wrong*.
This conformance violation should be addressed by the kernel first, and
only then should the C library follow suit.  That means that neither
this patch, nor the follow-up patch tackling cmsgbuf, should be applied
at all.  If either has already been applied, they should be backed out.

(If the kernel developers refuse to fix a conformance violation, then
that kernel has chosen to permanently deviate from the standard and,
again, the C library should faithfully reflect that.)

This objection has extra force under four circumstances all of which
apply to send/recv(m)msg:

 * The problem is a minor deviation from a standard and is unlikely to
   affect non-contrived programs.

 * The kernel primitives in question are async-signal-safe; that is a
   difficult contract to uphold in user space -- the more work the C
   library does, the more likely it is to screw something up.

 * A completely transparent user-space workaround would need to allocate
   memory.  In this case, it is my considered opinion that the proposed
   hard upper limit on the size of cmsgbuf is *far* more likely to break
   existing programs than leaving the status quo alone.

 * The kernel primitives in question are arbitrarily extensible, so it
   is not possible to guarantee that a user-space workaround cannot
   break future additions to the interface.

Earlier, I said that I didn't like copying cmsgbuf because it wasn't
possible to be sure that no cmsg opcodes cared (now or in the future)
about the address of the buffer, and Adhemerval said (effectively) that
such an opcode would not make sense.  That's not true.  Imagine, if you
will, a cmsg that expects the ancillary buffer to be overlaid on a
shared memory area, and rewrites the *non*-ancillary buffer to reflect
the location of that memory area in the receiver. Contrived? Perhaps.
Can we be sure no one will ever want to do something like that?  No, we
cannot.

zw