[PATCH v2 3/4] drm/exynos: added userptr feature.
Hi Jerome, > -Original Message- > From: Jerome Glisse [mailto:j.glisse at gmail.com] > Sent: Tuesday, May 08, 2012 3:18 AM > To: Dave Airlie > Cc: daeinki at gmail.com; Inki Dae; kyungmin.park at samsung.com; > sw0312.kim at samsung.com; dri-devel at lists.freedesktop.org > Subject: Re: [PATCH v2 3/4] drm/exynos: added userptr feature. > > On Sat, May 5, 2012 at 6:22 AM, Dave Airlie wrote: > > On Sat, May 5, 2012 at 11:19 AM, wrote: > >> Hi Dave, > >> > >> 2012. 4. 25. ?? 7:15 Dave Airlie ??: > >> > >>> On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae wrote: > >>>> this feature could be used to use memory region allocated by malloc() > in user > >>>> mode and mmaped memory region allocated by other memory allocators. > userptr > >>>> interface can identify memory type through vm_flags value and would > get > >>>> pages or page frame numbers to user space appropriately. > >>> > >>> Is there anything to stop the unpriviledged userspace driver locking > >>> all the RAM in the machine inside userptr? > >>> > >> > >> you mean that there is something that it can stop user space driver > locking some memory region of RAM? and if any user space driver locked > some region then anyone on user space can't access the region? could you > please tell me about your concerns in more detail so that we can solve the > issue? I guess you mean that any user level driver such as specific EGL > library can allocate some memory region and also lock the region so that > other user space applications can't access the region until rendering is > completed by hw accelerator such as 2d/3d core or opposite case. > >> > >> actually, this feature has already been used by v4l2 so I didn't try to > consider we could face with any problem with this and I've got a feeling > maybe there is something I missed so I'd be happy for you or anyone give > me any advices. > > > > Well v4l get to make their own bad design decisions. > > > > The problem is if an unprivledged users accessing the drm can lock all > > the pages it allocates into memory, by passing them to the kernel as > > userptrs., thus bypassing the swap and blocking all other users on the > > system. > > > > Dave. > > Beside that you are not locking the vma and afaik this means that the > page backing the vma might change, yes you will still own the page you > get but userspace might be reading/writing to different pages. The vma Yes, right. the vma should be locked because the pages backing the vma might be changed after swap-in. thank you for your pointing. > would need to be locked but than the userspace might unlock it in your > back and you start right from the begining. > I'm not sure I understood your comments but my understanding is you mean that there is some interface that it can unlock(using some interface of drm side or implementing it?) the vma so we can resolve the issue Dave pointed out? Thanks, Inki Dae > Cheers, > Jerome
[PATCH v2 3/4] drm/exynos: added userptr feature.
Hi Dave, > -Original Message- > From: Dave Airlie [mailto:airlied at gmail.com] > Sent: Saturday, May 05, 2012 7:23 PM > To: daeinki at gmail.com > Cc: Inki Dae; kyungmin.park at samsung.com; sw0312.kim at samsung.com; dri- > devel at lists.freedesktop.org > Subject: Re: [PATCH v2 3/4] drm/exynos: added userptr feature. > > On Sat, May 5, 2012 at 11:19 AM, wrote: > > Hi Dave, > > > > 2012. 4. 25. ?? 7:15 Dave Airlie ??: > > > >> On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae wrote: > >>> this feature could be used to use memory region allocated by malloc() > in user > >>> mode and mmaped memory region allocated by other memory allocators. > userptr > >>> interface can identify memory type through vm_flags value and would > get > >>> pages or page frame numbers to user space appropriately. > >> > >> Is there anything to stop the unpriviledged userspace driver locking > >> all the RAM in the machine inside userptr? > >> > > > > you mean that there is something that it can stop user space driver > locking some memory region of RAM? and if any user space driver locked > some region then anyone on user space can't access the region? could you > please tell me about your concerns in more detail so that we can solve the > issue? I guess you mean that any user level driver such as specific EGL > library can allocate some memory region and also lock the region so that > other user space applications can't access the region until rendering is > completed by hw accelerator such as 2d/3d core or opposite case. > > > > actually, this feature has already been used by v4l2 so I didn't try to > consider we could face with any problem with this and I've got a feeling > maybe there is something I missed so I'd be happy for you or anyone give > me any advices. > > Well v4l get to make their own bad design decisions. > > The problem is if an unprivledged users accessing the drm can lock all > the pages it allocates into memory, by passing them to the kernel as > userptrs., thus bypassing the swap and blocking all other users on the > system. > Thank you for your advices and comments and I will look over this feature again. We should use this feature for our linux-based platform because the backend of evas(used by elementary) or pixman(used by Cario) needs this feature to use hardware accelerator only using user address so I will re-post it again after resolving this issue if possible. Thanks, Inki Dae > Dave.
[PATCH v2 3/4] drm/exynos: added userptr feature.
On Tue, May 8, 2012 at 3:59 AM, Inki Dae wrote: > Hi Jerome, > >> -Original Message- >> From: Jerome Glisse [mailto:j.glisse at gmail.com] >> Sent: Tuesday, May 08, 2012 3:18 AM >> To: Dave Airlie >> Cc: daeinki at gmail.com; Inki Dae; kyungmin.park at samsung.com; >> sw0312.kim at samsung.com; dri-devel at lists.freedesktop.org >> Subject: Re: [PATCH v2 3/4] drm/exynos: added userptr feature. >> >> On Sat, May 5, 2012 at 6:22 AM, Dave Airlie wrote: >> > On Sat, May 5, 2012 at 11:19 AM, wrote: >> >> Hi Dave, >> >> >> >> 2012. 4. 25. ?? 7:15 Dave Airlie ??: >> >> >> >>> On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae > wrote: >> >>>> this feature could be used to use memory region allocated by malloc() >> in user >> >>>> mode and mmaped memory region allocated by other memory allocators. >> userptr >> >>>> interface can identify memory type through vm_flags value and would >> get >> >>>> pages or page frame numbers to user space appropriately. >> >>> >> >>> Is there anything to stop the unpriviledged userspace driver locking >> >>> all the RAM in the machine inside userptr? >> >>> >> >> >> >> you mean that there is something that it can stop user space driver >> locking some memory region of RAM? and if any user space driver locked >> some region then anyone on user space can't access the region? could you >> please tell me about your concerns in more detail so that we can solve the >> issue? I guess you mean that any user level driver such as specific EGL >> library can allocate some memory region and also lock the region so that >> other user space applications can't access the region until rendering is >> completed by hw accelerator such as 2d/3d core or opposite case. >> >> >> >> actually, this feature has already been used by v4l2 so I didn't try to >> consider we could face with any problem with this and I've got a feeling >> maybe there is something I missed so I'd be happy for you or anyone give >> me any advices. >> > >> > Well v4l get to make their own bad design decisions. >> > >> > The problem is if an unprivledged users accessing the drm can lock all >> > the pages it allocates into memory, by passing them to the kernel as >> > userptrs., thus bypassing the swap and blocking all other users on the >> > system. >> > >> > Dave. >> >> Beside that you are not locking the vma and afaik this means that the >> page backing the vma might change, yes you will still own the page you >> get but userspace might be reading/writing to different pages. The vma > > Yes, right. the vma should be locked because the pages backing the vma > might be changed after swap-in. thank you for your pointing. > > >> would need to be locked but than the userspace might unlock it in your >> back and you start right from the begining. >> > > I'm not sure I understood your comments but my understanding is you mean > that there is some interface that it can unlock(using some interface of drm > side or implementing it?) the vma so we can resolve the issue Dave pointed > out? > > Thanks, > Inki Dae > Userspace can unlock the vma behind your back with the sys call munlock, malicious process might use that to trick your gpu somehow. The thing is there is no proper infrastructure in linux kernel for locking vma for long period of time. Because it mess with core linux vm stuff i believe the vm people should be involved and comment on this. Also we absolutely don't want process to abuse the drm to force locking, so you will need to make sure that what drm does won't go over the memlock limit of the process (and i am not even sure that by default this limit is not 0). Anyway my point is i believe there is maybe no proper right now to do this, maybe using VM_RESERVED but i am not clear on the implication of doing so. Note in all case you will need the fragment the vma so that you don't suddenly convert more than you want from anonymous vma to something more restrictive. Cheers, Jerome
RE: [PATCH v2 3/4] drm/exynos: added userptr feature.
Hi Dave, -Original Message- From: Dave Airlie [mailto:airl...@gmail.com] Sent: Saturday, May 05, 2012 7:23 PM To: daei...@gmail.com Cc: Inki Dae; kyungmin.p...@samsung.com; sw0312@samsung.com; dri- de...@lists.freedesktop.org Subject: Re: [PATCH v2 3/4] drm/exynos: added userptr feature. On Sat, May 5, 2012 at 11:19 AM, daei...@gmail.com wrote: Hi Dave, 2012. 4. 25. 오후 7:15 Dave Airlie airl...@gmail.com 작성: On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae inki@samsung.com wrote: this feature could be used to use memory region allocated by malloc() in user mode and mmaped memory region allocated by other memory allocators. userptr interface can identify memory type through vm_flags value and would get pages or page frame numbers to user space appropriately. Is there anything to stop the unpriviledged userspace driver locking all the RAM in the machine inside userptr? you mean that there is something that it can stop user space driver locking some memory region of RAM? and if any user space driver locked some region then anyone on user space can't access the region? could you please tell me about your concerns in more detail so that we can solve the issue? I guess you mean that any user level driver such as specific EGL library can allocate some memory region and also lock the region so that other user space applications can't access the region until rendering is completed by hw accelerator such as 2d/3d core or opposite case. actually, this feature has already been used by v4l2 so I didn't try to consider we could face with any problem with this and I've got a feeling maybe there is something I missed so I'd be happy for you or anyone give me any advices. Well v4l get to make their own bad design decisions. The problem is if an unprivledged users accessing the drm can lock all the pages it allocates into memory, by passing them to the kernel as userptrs., thus bypassing the swap and blocking all other users on the system. Thank you for your advices and comments and I will look over this feature again. We should use this feature for our linux-based platform because the backend of evas(used by elementary) or pixman(used by Cario) needs this feature to use hardware accelerator only using user address so I will re-post it again after resolving this issue if possible. Thanks, Inki Dae Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2 3/4] drm/exynos: added userptr feature.
Hi Jerome, -Original Message- From: Jerome Glisse [mailto:j.gli...@gmail.com] Sent: Tuesday, May 08, 2012 3:18 AM To: Dave Airlie Cc: daei...@gmail.com; Inki Dae; kyungmin.p...@samsung.com; sw0312@samsung.com; dri-devel@lists.freedesktop.org Subject: Re: [PATCH v2 3/4] drm/exynos: added userptr feature. On Sat, May 5, 2012 at 6:22 AM, Dave Airlie airl...@gmail.com wrote: On Sat, May 5, 2012 at 11:19 AM, daei...@gmail.com wrote: Hi Dave, 2012. 4. 25. 오후 7:15 Dave Airlie airl...@gmail.com 작성: On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae inki@samsung.com wrote: this feature could be used to use memory region allocated by malloc() in user mode and mmaped memory region allocated by other memory allocators. userptr interface can identify memory type through vm_flags value and would get pages or page frame numbers to user space appropriately. Is there anything to stop the unpriviledged userspace driver locking all the RAM in the machine inside userptr? you mean that there is something that it can stop user space driver locking some memory region of RAM? and if any user space driver locked some region then anyone on user space can't access the region? could you please tell me about your concerns in more detail so that we can solve the issue? I guess you mean that any user level driver such as specific EGL library can allocate some memory region and also lock the region so that other user space applications can't access the region until rendering is completed by hw accelerator such as 2d/3d core or opposite case. actually, this feature has already been used by v4l2 so I didn't try to consider we could face with any problem with this and I've got a feeling maybe there is something I missed so I'd be happy for you or anyone give me any advices. Well v4l get to make their own bad design decisions. The problem is if an unprivledged users accessing the drm can lock all the pages it allocates into memory, by passing them to the kernel as userptrs., thus bypassing the swap and blocking all other users on the system. Dave. Beside that you are not locking the vma and afaik this means that the page backing the vma might change, yes you will still own the page you get but userspace might be reading/writing to different pages. The vma Yes, right. the vma should be locked because the pages backing the vma might be changed after swap-in. thank you for your pointing. would need to be locked but than the userspace might unlock it in your back and you start right from the begining. I'm not sure I understood your comments but my understanding is you mean that there is some interface that it can unlock(using some interface of drm side or implementing it?) the vma so we can resolve the issue Dave pointed out? Thanks, Inki Dae Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/exynos: added userptr feature.
On Tue, May 8, 2012 at 3:59 AM, Inki Dae inki@samsung.com wrote: Hi Jerome, -Original Message- From: Jerome Glisse [mailto:j.gli...@gmail.com] Sent: Tuesday, May 08, 2012 3:18 AM To: Dave Airlie Cc: daei...@gmail.com; Inki Dae; kyungmin.p...@samsung.com; sw0312@samsung.com; dri-devel@lists.freedesktop.org Subject: Re: [PATCH v2 3/4] drm/exynos: added userptr feature. On Sat, May 5, 2012 at 6:22 AM, Dave Airlie airl...@gmail.com wrote: On Sat, May 5, 2012 at 11:19 AM, daei...@gmail.com wrote: Hi Dave, 2012. 4. 25. 오후 7:15 Dave Airlie airl...@gmail.com 작성: On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae inki@samsung.com wrote: this feature could be used to use memory region allocated by malloc() in user mode and mmaped memory region allocated by other memory allocators. userptr interface can identify memory type through vm_flags value and would get pages or page frame numbers to user space appropriately. Is there anything to stop the unpriviledged userspace driver locking all the RAM in the machine inside userptr? you mean that there is something that it can stop user space driver locking some memory region of RAM? and if any user space driver locked some region then anyone on user space can't access the region? could you please tell me about your concerns in more detail so that we can solve the issue? I guess you mean that any user level driver such as specific EGL library can allocate some memory region and also lock the region so that other user space applications can't access the region until rendering is completed by hw accelerator such as 2d/3d core or opposite case. actually, this feature has already been used by v4l2 so I didn't try to consider we could face with any problem with this and I've got a feeling maybe there is something I missed so I'd be happy for you or anyone give me any advices. Well v4l get to make their own bad design decisions. The problem is if an unprivledged users accessing the drm can lock all the pages it allocates into memory, by passing them to the kernel as userptrs., thus bypassing the swap and blocking all other users on the system. Dave. Beside that you are not locking the vma and afaik this means that the page backing the vma might change, yes you will still own the page you get but userspace might be reading/writing to different pages. The vma Yes, right. the vma should be locked because the pages backing the vma might be changed after swap-in. thank you for your pointing. would need to be locked but than the userspace might unlock it in your back and you start right from the begining. I'm not sure I understood your comments but my understanding is you mean that there is some interface that it can unlock(using some interface of drm side or implementing it?) the vma so we can resolve the issue Dave pointed out? Thanks, Inki Dae Userspace can unlock the vma behind your back with the sys call munlock, malicious process might use that to trick your gpu somehow. The thing is there is no proper infrastructure in linux kernel for locking vma for long period of time. Because it mess with core linux vm stuff i believe the vm people should be involved and comment on this. Also we absolutely don't want process to abuse the drm to force locking, so you will need to make sure that what drm does won't go over the memlock limit of the process (and i am not even sure that by default this limit is not 0). Anyway my point is i believe there is maybe no proper right now to do this, maybe using VM_RESERVED but i am not clear on the implication of doing so. Note in all case you will need the fragment the vma so that you don't suddenly convert more than you want from anonymous vma to something more restrictive. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] drm/exynos: added userptr feature.
On Sat, May 5, 2012 at 6:22 AM, Dave Airlie wrote: > On Sat, May 5, 2012 at 11:19 AM, wrote: >> Hi Dave, >> >> 2012. 4. 25. ?? 7:15 Dave Airlie ??: >> >>> On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae wrote: this feature could be used to use memory region allocated by malloc() in user mode and mmaped memory region allocated by other memory allocators. userptr interface can identify memory type through vm_flags value and would get pages or page frame numbers to user space appropriately. >>> >>> Is there anything to stop the unpriviledged userspace driver locking >>> all the RAM in the machine inside userptr? >>> >> >> you mean that there is something that it can stop user space driver locking >> some memory region of RAM? and if any user space driver locked some region >> then anyone on user space can't access the region? could you please tell me >> about your concerns in more detail so that we can solve the issue? I guess >> you mean that any user level driver such as specific EGL library can >> allocate some memory region and also lock the region so that other user >> space applications can't access the region until rendering is completed by >> hw accelerator such as 2d/3d core or opposite case. >> >> actually, this feature has already been used by v4l2 so I didn't try to >> consider we could face with any problem with this and I've got a feeling >> maybe there is something I missed so I'd be happy for you or anyone give me >> any advices. > > Well v4l get to make their own bad design decisions. > > The problem is if an unprivledged users accessing the drm can lock all > the pages it allocates into memory, by passing them to the kernel as > userptrs., thus bypassing the swap and blocking all other users on the > system. > > Dave. Beside that you are not locking the vma and afaik this means that the page backing the vma might change, yes you will still own the page you get but userspace might be reading/writing to different pages. The vma would need to be locked but than the userspace might unlock it in your back and you start right from the begining. Cheers, Jerome
Re: [PATCH v2 3/4] drm/exynos: added userptr feature.
On Sat, May 5, 2012 at 6:22 AM, Dave Airlie airl...@gmail.com wrote: On Sat, May 5, 2012 at 11:19 AM, daei...@gmail.com wrote: Hi Dave, 2012. 4. 25. 오후 7:15 Dave Airlie airl...@gmail.com 작성: On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae inki@samsung.com wrote: this feature could be used to use memory region allocated by malloc() in user mode and mmaped memory region allocated by other memory allocators. userptr interface can identify memory type through vm_flags value and would get pages or page frame numbers to user space appropriately. Is there anything to stop the unpriviledged userspace driver locking all the RAM in the machine inside userptr? you mean that there is something that it can stop user space driver locking some memory region of RAM? and if any user space driver locked some region then anyone on user space can't access the region? could you please tell me about your concerns in more detail so that we can solve the issue? I guess you mean that any user level driver such as specific EGL library can allocate some memory region and also lock the region so that other user space applications can't access the region until rendering is completed by hw accelerator such as 2d/3d core or opposite case. actually, this feature has already been used by v4l2 so I didn't try to consider we could face with any problem with this and I've got a feeling maybe there is something I missed so I'd be happy for you or anyone give me any advices. Well v4l get to make their own bad design decisions. The problem is if an unprivledged users accessing the drm can lock all the pages it allocates into memory, by passing them to the kernel as userptrs., thus bypassing the swap and blocking all other users on the system. Dave. Beside that you are not locking the vma and afaik this means that the page backing the vma might change, yes you will still own the page you get but userspace might be reading/writing to different pages. The vma would need to be locked but than the userspace might unlock it in your back and you start right from the begining. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] drm/exynos: added userptr feature.
Hi Dave, 2012. 4. 25. ?? 7:15 Dave Airlie ??: > On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae wrote: >> this feature could be used to use memory region allocated by malloc() in user >> mode and mmaped memory region allocated by other memory allocators. userptr >> interface can identify memory type through vm_flags value and would get >> pages or page frame numbers to user space appropriately. > > Is there anything to stop the unpriviledged userspace driver locking > all the RAM in the machine inside userptr? > you mean that there is something that it can stop user space driver locking some memory region of RAM? and if any user space driver locked some region then anyone on user space can't access the region? could you please tell me about your concerns in more detail so that we can solve the issue? I guess you mean that any user level driver such as specific EGL library can allocate some memory region and also lock the region so that other user space applications can't access the region until rendering is completed by hw accelerator such as 2d/3d core or opposite case. actually, this feature has already been used by v4l2 so I didn't try to consider we could face with any problem with this and I've got a feeling maybe there is something I missed so I'd be happy for you or anyone give me any advices. Thanks, Inki Dae. > seems like a very bad plan, I know TTM has code to address this sort > of things with limits. > > Dave. > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] drm/exynos: added userptr feature.
On Sat, May 5, 2012 at 11:19 AM, wrote: > Hi Dave, > > 2012. 4. 25. ?? 7:15 Dave Airlie ??: > >> On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae wrote: >>> this feature could be used to use memory region allocated by malloc() in >>> user >>> mode and mmaped memory region allocated by other memory allocators. userptr >>> interface can identify memory type through vm_flags value and would get >>> pages or page frame numbers to user space appropriately. >> >> Is there anything to stop the unpriviledged userspace driver locking >> all the RAM in the machine inside userptr? >> > > you mean that there is something that it can stop user space driver locking > some memory region of RAM? and if any user space driver locked some region > then anyone on user space can't access the region? could you please tell me > about your concerns in more detail so that we can solve the issue? I guess > you mean that any user level driver such as specific EGL library can allocate > some memory region and also lock the region so that other user space > applications can't access the region until rendering is completed by hw > accelerator such as 2d/3d core or opposite case. > > actually, this feature has already been used by v4l2 so I didn't try to > consider we could face with any problem with this and I've got a feeling > maybe there is something I missed so I'd be happy for you or anyone give me > any advices. Well v4l get to make their own bad design decisions. The problem is if an unprivledged users accessing the drm can lock all the pages it allocates into memory, by passing them to the kernel as userptrs., thus bypassing the swap and blocking all other users on the system. Dave.
Re: [PATCH v2 3/4] drm/exynos: added userptr feature.
Hi Dave, 2012. 4. 25. 오후 7:15 Dave Airlie airl...@gmail.com 작성: On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae inki@samsung.com wrote: this feature could be used to use memory region allocated by malloc() in user mode and mmaped memory region allocated by other memory allocators. userptr interface can identify memory type through vm_flags value and would get pages or page frame numbers to user space appropriately. Is there anything to stop the unpriviledged userspace driver locking all the RAM in the machine inside userptr? you mean that there is something that it can stop user space driver locking some memory region of RAM? and if any user space driver locked some region then anyone on user space can't access the region? could you please tell me about your concerns in more detail so that we can solve the issue? I guess you mean that any user level driver such as specific EGL library can allocate some memory region and also lock the region so that other user space applications can't access the region until rendering is completed by hw accelerator such as 2d/3d core or opposite case. actually, this feature has already been used by v4l2 so I didn't try to consider we could face with any problem with this and I've got a feeling maybe there is something I missed so I'd be happy for you or anyone give me any advices. Thanks, Inki Dae. seems like a very bad plan, I know TTM has code to address this sort of things with limits. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/exynos: added userptr feature.
On Sat, May 5, 2012 at 11:19 AM, daei...@gmail.com wrote: Hi Dave, 2012. 4. 25. 오후 7:15 Dave Airlie airl...@gmail.com 작성: On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae inki@samsung.com wrote: this feature could be used to use memory region allocated by malloc() in user mode and mmaped memory region allocated by other memory allocators. userptr interface can identify memory type through vm_flags value and would get pages or page frame numbers to user space appropriately. Is there anything to stop the unpriviledged userspace driver locking all the RAM in the machine inside userptr? you mean that there is something that it can stop user space driver locking some memory region of RAM? and if any user space driver locked some region then anyone on user space can't access the region? could you please tell me about your concerns in more detail so that we can solve the issue? I guess you mean that any user level driver such as specific EGL library can allocate some memory region and also lock the region so that other user space applications can't access the region until rendering is completed by hw accelerator such as 2d/3d core or opposite case. actually, this feature has already been used by v4l2 so I didn't try to consider we could face with any problem with this and I've got a feeling maybe there is something I missed so I'd be happy for you or anyone give me any advices. Well v4l get to make their own bad design decisions. The problem is if an unprivledged users accessing the drm can lock all the pages it allocates into memory, by passing them to the kernel as userptrs., thus bypassing the swap and blocking all other users on the system. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] drm/exynos: added userptr feature.
Hi Dave, 2012/4/25, Dave Airlie : > On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae wrote: >> this feature could be used to use memory region allocated by malloc() in >> user >> mode and mmaped memory region allocated by other memory allocators. >> userptr >> interface can identify memory type through vm_flags value and would get >> pages or page frame numbers to user space appropriately. > > Is there anything to stop the unpriviledged userspace driver locking > all the RAM in the machine inside userptr? > > seems like a very bad plan, I know TTM has code to address this sort > of things with limits. > Thank you for your pointing and I will look into it. could anyone tell me that I can refer to which part of TTM? if doing so, it would be helpful to me. Thanks, Inki Dae. > Dave. > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[PATCH v2 3/4] drm/exynos: added userptr feature.
On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae wrote: > this feature could be used to use memory region allocated by malloc() in user > mode and mmaped memory region allocated by other memory allocators. userptr > interface can identify memory type through vm_flags value and would get > pages or page frame numbers to user space appropriately. Is there anything to stop the unpriviledged userspace driver locking all the RAM in the machine inside userptr? seems like a very bad plan, I know TTM has code to address this sort of things with limits. Dave.
Re: [PATCH v2 3/4] drm/exynos: added userptr feature.
On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae inki@samsung.com wrote: this feature could be used to use memory region allocated by malloc() in user mode and mmaped memory region allocated by other memory allocators. userptr interface can identify memory type through vm_flags value and would get pages or page frame numbers to user space appropriately. Is there anything to stop the unpriviledged userspace driver locking all the RAM in the machine inside userptr? seems like a very bad plan, I know TTM has code to address this sort of things with limits. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] drm/exynos: added userptr feature.
this feature could be used to use memory region allocated by malloc() in user
mode and mmaped memory region allocated by other memory allocators. userptr
interface can identify memory type through vm_flags value and would get
pages or page frame numbers to user space appropriately.
changelog v2:
the memory region mmaped with VM_PFNMAP type is physically continuous and
start address of the memory region should be set into buf->dma_addr but
previous patch had a problem that end address is set into buf->dma_addr
so v2 fixes that problem.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_drv.c |2 +
drivers/gpu/drm/exynos/exynos_drm_gem.c | 265 +++
drivers/gpu/drm/exynos/exynos_drm_gem.h | 13 ++-
include/drm/exynos_drm.h| 25 +++-
4 files changed, 303 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index f58a487..5bb0361 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -211,6 +211,8 @@ static struct drm_ioctl_desc exynos_ioctls[] = {
DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(EXYNOS_GEM_USERPTR,
+ exynos_drm_gem_userptr_ioctl, DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(EXYNOS_PLANE_SET_ZPOS, exynos_plane_set_zpos_ioctl,
DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index afd0cd4..1ee5383 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -66,6 +66,43 @@ static int check_gem_flags(unsigned int flags)
return 0;
}
+static struct vm_area_struct *get_vma(struct vm_area_struct *vma)
+{
+ struct vm_area_struct *vma_copy;
+
+ vma_copy = kmalloc(sizeof(*vma_copy), GFP_KERNEL);
+ if (!vma_copy)
+ return NULL;
+
+ if (vma->vm_ops && vma->vm_ops->open)
+ vma->vm_ops->open(vma);
+
+ if (vma->vm_file)
+ get_file(vma->vm_file);
+
+ memcpy(vma_copy, vma, sizeof(*vma));
+
+ vma_copy->vm_mm = NULL;
+ vma_copy->vm_next = NULL;
+ vma_copy->vm_prev = NULL;
+
+ return vma_copy;
+}
+
+static void put_vma(struct vm_area_struct *vma)
+{
+ if (!vma)
+ return;
+
+ if (vma->vm_ops && vma->vm_ops->close)
+ vma->vm_ops->close(vma);
+
+ if (vma->vm_file)
+ fput(vma->vm_file);
+
+ kfree(vma);
+}
+
static void update_vm_cache_attr(struct exynos_drm_gem_obj *obj,
struct vm_area_struct *vma)
{
@@ -254,6 +291,41 @@ static void exynos_drm_gem_put_pages(struct drm_gem_object
*obj)
/* add some codes for UNCACHED type here. TODO */
}
+static void exynos_drm_put_userptr(struct drm_gem_object *obj)
+{
+ struct exynos_drm_gem_obj *exynos_gem_obj;
+ struct exynos_drm_gem_buf *buf;
+ struct vm_area_struct *vma;
+ int npages;
+
+ exynos_gem_obj = to_exynos_gem_obj(obj);
+ buf = exynos_gem_obj->buffer;
+ vma = exynos_gem_obj->vma;
+
+ if (vma && (vma->vm_flags & VM_PFNMAP) && (vma->vm_pgoff)) {
+ put_vma(exynos_gem_obj->vma);
+ goto out;
+ }
+
+ npages = buf->size >> PAGE_SHIFT;
+
+ npages--;
+ while (npages >= 0) {
+ if (buf->write)
+ set_page_dirty_lock(buf->pages[npages]);
+
+ put_page(buf->pages[npages]);
+ npages--;
+ }
+
+out:
+ kfree(buf->pages);
+ buf->pages = NULL;
+
+ kfree(buf->sgt);
+ buf->sgt = NULL;
+}
+
static int exynos_drm_gem_handle_create(struct drm_gem_object *obj,
struct drm_file *file_priv,
unsigned int *handle)
@@ -293,6 +365,8 @@ void exynos_drm_gem_destroy(struct exynos_drm_gem_obj
*exynos_gem_obj)
if (exynos_gem_obj->flags & EXYNOS_BO_NONCONTIG)
exynos_drm_gem_put_pages(obj);
+ else if (exynos_gem_obj->flags & EXYNOS_BO_USERPTR)
+ exynos_drm_put_userptr(obj);
else
exynos_drm_free_buf(obj->dev, exynos_gem_obj->flags, buf);
@@ -606,6 +680,197 @@ int exynos_drm_gem_mmap_ioctl(struct drm_device *dev,
void *data,
return 0;
}
+static int exynos_drm_get_userptr(struct drm_device *dev,
+ struct exynos_drm_gem_obj *obj,
+ unsigned long userptr,
+ unsigned int write)
+{
+ unsigned int get_npages;
+ unsigned long npages = 0;
+ struct vm_area_struct *vma;
+ struct
[PATCH v2 3/4] drm/exynos: added userptr feature.
this feature could be used to use memory region allocated by malloc() in user
mode and mmaped memory region allocated by other memory allocators. userptr
interface can identify memory type through vm_flags value and would get
pages or page frame numbers to user space appropriately.
changelog v2:
the memory region mmaped with VM_PFNMAP type is physically continuous and
start address of the memory region should be set into buf-dma_addr but
previous patch had a problem that end address is set into buf-dma_addr
so v2 fixes that problem.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_drv.c |2 +
drivers/gpu/drm/exynos/exynos_drm_gem.c | 265 +++
drivers/gpu/drm/exynos/exynos_drm_gem.h | 13 ++-
include/drm/exynos_drm.h| 25 +++-
4 files changed, 303 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index f58a487..5bb0361 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -211,6 +211,8 @@ static struct drm_ioctl_desc exynos_ioctls[] = {
DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(EXYNOS_GEM_USERPTR,
+ exynos_drm_gem_userptr_ioctl, DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(EXYNOS_PLANE_SET_ZPOS, exynos_plane_set_zpos_ioctl,
DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index afd0cd4..1ee5383 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -66,6 +66,43 @@ static int check_gem_flags(unsigned int flags)
return 0;
}
+static struct vm_area_struct *get_vma(struct vm_area_struct *vma)
+{
+ struct vm_area_struct *vma_copy;
+
+ vma_copy = kmalloc(sizeof(*vma_copy), GFP_KERNEL);
+ if (!vma_copy)
+ return NULL;
+
+ if (vma-vm_ops vma-vm_ops-open)
+ vma-vm_ops-open(vma);
+
+ if (vma-vm_file)
+ get_file(vma-vm_file);
+
+ memcpy(vma_copy, vma, sizeof(*vma));
+
+ vma_copy-vm_mm = NULL;
+ vma_copy-vm_next = NULL;
+ vma_copy-vm_prev = NULL;
+
+ return vma_copy;
+}
+
+static void put_vma(struct vm_area_struct *vma)
+{
+ if (!vma)
+ return;
+
+ if (vma-vm_ops vma-vm_ops-close)
+ vma-vm_ops-close(vma);
+
+ if (vma-vm_file)
+ fput(vma-vm_file);
+
+ kfree(vma);
+}
+
static void update_vm_cache_attr(struct exynos_drm_gem_obj *obj,
struct vm_area_struct *vma)
{
@@ -254,6 +291,41 @@ static void exynos_drm_gem_put_pages(struct drm_gem_object
*obj)
/* add some codes for UNCACHED type here. TODO */
}
+static void exynos_drm_put_userptr(struct drm_gem_object *obj)
+{
+ struct exynos_drm_gem_obj *exynos_gem_obj;
+ struct exynos_drm_gem_buf *buf;
+ struct vm_area_struct *vma;
+ int npages;
+
+ exynos_gem_obj = to_exynos_gem_obj(obj);
+ buf = exynos_gem_obj-buffer;
+ vma = exynos_gem_obj-vma;
+
+ if (vma (vma-vm_flags VM_PFNMAP) (vma-vm_pgoff)) {
+ put_vma(exynos_gem_obj-vma);
+ goto out;
+ }
+
+ npages = buf-size PAGE_SHIFT;
+
+ npages--;
+ while (npages = 0) {
+ if (buf-write)
+ set_page_dirty_lock(buf-pages[npages]);
+
+ put_page(buf-pages[npages]);
+ npages--;
+ }
+
+out:
+ kfree(buf-pages);
+ buf-pages = NULL;
+
+ kfree(buf-sgt);
+ buf-sgt = NULL;
+}
+
static int exynos_drm_gem_handle_create(struct drm_gem_object *obj,
struct drm_file *file_priv,
unsigned int *handle)
@@ -293,6 +365,8 @@ void exynos_drm_gem_destroy(struct exynos_drm_gem_obj
*exynos_gem_obj)
if (exynos_gem_obj-flags EXYNOS_BO_NONCONTIG)
exynos_drm_gem_put_pages(obj);
+ else if (exynos_gem_obj-flags EXYNOS_BO_USERPTR)
+ exynos_drm_put_userptr(obj);
else
exynos_drm_free_buf(obj-dev, exynos_gem_obj-flags, buf);
@@ -606,6 +680,197 @@ int exynos_drm_gem_mmap_ioctl(struct drm_device *dev,
void *data,
return 0;
}
+static int exynos_drm_get_userptr(struct drm_device *dev,
+ struct exynos_drm_gem_obj *obj,
+ unsigned long userptr,
+ unsigned int write)
+{
+ unsigned int get_npages;
+ unsigned long npages = 0;
+ struct vm_area_struct *vma;
+ struct
