Re: DMA Engine: Transfer From Userspace

From: Thomas Ruf <freelancer@rufusul.de>
To: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>, Vinod Koul <vkoul@kernel.org>,
	Federico Vaga <federico.vaga@cern.ch>,
	Dan Williams <dan.j.williams@intel.com>,
	dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org, "Kumar,
	Sanjay K" <sanjay.k.kumar@intel.com>,
	"Luck, Tony" <tony.luck@intel.com>
Subject: Re: DMA Engine: Transfer From Userspace
Date: Mon, 29 Jun 2020 17:31:27 +0200 (CEST)	[thread overview]
Message-ID: <1069735883.1017676.1593444687939@mailbusiness.ionos.de> (raw)
In-Reply-To: <20200626200815.GC2454695@iweiny-DESK2.sc.intel.com>

> On 26 June 2020 at 22:08 Ira Weiny <ira.weiny@intel.com> wrote:
> 
> 
> On Thu, Jun 25, 2020 at 10:11:28AM +0200, Thomas Ruf wrote:
> > 
> > > On 25 June 2020 at 02:42 Dave Jiang <dave.jiang@intel.com> wrote:
> > > 
> > > 
> > > 
> > > 
> > > On 6/21/2020 12:24 AM, Vinod Koul wrote:
> > > > On 19-06-20, 16:31, Dave Jiang wrote:
> > > >>
> > > >>
> > > >> On 6/19/2020 3:47 PM, Federico Vaga wrote:
> > > >>> Hello,
> > > >>>
> > > >>> is there the possibility of using a DMA engine channel from userspace?
> > > >>>
> > > >>> Something like:
> > > >>> - configure DMA using ioctl() (or whatever configuration mechanism)
> > > >>> - read() or write() to trigger the transfer
> > > >>>
> > > >>
> > > >> I may have supposedly promised Vinod to look into possibly providing
> > > >> something like this in the future. But I have not gotten around to do that
> > > >> yet. Currently, no such support.
> > > > 
> > > > And I do still have serious reservations about this topic :) Opening up
> > > > userspace access to DMA does not sound very great from security point of
> > > > view.
> > > 
> > > What about doing it with DMA engine that supports PASID? That way the user can 
> > > really only trash its own address space and kernel is protected.
> > 
> > Sounds interesting! Not sure if this is really needed in that case...
> > I have already implemented checks of vm_area_struct for contiguous memory or even do a get_user_pages_fast for user memory to pin it (hope that is the correct term here). Of course i have to do that for every involved page.
> 
> FWIW there is a new pin_user_pages_fast()/unpin_user_page() interface now.

Thanks for that info. But at the moment we are mainly interested in a solution which can be easily backported to Xilinix Release 2020.1 with kernel 5.4.x where i could not find that new functionality.

> > But i will do some checks if my code is really suitable to avoid misusage.

Did some basic tests today and was not able to break out of my own checks done via follow_pfn() respectively get_user_pages_fast(). If this stands "advanced attacks" my proxy driver shouldn't be more dangerous as an ordinary memcpy, i know that there will always remain some doubts ;-)

best regards,
Thomas