From: Arto Merilainen <amerilainen@nvidia.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: "airlied@linux.ie" <airlied@linux.ie>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
Terje Bergstrom <tbergstrom@nvidia.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/6] gpu: host1x: Fixes to host1x firewall
Date: Mon, 27 May 2013 09:22:15 +0300 [thread overview]
Message-ID: <51A2FB97.4040505@nvidia.com> (raw)
In-Reply-To: <20130526100240.GA1652@mithrandir>
On 05/26/2013 01:02 PM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Fri, May 17, 2013 at 02:49:43PM +0300, Arto Merilainen wrote:
>> From: Terje Bergstrom <tbergstrom@nvidia.com>
>>
>> This patch adds several fixes to host1x firewall:
>> - Host1x firewall does not survive if it expects a reloc, but user
>> space didn't pass any relocs. Also it reset the reloc table for
>> each gather, whereas they should be reset only per submit. Also
>> class does not need to be reset for each class - once per submit
>> is enough.
>> - For INCR opcode the check was not working properly at all.
>> - The firewall verified gather buffers before copying them. This
>> allowed a malicious application to rewrite the buffer content by
>> timing the rewrite carefully. This patch makes the buffer
>> validation occur after copying the buffers.
>
> Can these be split into separate patches, please? It's not only always
> good to split logical changes into separate patches but it also makes
> reviewing a lot more pleasant. It's hard to tell from this combined
> patch which changes belong together.
Sure.
>
> I have a few additional comments inline.
>
>> diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
>> index f665d67..4f3c004 100644
>> --- a/drivers/gpu/host1x/job.c
>> +++ b/drivers/gpu/host1x/job.c
>> @@ -228,17 +228,15 @@ static unsigned int do_relocs(struct host1x_job *job, struct host1x_bo *cmdbuf)
>> void *cmdbuf_page_addr = NULL;
>>
>> /* pin & patch the relocs for one gather */
>> - while (i < job->num_relocs) {
>> + for (i = 0; i < job->num_relocs; ++i) {
>
> Nit: I prefer post-increment where possible. For consistency.
Will do.
>
>> @@ -268,15 +263,15 @@ static unsigned int do_relocs(struct host1x_job *job, struct host1x_bo *cmdbuf)
>> return 0;
>> }
>>
>> -static int check_reloc(struct host1x_reloc *reloc, struct host1x_bo *cmdbuf,
>> - unsigned int offset)
>> +static bool check_reloc(struct host1x_reloc *reloc, struct host1x_bo *cmdbuf,
>> + unsigned int offset)
>> {
>> offset *= sizeof(u32);
>>
>> - if (reloc->cmdbuf != cmdbuf || reloc->cmdbuf_offset != offset)
>> - return -EINVAL;
>> + if (!reloc || reloc->cmdbuf != cmdbuf || reloc->cmdbuf_offset != offset)
>
> Is the additional !reloc check really necessary? Looking at the callers,
> they always pass in fw->relocarray, which in turn is only NULL if no
> buffers are to be relocated.
Yes, the additional check is necessary exactly for that reason. The code
will fail if the userspace does not deliver a relocation array and still
pushes data to an address register.
However, the code *should* check that there are relocations left before
even coming here so I probably just fix this differently.
>
>> + return true;
>>
>> - return 0;
>> + return false;
>> }
>
> I wonder whether we should be changing the logic here and have the
> check_reloc() function return true if the relocation is good. I find
> that to be more intuitive.
>
I was also thinking that earlier. Will do.
>> @@ -508,6 +502,7 @@ int host1x_job_pin(struct host1x_job *job, struct device *dev)
>> int err;
>> unsigned int i, j;
>> struct host1x *host = dev_get_drvdata(dev->parent);
>> +
>> DECLARE_BITMAP(waitchk_mask, host1x_syncpt_nb_pts(host));
>
> This is an unnecessary whitespace change.
Ops. Will fix.
- Arto
next prev parent reply other threads:[~2013-05-27 6:28 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-17 11:49 [PATCH 0/6] Miscellaneous fixes to host1x Arto Merilainen
2013-05-17 11:49 ` [PATCH 1/6] gpu: host1x: Fixes to host1x firewall Arto Merilainen
2013-05-26 10:02 ` Thierry Reding
2013-05-27 6:22 ` Arto Merilainen [this message]
2013-05-17 11:49 ` [PATCH 2/6] gpu: host1x: Fix syncpoint wait return value Arto Merilainen
2013-05-26 10:12 ` Thierry Reding
2013-05-27 6:55 ` Arto Merilainen
2013-05-28 10:39 ` Thierry Reding
2013-05-28 19:12 ` Keith Packard
2013-06-11 10:48 ` Thierry Reding
2013-06-11 11:00 ` Daniel Vetter
[not found] ` <51B70D52.9060601@nvidia.com>
2013-06-11 12:09 ` Daniel Vetter
2013-06-11 18:19 ` Thierry Reding
[not found] ` <51B84D4E.30703@nvidia.com>
2013-06-12 11:00 ` Daniel Vetter
2013-05-17 11:49 ` [PATCH 3/6] gpu: host1x: Fix memory access in syncpt request Arto Merilainen
2013-05-26 10:15 ` Thierry Reding
2013-05-27 6:56 ` Arto Merilainen
2013-05-17 11:49 ` [PATCH 4/6] gpu: host1x: Fix client_managed type Arto Merilainen
2013-05-26 10:17 ` Thierry Reding
2013-05-17 11:49 ` [PATCH 5/6] gpu: host1x: Rework CPU syncpoint increment Arto Merilainen
2013-05-26 10:24 ` Thierry Reding
2013-05-17 11:49 ` [PATCH 6/6] drm/tegra: Fix syncpoint increment return code Arto Merilainen
2013-05-26 10:26 ` Thierry Reding
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51A2FB97.4040505@nvidia.com \
--to=amerilainen@nvidia.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=tbergstrom@nvidia.com \
--cc=thierry.reding@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox