public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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