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

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 07/06/2016 10:31, Zack Weinberg wrote:
> 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.

I strongly disagree with this definition, the C library is still an
abstraction on underlying kernel and GLIBC should and follows POSIX
standards even when it deviates from the kernel primitives.  The same
idea of standard is what drove the various fixes on both math library
conformance and various primitives (quick_exit is an example).

And it is also why some from community view explicit exposing some
Linux primitives (such as gettid) to be a controversial subject.

But I do agree with that it *should* be fixed in kernel in the same
way it has fixed deviation from standard: by providing a new
syscall entry and by glibc using is directly.

> 
> (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.

I agree it is a minor deviation, but it is still a deviation I see no 
compelling reason to just continue to deviate from standard just because
it might not 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.

It is not the kernel that provides async-signal-safe, but rather the way
the underlying libc wrapper is programmed.  If we had an async-signal-safe
malloc, we could allocate an arbitrary copy buffer. And current wrappers 
does not call any non async-signal-safe functions. 

> 
>  * 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.

That's why I sent the second part of my fix as RFC and this part I think
it is the most controversial nit which I am not sure if the possible
breakage is worth.  I am proposing to use a large buffer to avoid 
issues on mostly usercases, but indeed it might not be suffice for some
rare cases.  But again, such cases I presume it would be rare and somewhat
easily fixable.

> 
>  * 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.

Again, I see to no problem in this scenario: the function prototype states
a constant cmsghdr and it will not change its state. Even if the ancillary
buffer might change, it is up to application to synchronize its access
and call sendmsg in a flow where the data is a consistent state.  I personally
see that calling a syscall with a buffer in racy condition does not make
sense.

 Contrived? Perhaps.
> Can we be sure no one will ever want to do something like that?  No, we
> cannot.
> 
> zw
>