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

[Zack Weinberg <zackw at panix dot com>]

On Wed, Jun 8, 2016 at 4:57 PM, Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
> On 08/06/2016 17:15, Zack Weinberg wrote:
>> On Tue, Jun 7, 2016 at 10:21 AM, Adhemerval Zanella
>> <adhemerval.zanella@linaro.org> wrote:
>>> On 07/06/2016 10:31, Zack Weinberg wrote:
>>>>
>>>> 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*.
...
>> You are going to have a very hard time persuading me to change my
>> position, and this ain't gonna do it. This is circular logic.  "We
>> should follow POSIX because we should follow POSIX."
>>
>> I would consider a real (not made up for the purpose, and ideally,
>> already existing) program that is broken by not having these types be
>> as POSIX specifies to be a *valid argument* for changing the types,
>> but even that might not be a *persuasive* argument for changing the
>> types[.]
...
>> What would persuade you to accept *my* position on this issue?
>
> I am stating we follow POSIX to very reason we follow other technical
> standard: to provide libc compatibility.

This is not a response to my argument.

I said that I consider faithfully exposing all the true kernel
interfaces to be MORE IMPORTANT than following POSIX.  I also told you
what I would consider to be a valid (but not necessarily persuasive)
argument against my position: exhibit a real program that is broken by
this conformance deviation.

You respond by reiterating that following POSIX is important in the
abstract.  Sure, but I still think that faithfully exposing all the
true kernel interfaces is *more* important.  You give a reason why
it's important in the abstract: to provide compatibility with other
systems.  Sure, but for that to have any persuasive force at all, you
need to exhibit a real program that cares.

And I would still like to know what could persuade *you* to agree with
*me*; maybe then I could actually present that.

> And the breakage Florian has pointed (and I replied) is a very
> specific one that also require the interposing library to know a
> very deal of the interposed library.  This kind of tooling is highly
> coupled with implementation and there are various hacks and slight
> breakages that minor GLIBC changes already incurred (for instance
> on libsanitizer, every TCB size change needs to be explicit take
> in account).

I'm sorry, I have not been able to make any sense whatsoever out of
this paragraph.

> And I do not see the tooling breakage as compelling reason to break
> interface changes and fixes.

If you're trying to say that you think the breakage Florian cited is
too unusual to worry about, I cannot agree with that.  We're bending
over backward to keep old Emacs binaries working that depended on
glibc-specific details of the malloc implementation -- interposition
of network APIs is commonplace by comparison.

(I also suspect that this *can't* be easily papered over by messing
with the semantics of dlsym() -- see upcoming reply to Carlos.)

>> You clearly still don't get it.  It's not about the buffer being in a
>> racy condition.  It's that the *address might be part of the message.*
>> "Nobody should do that" is NOT a valid objection, because this is an
>> arbitrarily extensible interface.
>>
>> Let me try again with another example.
[...]
> This very interface does not make sense

What part of '"Nobody should do that" is NOT a valid objection' was
unclear?

zw