From mboxrd@z Thu Jan 1 00:00:00 1970 From: Serguei Sagalovitch Subject: Re: [RFC] drm/radeon: userfence IOCTL Date: Mon, 13 Apr 2015 11:52:19 -0400 Message-ID: <552BE633.9020306@amd.com> References: <1428936737-19103-1-git-send-email-deathsimple@vodafone.de> <552BDFEA.6070806@amd.com> <20150413153935.GB29334@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1850369232==" Return-path: Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0107.outbound.protection.outlook.com [65.55.169.107]) by gabe.freedesktop.org (Postfix) with ESMTP id 409DC6E11D for ; Mon, 13 Apr 2015 09:25:49 -0700 (PDT) In-Reply-To: <20150413153935.GB29334@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Jerome Glisse Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1850369232== Content-Type: multipart/alternative; boundary="------------080904040700070401070900" --------------080904040700070401070900 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: quoted-printable > Given that the userspace wait fence ioctl has not way to know which=20 command buffer it is really waiting after then kernel has no knowledge=20 of if this user fence will signal at all. We could pass BO handle as parameter in the "fence ioctl" to rely on it=20 so kernel will know which BO it is waiting. > So a malicious user space (we always have to assume this thing exist)=20 could create a big VRAM BO and effectively pin it in VRAM leading to a=20 GPU DOS (denial of service). This problem always exists. Malicious user space could allocate big BO=20 and then submit shader running in loop which read/write from this BO. =20 It could also spawn processes which will do the same thing. IMHO the=20 only way to improve situation is to have GPU Scheduler to allow=20 "unloading" such application. Sincerely yours, Serguei Sagalovitch On 15-04-13 11:39 AM, Jerome Glisse wrote: > On Mon, Apr 13, 2015 at 11:25:30AM -0400, Serguei Sagalovitch wrote: >>> the BO to be kept in the same place while it is mapped inside the ker= nel >> page table >> ... >>> So this requires that we pin down the BO for the duration of the wait >> IOCTL. >> >> But my understanding is that it should be not duration of "wait" IOCTL= but >> "duration" of command buffer execution. >> >> BTW: I would assume that this is not the new scenario. >> >> This is scenario: >> - User allocate BO >> - User get CPU address for BO >> - User submit command buffer to write to BO >> - User could "poll" / "read" or "write" BO data by CPU >> >> So when TTM needs to move BO to another location it should also upda= te CPU >> "mapping" correctly so user will always read / write the correct data. >> >> Did I miss anything? > No this is how things works. But we want to avoid pinning buffer. > One use case for this userspace fence is i assume same BO same > user fence use accross several command buffer. Given that the > userspace wait fence ioctl has not way to know which command > buffer it is really waiting after then kernel has no knowledge > of if this user fence will signal at all. So a malicious user > space (we always have to assume this thing exist) could create > a big VRAM BO and effectively pin it in VRAM leading to a GPU > DOS (denial of service). > > By the way Christian, i would add a timeout to this ioctl and > return eagain to userspace on timeout so that userspace can > resumit. That way a malicious userspace will just keep exhausting > its cpu timeslot. > > Cheers, > J=E9r=F4me --------------080904040700070401070900 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable > Given that the userspace wait fence ioctl has not way to know which command buffer it is really waiting after then kernel has no knowledge of if this user fence will signal at all.
We could pass BO handle as=A0 parameter in the "fence ioctl" to rely on it so kernel will know which BO=A0 it is waiting.


> So a malicious user space (we always have to assume this thing exist) could create a big VRAM BO and effectively pin it in VRAM leading to a GPU DOS (denial of service).
This problem=A0 always exists. Malicious user space could allocate bi= g BO and then submit shader running in loop which read/write from this BO.=A0 It could also spawn processes which will do the same thing. IMHO the only way to improve situation is=A0 to have GPU Scheduler to allow "unloading" such application.

Sincerely yours,
Serguei Sagalovitch

On 15-04-13 11:39 AM, Jerome Glisse wrote:
On Mon, Apr 13, 2015 at 11:25:30AM -0400, Serguei Sa=
galovitch wrote:

the BO to be kept in the same place while it is =
mapped inside the kernel

page table
...

So this requires that we pin down the BO for the=
 duration of the wait

IOCTL.

But my understanding is that it should be not duration of "wait" IOCTL bu=
t
"duration" of command buffer execution.

BTW: I would assume that this is not the new scenario.

 This is scenario:
    - User allocate BO
    - User get CPU address for BO
    - User submit command buffer to write to BO
    - User could "poll" / "read" or "write" BO data by CPU

So when  TTM needs  to move BO to another location it should also update =
CPU
"mapping" correctly so user will always read / write the correct data.

Did I miss anything?

No this is how things works. But we want to avoid pinning buffer.
One use case for this userspace fence is i assume same BO same
user fence use accross several command buffer. Given that the
userspace wait fence ioctl has not way to know which command
buffer it is really waiting after then kernel has no knowledge
of if this user fence will signal at all. So a malicious user
space (we always have to assume this thing exist) could create
a big VRAM BO and effectively pin it in VRAM leading to a GPU
DOS (denial of service).

By the way Christian, i would add a timeout to this ioctl and
return eagain to userspace on timeout so that userspace can
resumit. That way a malicious userspace will just keep exhausting
its cpu timeslot.

Cheers,
J=E9r=F4me

--------------080904040700070401070900-- --===============1850369232== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============1850369232==--