From: chenfeng <puck.chen@hisilicon.com>
To: David Rientjes <rientjes@google.com>
Cc: <gregkh@linuxfoundation.org>, <arve@android.com>,
<riandrews@android.com>, <devel@driverdev.osuosl.org>,
<linux-kernel@vger.kernel.org>, <yudongbin@hisilicon.com>,
<saberlily.xia@hisilicon.com>, <suzhuangluan@hisilicon.com>,
<kong.kongxinwei@hisilicon.com>, <xuyiping@hisilicon.com>,
<z.liuxinliang@hisilicon.com>, <weidong2@hisilicon.com>,
<w.f@huawei.com>, <puck.chen@foxmail.com>,
<shimingxing@hisilicon.com>, <oliver.fu@hisilicon.com>,
<albert.lubing@hisilicon.com>, <chenxiang9@huawei.com>,
<liuzixing@huawei.com>, <haojian.zhuang@linaro.org>,
<zhaojunmin@huawei.com>, <wangjing6@huawei.com>,
<john.stultz@linaro.org>, <qijiwen@hisilicon.com>,
<peter.panshilin@hisilicon.com>, <dan.zhao@hisilicon.com>,
<linuxarm@huawei.com>, <dev@lists.96boards.org>
Subject: Re: [PATCH v2] android: binder: Sanity check at binder ioctl
Date: Thu, 28 Jan 2016 15:08:22 +0800 [thread overview]
Message-ID: <56A9BE66.80400@hisilicon.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1601191436370.7346@chino.kir.corp.google.com>
Hi,
On 2016/1/20 6:40, David Rientjes wrote:
> On Tue, 19 Jan 2016, Chen Feng wrote:
>
>> When a process fork a child process, we should not allow the
>> child process use the binder which opened by parent process.
>>
>> But if the binder-object creater is a thread of one process who exit,
>> the other thread can also use this binder-object normally.
>> We can distinguish this by the member proc->tsk->mm.
>> If the thread exit the tsk->mm will be NULL.
>>
>
> Why does exit_mm(), the point where tsk->mm == NULL, signify the point at
> which the binder can now be used by other threads?
Yes,the other threads used this shared mm for communication. A lots of APPs
have this issue.
For example: system_server process use many libs,libstagefright, Libdrmframeworketc,
In these lib, binder global object exist like static sp<DeathNotifier> sDeathNotifier,
static sp<IDrmManagerService> sDrmManagerService;
When system_sever process fork failed, the new child process call exit, which will call
hook destruction function.
In destruction, the parent process *binder reference count will be wrong*. To protect
these exception, we need to add the code in binder.
For v2 patch, I agree with your opinion, some race condition exist in some special case.
I found that the task->mm already cached at binder_mm.
proc->vma_vm_mm = vma->vm_mm;
I will change the condition to if (unlikely(current->mm != proc->tsk->mm)).
But in some scenes, the thread do communication before the mmap called.
So I add proc->vma_vm_mm = current->mm where the binder_open function.
Since the binder init process in libbinder, the fix won't produce side effect.
If these are accepted, I will send a new V3 version.
>
>> proc->tsk->mm != current->mm && proc->tsk->mm
>>
>> So only allow the shared mm_struct to use the same binder-object and
>> check the existence of mm_struct.
>>
>> V2: Fix compile error for error commit
>>
>> Signed-off-by: Chen Feng <puck.chen@hisilicon.com>
>> Signed-off-by: Wei Dong <weidong2@hisilicon.com>
>> Signed-off-by: Junmin Zhao <zhaojunmin@huawei.com>
>> Reviewed-by: Zhuangluan Su <suzhuangluan@hisilicon.com>
>> ---
>> drivers/android/binder.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
>> index a39e85f..279063c 100644
>> --- a/drivers/android/binder.c
>> +++ b/drivers/android/binder.c
>> @@ -2736,6 +2736,8 @@ static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
>>
>> /*pr_info("binder_ioctl: %d:%d %x %lx\n",
>> proc->pid, current->pid, cmd, arg);*/
>> + if (unlikely(proc->tsk->mm != current->mm && proc->tsk->mm))
>> + return -EINVAL;
>>
>> trace_binder_ioctl(cmd, arg);
>>
>
> I would imagine that you would want to do READ_ONCE(proc->tsk->mm) so you
> are guaranteed to be testing the same value.
>
> .
>
prev parent reply other threads:[~2016-01-28 7:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-19 9:04 Chen Feng
2016-01-19 22:40 ` David Rientjes
2016-01-28 7:08 ` chenfeng [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56A9BE66.80400@hisilicon.com \
--to=puck.chen@hisilicon.com \
--cc=albert.lubing@hisilicon.com \
--cc=arve@android.com \
--cc=chenxiang9@huawei.com \
--cc=dan.zhao@hisilicon.com \
--cc=dev@lists.96boards.org \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=haojian.zhuang@linaro.org \
--cc=john.stultz@linaro.org \
--cc=kong.kongxinwei@hisilicon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=liuzixing@huawei.com \
--cc=oliver.fu@hisilicon.com \
--cc=peter.panshilin@hisilicon.com \
--cc=puck.chen@foxmail.com \
--cc=qijiwen@hisilicon.com \
--cc=riandrews@android.com \
--cc=rientjes@google.com \
--cc=saberlily.xia@hisilicon.com \
--cc=shimingxing@hisilicon.com \
--cc=suzhuangluan@hisilicon.com \
--cc=w.f@huawei.com \
--cc=wangjing6@huawei.com \
--cc=weidong2@hisilicon.com \
--cc=xuyiping@hisilicon.com \
--cc=yudongbin@hisilicon.com \
--cc=z.liuxinliang@hisilicon.com \
--cc=zhaojunmin@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome