From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
To: Jonathan Marek <jonathan@marek.ca>, linux-arm-msm@vger.kernel.org
Cc: Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/3] fastrpc: remove redundant fastrpc_map_create() call
Date: Tue, 23 Feb 2021 09:43:53 +0000 [thread overview]
Message-ID: <9af55046-043b-13e1-a2bb-14b21272ea32@linaro.org> (raw)
In-Reply-To: <66afb839-7cd9-875c-72ea-f3236678f9f9@marek.ca>
On 22/02/2021 13:53, Jonathan Marek wrote:
> On 2/22/21 7:37 AM, Srinivas Kandagatla wrote:
>>
>>
>> On 18/02/2021 03:20, Jonathan Marek wrote:
>>> fastrpc_internal_invoke() will call fastrpc_map_create, so there is no
>>> point in having it called here. This does change the behavior
>>> somewhat as
>>> fastrpc_internal_invoke() will release the map afterwards, but that's
>>> what
>>> we want to happen in this case.
>>
>> This will crash the DSP as you will be freeing the init process memory
>> while it is actively using it!
>>
>> The shell/init process is created as part of user process and it
>> should be valid until the user process is valid! We can not free it
>> when the invoke is finished/acked as we normally do for other invoke
>> context!
>>
>> In some firmwares the shell process is statically built into the DSP
>> firmware which might work! But other normal cases are totally broken
>> by this patch!
>>
>> --srini
>>
>
> I am not using the static guest process, I am using the
> FASTRPC_IOCTL_INIT_CREATE to load a fastrpc shell process. It doesn't
> crash.
>
> AFAIK the DSP does not need the process memory after the process
> creation - this would allow userspace to modify the executable after the
This process memory includes memory to load shell and the heap(complete
process memory) so it should be kept till the process dies!
--srini
> DSP verifies the hash/signature. So the DSP absolutely needs to make a
> copy of it before verifying it (otherwise this would be a pretty serious
> and obvious security flaw in qcom's fastrpc system. but I wouldn't be
> surprised!).
>
>>>
>>> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
>>> ---
>>> drivers/misc/fastrpc.c | 12 +-----------
>>> 1 file changed, 1 insertion(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
>>> index 170352b43ab6..ccad9f5f5e2f 100644
>>> --- a/drivers/misc/fastrpc.c
>>> +++ b/drivers/misc/fastrpc.c
>>> @@ -1013,7 +1013,6 @@ static int fastrpc_init_create_process(struct
>>> fastrpc_user *fl,
>>> struct fastrpc_init_create init;
>>> struct fastrpc_invoke_args *args;
>>> struct fastrpc_phy_page pages[1];
>>> - struct fastrpc_map *map = NULL;
>>> struct fastrpc_buf *imem = NULL;
>>> int memlen;
>>> int err;
>>> @@ -1049,18 +1048,12 @@ static int fastrpc_init_create_process(struct
>>> fastrpc_user *fl,
>>> inbuf.siglen = init.siglen;
>>> fl->pd = USER_PD;
>>> - if (init.filelen && init.filefd) {
>>> - err = fastrpc_map_create(fl, init.filefd, init.filelen, &map);
>>> - if (err)
>>> - goto err;
>>> - }
>>> - > memlen = ALIGN(max(INIT_FILELEN_MAX, (int)init.filelen * 4),
>>> 1024 * 1024);
>>> err = fastrpc_buf_alloc(fl, fl->sctx->dev, memlen,
>>> &imem);
>>> if (err)
>>> - goto err_alloc;
>>> + goto err;
>>> fl->init_mem = imem;
>>> args[0].ptr = (u64)(uintptr_t)&inbuf;
>>> @@ -1106,9 +1099,6 @@ static int fastrpc_init_create_process(struct
>>> fastrpc_user *fl,
>>> err_invoke:
>>> fl->init_mem = NULL;
>>> fastrpc_buf_free(imem);
>>> -err_alloc:
>>> - if (map)
>>> - fastrpc_map_put(map);
>>> err:
>>> kfree(args);
>>>
prev parent reply other threads:[~2021-02-23 9:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-18 3:20 [PATCH 0/3] fastrpc: fix dmabuf arguments Jonathan Marek
2021-02-18 3:20 ` [PATCH 1/3] fastrpc: always use fl->lock and remove fl->mutex Jonathan Marek
2021-02-18 3:20 ` [PATCH 2/3] fastrpc: move fl->maps list removal into fastrpc_free_map Jonathan Marek
2021-02-18 3:20 ` [PATCH 3/3] fastrpc: remove redundant fastrpc_map_create() call Jonathan Marek
2021-02-22 12:37 ` Srinivas Kandagatla
2021-02-22 13:53 ` Jonathan Marek
2021-02-23 9:43 ` Srinivas Kandagatla [this message]
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=9af55046-043b-13e1-a2bb-14b21272ea32@linaro.org \
--to=srinivas.kandagatla@linaro.org \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=jonathan@marek.ca \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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