linux-kernel - Re: [PATCH] af_unix: Allow Unix sockets to raise SIGURG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e1047be3-2d53-49d3-67b4-a2a99e0c0f0f@oracle.com>
Date:   Fri, 29 Jan 2021 12:44:44 -0800
From:   Shoaib Rao <rao.shoaib@...cle.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     "Matthew Wilcox (Oracle)" <willy@...radead.org>,
        linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
        netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
        andy.rudoff@...el.com
Subject: Re: [PATCH] af_unix: Allow Unix sockets to raise SIGURG


On 1/29/21 12:18 PM, Jakub Kicinski wrote:
> On Fri, 29 Jan 2021 12:10:21 -0800 Shoaib Rao wrote:
>> On 1/29/21 12:02 PM, Jakub Kicinski wrote:
>>> On Fri, 29 Jan 2021 11:48:15 -0800 Shoaib Rao wrote:
>>>> Data was discarded because the flag was not supported, this patch
>>>> changes that but does not support any urgent data.
>>> When you say it does not support any urgent data do you mean the
>>> message len must be == 0 because something is checking it, or that
>>> the code does not support its handling?
>>>
>>> I'm perfectly fine with the former, just point me at the check, please.
>> The code does not care about the size of data -- All it does is that if
>> MSG_OOB is set it will deliver the signal to the peer process
>> irrespective of the length of the data (which can be zero length). Let's
>> look at the code of unix_stream_sendmsg() It does the following (sent is
>> initialized to zero)
> Okay. Let me try again. AFAICS your code makes it so that data sent
> with MSG_OOB is treated like any other data. It just sends a signal.
Correct.
> So you're hijacking the MSG_OOB to send a signal, because OOB also
> sends a signal.
Correct.
>   But there is nothing OOB about the data itself.
Correct.
>   So
> I'm asking you to make sure that there is no data in the message.
Yes I can do that.
> That way when someone wants _actual_ OOB data on UNIX sockets they
> can implement it without breaking backwards compatibility of the
> kernel uAPI.

I see what you are trying to achieve. However it may not work.

Let's assume that __actual__ OOB data has been implemented. An 
application sends a zero length message with MSG_OOB, after that it 
sends some data (not suppose to be OOB data). How is the receiver going 
to differentiate if the data an OOB or not.

We could use a different flag (MSG_SIGURG) or implement the _actual_ OOB 
data semantics (If anyone is interested in it). MSG_SIGURG could be a 
generic flag that just sends SIGURG irrespective of the length of the data.

Shoaib

>
>> while (sent < len) {
>>                   size = len - sent;
>> <..>
>>
>> }
>>
>>           if (msg->msg_flags & MSG_OOB)
>>                   sk_send_sigurg(other);
>>
>> Before the patch there was a check above the while loop that checked the
>> flag and returned and error, that has been removed.