All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arto Merilainen <amerilainen@nvidia.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: "linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	Terje Bergstrom <tbergstrom@nvidia.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.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

WARNING: multiple messages have this Message-ID (diff)
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:22 UTC|newest]

Thread overview: 46+ 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 ` Arto Merilainen
     [not found] ` <1368791388-31441-1-git-send-email-amerilainen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-05-17 11:49   ` [PATCH 1/6] gpu: host1x: Fixes to host1x firewall Arto Merilainen
2013-05-17 11:49     ` Arto Merilainen
     [not found]     ` <1368791388-31441-2-git-send-email-amerilainen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-05-26 10:02       ` Thierry Reding
2013-05-26 10:02         ` Thierry Reding
2013-05-27  6:22         ` Arto Merilainen [this message]
2013-05-27  6:22           ` Arto Merilainen
2013-05-17 11:49   ` [PATCH 3/6] gpu: host1x: Fix memory access in syncpt request Arto Merilainen
2013-05-17 11:49     ` Arto Merilainen
     [not found]     ` <1368791388-31441-4-git-send-email-amerilainen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-05-26 10:15       ` Thierry Reding
2013-05-26 10:15         ` Thierry Reding
2013-05-27  6:56         ` Arto Merilainen
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-17 11:49     ` Arto Merilainen
     [not found]     ` <1368791388-31441-5-git-send-email-amerilainen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-05-26 10:17       ` Thierry Reding
2013-05-26 10:17         ` Thierry Reding
2013-05-17 11:49 ` [PATCH 2/6] gpu: host1x: Fix syncpoint wait return value Arto Merilainen
2013-05-17 11:49   ` Arto Merilainen
     [not found]   ` <1368791388-31441-3-git-send-email-amerilainen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-05-26 10:12     ` Thierry Reding
2013-05-26 10:12       ` Thierry Reding
2013-05-27  6:55       ` Arto Merilainen
2013-05-27  6:55         ` Arto Merilainen
     [not found]         ` <51A30372.6080907-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-05-28 10:39           ` Thierry Reding
2013-05-28 10:39             ` Thierry Reding
2013-05-28 19:12             ` Keith Packard
2013-05-28 19:12               ` Keith Packard
     [not found]               ` <86y5ay6hrn.fsf-07MG1JmyPZaz9DMzp4kqnw@public.gmane.org>
2013-06-11 10:48                 ` Thierry Reding
2013-06-11 10:48                   ` Thierry Reding
2013-06-11 11:00                   ` Daniel Vetter
2013-06-11 11:00                     ` Daniel Vetter
2013-06-11 11:43                     ` Terje Bergström
2013-06-11 12:09                       ` Daniel Vetter
     [not found]                         ` <CAKMK7uGRW4uqsSaDEehTZwknZH+mNEgyKB6-4TgfgUOaTOcoLA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-11 18:19                           ` Thierry Reding
2013-06-11 18:19                             ` Thierry Reding
2013-06-12 10:28                         ` Terje Bergström
2013-06-12 11:00                           ` Daniel Vetter
2013-05-17 11:49 ` [PATCH 5/6] gpu: host1x: Rework CPU syncpoint increment Arto Merilainen
2013-05-17 11:49   ` Arto Merilainen
     [not found]   ` <1368791388-31441-6-git-send-email-amerilainen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-05-26 10:24     ` Thierry Reding
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-17 11:49   ` Arto Merilainen
     [not found]   ` <1368791388-31441-7-git-send-email-amerilainen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-05-26 10:26     ` Thierry Reding
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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.