Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   ebiederm@xmission.com (Eric W. Biederman)
To:     Alan Stern <stern@rowland.harvard.edu>
Cc:     linux-usb@vger.kernel.org,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Oliver Neukum <oneukum@suse.com>,
        <linux-kernel@vger.kernel.org>
References: <Pine.LNX.4.44L0.1905231352200.1553-100000@iolanthe.rowland.org>
Date:   Thu, 23 May 2019 15:54:26 -0500
In-Reply-To: <Pine.LNX.4.44L0.1905231352200.1553-100000@iolanthe.rowland.org>
        (Alan Stern's message of "Thu, 23 May 2019 14:12:57 -0400 (EDT)")
Message-ID: <87ef4oevst.fsf@xmission.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [PATCH] signal/usb: Replace kill_pid_info_as_cred with kill_pid_usb_asyncio
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Alan Stern <stern@rowland.harvard.edu> writes:

> On Wed, 22 May 2019, Eric W. Biederman wrote:
>
>> Perhaps this will work as a diagram.  I don't know if there is a better
>> way to say it in my patch description.  In struct siginfo there are 3
>> fields in fixed positions:
>> 
>>    int si_signo;
>>    int si_errno;
>>    int si_code;
>> 
>> After that there is a union.  The si_signo and si_code fields are
>> examined to see which union member is valid (see siginfo_layout).
>> In every other case a si_code of SI_ASYNCIO corresponds to
>> the the _rt union member which has the fields:
>> 
>>    int si_pid;
>>    int si_uid;
>>    sigval_t si_sigval;
>
> Yuu mean it's actually a union of structures containing these fields,
> not a union of these fields, right?

Correct.

>> However when usb started using SI_ASYNCIO the _sigfault union member
>> that (except for special exceptions) only has the field:
>> 
>>    void __user *si_addr;
>> 
>> Or in short the relevant piece of the union looks like:
>> 
>>          0   1  2   3    4   5   6  7
>>        +---+---+---+---+---+---+---+---+
>>        |    si_pid     |   si_uid      |
>>        +---+---+---+---+---+---+---+---+
>>        |             si_addr           | (64bit)
>>        +---+---+---+---+---+---+---+---+
>>        |     si_addr   | (32bit)
>>        +---+---+---+---+
>> 
>> Which means if siginfo is copied field by field on 32bit everything
>> works because si_pid and si_addr are in the same location.
>
> When you say "copied field by field", you mean that the si_pid, 
> si_uid, and si_sigval values are copied individually?

At least historically.  I have cleaned things up so no on native
we can do a byte by byte copy.  But for the compat case we still
copy field by field so that we have a chance of translating the fields.

>> Similarly if siginfo is copied field by field on 64bit everything
>> works because there is no padding between si_pid and si_uid. So
>> copying both of those fields results in the entire si_addr being
>> copied.
>> 
>> It is the compat case that gets tricky.  Half of the bits are
>> zero.  If those zero bits show up in bytes 4-7 and the data
>> shows up in bytes 0-3 (aka little endian) everything works.
>> If those zero bits show in in bytes 0-3 (aka big endian) userspace sees
>> a NULL pointer instead of the value it passed.
>
> The problem is that the compat translation layer copies si_pid and 
> si_uid from the 64-bit kernel structure to the 32-bit user structure.  
> And since the system is big-endian, the 64-bit si_addr value 
> has zeros in bytes 0-3.  But those zeros are what userspace ends up 
> seeing in its 32-bit version of si_addr.
>
> So the solution is to store the address in the si_sigval part instead.  
> Wouldn't it have been easier to have a compat routine somewhere just 
> do something like:
>
> 	sinfo->si_pid = (u32) sinfo->si_addr;  /* Compensate for USB */
>
> That would work regardless of the endianness, wouldn't it?

That logic will work yes.  That is essentially what I implemented in
proc_submiturb_compat:
	userurb_sigval.sival_int = ptr_to_compat(arg);

The practical problem is that we only know the compat status
of userspace when (a) the usb ioctl is called and when (b) the signal is
delivered to userspace.  We can't fix this a (b) because there is
too little information available due to the fact that glibc also
uses SI_ASYNCIO but with si_uid, si_pid, and si_siginfo. So we can't
just replace si_pid with sinfo->si_addr because si_pid and si_uid are
valid.

So we have to do something at (a) which is complicated by the fact
that we don't have siginfo yet.  So I choose to store a sigval_t
instead to just get the relevant bits.

>> Fixing this while maintaining some modicum of sanity is the tricky bit.
>> The interface is made to kill_pid_usb_asyncio is made a sigval_t so the
>> standard signal compat tricks can be used.  sigval_t is a union of:
>> 
>>         int sival_int;
>>         void __user *sival_ptr;
>> 
>>          0   1  2   3    4   5   6  7
>>        +---+---+---+---+---+---+---+---+
>>        |            sival_ptr          | (64bit)
>>        +---+---+---+---+---+---+---+---+ 
>>        |    sival_ptr  | (32bit)
>>        +---+---+---+---+
>>        |    sival_int  |
>>        +---+---+---+---+
>> 
>> The signal code solves the compat issues for sigval_t by storing the
>> 32bit pointers in sival_int.  So they meaningful bits are guaranteed to
>> be in the low 32bits, just like the 32bit sival_ptr.
>> 
>> After a bunch of build BUG_ONs to verify my reasonable assumptions
>> of but the siginfo layout are actually true, the code that generates
>> the siginfo just copies a sigval_t to si_pid.  And assumes the code
>> in the usb stack placed the pointer in the proper part of the sigval_t
>> when it read the information from userspace.
>> 
>> I don't know if that helps make it easy to understand but I figured I
>> would give it a shot.
>
> I think I understand now.  Thanks.

Welcome.  I am trying to make this stuff comprehensible.

Eric