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

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

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

Like Carlos has pointed out, my idea is not blindly follow POSIX in any
statement, but rather discuss if each standard definition and interface
make sense to implement or not in glibc. Now, I see that not only
conformance, but also compatibility is a goal GLIBC is aim to provide.
I do not see the case that I should provide a real program, mostly
because real programs either will fix the system difference by 
themselves.

Now related this specific issue: BZ#16919 was opened in 2014 and there
was some discussion in the way it should be fixed in GLIBC. Now, what 
you are advocating is we should close it as WONTFIX, keep the documentation
that GLIBC does not follow the standard and state that we won't fix
it in GLIBC.

I personally do not oppose for this course of action, but we need
*consensus*. What I do not agree is to GLIBC also blindly follow kernel
interfaces, even when they differ from POSIX or any other standard
GLIBC aims to follow.

But I do agree that libsanitizer breakage it is something we should 
consider, even if relies on implementation details not exposed by the API.
That why I talked with Carlos en Joseph at IRC (and my mistake here,
I should have brought it on maillist as well). And my understanding
it is still desirable to push this fix.

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

I mean that the way libsanitizer couple with GLIBC requires to know
internal specific details that is not part of the ABI/exported
interfaces. And also it is possible to hook on libc provided symbols
with some sanitizer changes, so stating this change breaks libsanitizer
is not a strong reason to block this fix IMHO.

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

Because EMACS uses a defined ABI/interface GLIBC aimed to exposed.
The Florian specific one is another bug [1].

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=14932

> 
>>> 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?

It is not 'nobody should do that', it is 'this interface you described
do not make sense'.