Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp2125188ybv; Sun, 23 Feb 2020 23:17:59 -0800 (PST) X-Google-Smtp-Source: APXvYqwCHu8o4Slxa+OT0YkoI5ifZcGlOedYFmPWxG2c4dyXp+gYCnJto1vMWgAZiL+HchpIFA9Q X-Received: by 2002:aca:54cc:: with SMTP id i195mr11387683oib.126.1582528679610; Sun, 23 Feb 2020 23:17:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582528679; cv=none; d=google.com; s=arc-20160816; b=lz9UyFZGOB6as0OOZnWGfMZssFfX0ovy7REtBoPFeErQV7lcM7JSlPbPUOPuvhKEoJ 2EERzuZm1f6A0dDc6Chpve5rJ91fO+FuhkdP6ctyMRvjxutwBzG42e9u38TlxlG74OQT 4JnIRmb8X/s4ejQOEeDrWnDg6U9bEcNeKLcRIc5j9OsdUg596wCdFokhv18IMHTC/3Cq OMrBd06FkiPRRU6F4JOAKV852FxQebwZpjj5n6u3wkRjhboZd8OnsHoTZukqc1R+VG/y Hog8EGtoaT4zO3dL919WR+iUf/nwmQvIW9Qb/2TbMznsh/9nXFAlNzKdR0o9QEcifh4f Fqqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=BQ1NDYexaPG7tdlaCCx1LdI/FdRKQuJym5j+xr3k3DQ=; b=HoQAQsjsZfftmK8PoGcVK7ghznqFB7oYhze3AIxE007xd3hOo4R6T+LLHsBB4F0IEM XHFHRSsatv9lP7/Trq3su2HZKizT18HNEGCrQH2kp+9lP1ippsbso+O4b2e/IqbDpefk Zz+r1UR88VTfFe8AuupeOqd5m8w1uqAESCNoMz8tBvkSPBBZKEDD8i84TjMHizC5tBt9 3WBgcoWD32lIbJZBLevKxuorf7VGbvIolKpjikxp7rJ9oRF0himiXLvK8ZOGm7zBVj+2 MJynHWjmUZXJOqaEkCYnZHJzmI/dxlpDPraS9Xo9smR0zcmAgAFKOueWzjzqAgnnZ2JW Tczw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p186si4785834oih.172.2020.02.23.23.17.47; Sun, 23 Feb 2020 23:17:59 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726744AbgBXHRo (ORCPT + 99 others); Mon, 24 Feb 2020 02:17:44 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:10679 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725792AbgBXHRo (ORCPT ); Mon, 24 Feb 2020 02:17:44 -0500 Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 8238FEBECE607EF86A2F; Mon, 24 Feb 2020 15:17:36 +0800 (CST) Received: from [127.0.0.1] (10.67.101.242) by DGGEMS406-HUB.china.huawei.com (10.3.19.206) with Microsoft SMTP Server id 14.3.439.0; Mon, 24 Feb 2020 15:17:28 +0800 Subject: Re: [PATCH] uacce: unmap remaining mmapping from user space To: Zhangfei Gao , Greg Kroah-Hartman , Arnd Bergmann , Herbert Xu , , , , jean-philippe , Jerome Glisse , , , , Wangzhou , "haojian . zhuang" , References: <1582528016-2873-1-git-send-email-zhangfei.gao@linaro.org> CC: , , , From: Xu Zaibo Message-ID: Date: Mon, 24 Feb 2020 15:17:28 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <1582528016-2873-1-git-send-email-zhangfei.gao@linaro.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.101.242] X-CFilter-Loop: Reflected Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Hi Zhangfei, On 2020/2/24 15:06, Zhangfei Gao wrote: > When uacce parent device module is removed, user app may > still keep the mmaped area, which can be accessed unsafely. > When rmmod, Parent device drvier will call uacce_remove, > which unmap all remaining mapping from user space for safety. > VM_FAULT_SIGBUS is also reported to user space accordingly. > > Suggested-by: Dave Jiang > Signed-off-by: Zhangfei Gao > --- > drivers/misc/uacce/uacce.c | 17 +++++++++++++++++ > include/linux/uacce.h | 2 ++ > 2 files changed, 19 insertions(+) > > diff --git a/drivers/misc/uacce/uacce.c b/drivers/misc/uacce/uacce.c > index ffced4d..1bcc5e6 100644 > --- a/drivers/misc/uacce/uacce.c > +++ b/drivers/misc/uacce/uacce.c > @@ -224,6 +224,7 @@ static int uacce_fops_open(struct inode *inode, struct file *filep) > > init_waitqueue_head(&q->wait); > filep->private_data = q; > + uacce->inode = inode; > q->state = UACCE_Q_INIT; > > return 0; > @@ -253,6 +254,14 @@ static int uacce_fops_release(struct inode *inode, struct file *filep) > return 0; > } > > +static vm_fault_t uacce_vma_fault(struct vm_fault *vmf) > +{ > + if (vmf->flags & (FAULT_FLAG_MKWRITE | FAULT_FLAG_WRITE)) > + return VM_FAULT_SIGBUS; > + > + return 0; > +} > + > static void uacce_vma_close(struct vm_area_struct *vma) > { > struct uacce_queue *q = vma->vm_private_data; > @@ -265,6 +274,7 @@ static void uacce_vma_close(struct vm_area_struct *vma) > } > > static const struct vm_operations_struct uacce_vm_ops = { > + .fault = uacce_vma_fault, > .close = uacce_vma_close, > }; > > @@ -585,6 +595,13 @@ void uacce_remove(struct uacce_device *uacce) > cdev_device_del(uacce->cdev, &uacce->dev); > xa_erase(&uacce_xa, uacce->dev_id); > put_device(&uacce->dev); > + > + /* > + * unmap remainning mapping from user space, preventing user still > + * access the mmaped area while parent device is already removed > + */ > + if (uacce->inode) > + unmap_mapping_range(uacce->inode->i_mapping, 0, 0, 1); Should we unmap them at the first of 'uacce_remove', and before 'uacce_put_queue'? Thanks, Zaibo . > } > EXPORT_SYMBOL_GPL(uacce_remove); > > diff --git a/include/linux/uacce.h b/include/linux/uacce.h > index 904a461..0e215e6 100644 > --- a/include/linux/uacce.h > +++ b/include/linux/uacce.h > @@ -98,6 +98,7 @@ struct uacce_queue { > * @priv: private pointer of the uacce > * @mm_list: list head of uacce_mm->list > * @mm_lock: lock for mm_list > + * @inode: core vfs > */ > struct uacce_device { > const char *algs; > @@ -113,6 +114,7 @@ struct uacce_device { > void *priv; > struct list_head mm_list; > struct mutex mm_lock; > + struct inode *inode; > }; > > /**