Re: [PATCH 2/2] uacce: add uacce module

[Kenneth Lee]

On Mon, Aug 26, 2019 at 06:29:10AM +0200, Greg Kroah-Hartman wrote:
> Date: Mon, 26 Aug 2019 06:29:10 +0200
> From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> To: Kenneth Lee <liguozhu@xxxxxxxxxxxxx>
> CC: zhangfei <zhangfei.gao@xxxxxxxxxx>, Arnd Bergmann <arnd@xxxxxxxx>,
>  linux-accelerators@xxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, Zaibo
>  Xu <xuzaibo@xxxxxxxxxx>, Zhou Wang <wangzhou1@xxxxxxxxxxxxx>
> Subject: Re: [PATCH 2/2] uacce: add uacce module
> User-Agent: Mutt/1.12.1 (2019-06-15)
> Message-ID: <20190826042910.GA26547@xxxxxxxxx>
> 
> On Mon, Aug 26, 2019 at 12:10:42PM +0800, Kenneth Lee wrote:
> > On Wed, Aug 21, 2019 at 09:05:42AM -0700, Greg Kroah-Hartman wrote:
> > > Date: Wed, 21 Aug 2019 09:05:42 -0700
> > > From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> > > To: zhangfei <zhangfei.gao@xxxxxxxxxx>
> > > CC: Arnd Bergmann <arnd@xxxxxxxx>, linux-accelerators@xxxxxxxxxxxxxxxx,
> > >  linux-kernel@xxxxxxxxxxxxxxx, Kenneth Lee <liguozhu@xxxxxxxxxxxxx>, Zaibo
> > >  Xu <xuzaibo@xxxxxxxxxx>, Zhou Wang <wangzhou1@xxxxxxxxxxxxx>
> > > Subject: Re: [PATCH 2/2] uacce: add uacce module
> > > User-Agent: Mutt/1.12.1 (2019-06-15)
> > > Message-ID: <20190821160542.GA14760@xxxxxxxxx>
> > > 
> > > On Wed, Aug 21, 2019 at 10:30:22PM +0800, zhangfei wrote:
> > > > 
> > > > 
> > > > On 2019/8/21 äå5:17, Greg Kroah-Hartman wrote:
> > > > > On Wed, Aug 21, 2019 at 03:21:18PM +0800, zhangfei.gao@xxxxxxxxxxx wrote:
> > > > > > Hi, Greg
> > > > > > 
> > > > > > On 2019/8/21 äå12:59, Greg Kroah-Hartman wrote:
> > > > > > > On Tue, Aug 20, 2019 at 09:08:55PM +0800, zhangfei wrote:
> > > > > > > > On 2019/8/15 äå10:13, Greg Kroah-Hartman wrote:
> > > > > > > > > On Wed, Aug 14, 2019 at 05:34:25PM +0800, Zhangfei Gao wrote:
> > > > > > > > > > +int uacce_register(struct uacce *uacce)
> > > > > > > > > > +{
> > > > > > > > > > +	int ret;
> > > > > > > > > > +
> > > > > > > > > > +	if (!uacce->pdev) {
> > > > > > > > > > +		pr_debug("uacce parent device not set\n");
> > > > > > > > > > +		return -ENODEV;
> > > > > > > > > > +	}
> > > > > > > > > > +
> > > > > > > > > > +	if (uacce->flags & UACCE_DEV_NOIOMMU) {
> > > > > > > > > > +		add_taint(TAINT_CRAP, LOCKDEP_STILL_OK);
> > > > > > > > > > +		dev_warn(uacce->pdev,
> > > > > > > > > > +			 "Register to noiommu mode, which export kernel data to user space and may vulnerable to attack");
> > > > > > > > > > +	}
> > > > > > > > > THat is odd, why even offer this feature then if it is a major issue?
> > > > > > > > UACCE_DEV_NOIOMMU maybe confusing here.
> > > > > > > > 
> > > > > > > > In this mode, app use ioctl to get dma_handle from dma_alloc_coherent.
> > > > > > > That's odd, why not use the other default apis to do that?
> > > > > > > 
> > > > > > > > It does not matter iommu is enabled or not.
> > > > > > > > In case iommu is disabled, it maybe dangerous to kernel, so we added warning here, is it required?
> > > > > > > You should use the other documentated apis for this, don't create your
> > > > > > > own.
> > > > > > I am sorry, not understand here.
> > > > > > Do you mean there is a standard ioctl or standard api in user space, it can
> > > > > > get dma_handle from dma_alloc_coherent from kernel?
> > > > > There should be a standard way to get such a handle from userspace
> > > > > today.  Isn't that what the ion interface does?  DRM also does this, as
> > > > > does UIO I think.
> > > > Thanks Greg,
> > > > Still not find it, will do more search.
> > > > But this may introduce dependency in our lib, like depend on ion?
> > > > > Do you have a spec somewhere that shows exactly what you are trying to
> > > > > do here, along with example userspace code?  It's hard to determine it
> > > > > given you only have one "half" of the code here and no users of the apis
> > > > > you are creating.
> > > > > 
> > > > The purpose is doing dma in user space.
> > > 
> > > Oh no, please no.  Are you _SURE_ you want to do this?
> > > 
> > > Again, look at how ION does this and how the DMAbuff stuff is replacing
> > > it.  Use that api please instead, otherwise you will get it wrong and we
> > > don't want to duplicate efforts.
> > > 
> > > thanks,
> > > 
> > > greg k-h
> > 
> > Dear Greg. I wrote a blog to explain the intention of WarpDrive here:
> > https://zhuanlan.zhihu.com/p/79680889.
> 
> Putting that information into the changelog and kernel documentation is
> a much better idea than putting it there.

Yes, will do. Thank you.

> 
> > Sharing data is not our intention, Sharing address is. NOIOMMU mode is just a
> > temporary solution to let some hardware which does not care the security issue
> > to try WarpDrive for the first step. Some user do not care this much in embedded
> > scenario. We saw VFIO use the same model so we also want to make a try. If you
> > insist this is risky, we can remove it.
> 
> Why not just use vfio then?

We tried that in previous patches. But it needs to create unnecessary mdev to
fulfill the requirement. So we discard it after the discussion in lkml.

> 
> And yes, for now, please remove it, if you are not requiring it.
> 

We do require it;) But surely we can kept it in our own branch but push only the
main function. Thank you.

> thanks,
> 
> greg k-h

-- 
			-Kenneth(Hisilicon)

================================================================================
æéäååéäåæåäååçäåäæïäéäåéçäéååäååçääæççãç
æääåäääääååäçïåæääéäåéæéååæéãååãææåïæéää
çäæãåææéæäæéäïèæçåçèæéäéçåääååéæéäï
This e-mail and its attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed above.
Any use of the 
information contained herein in any way (including, but not limited to, total or
partial disclosure, reproduction, or dissemination) by persons other than the
intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify
the sender by phone or email immediately and delete it!