linux-kernel - Re: [PATCH v1 5/5] misc: fastrpc: Add missing unmapping user-requested remote heap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7505f0e8-222d-4052-8614-c12109d14bce@oss.qualcomm.com>
Date: Thu, 12 Jun 2025 15:02:52 +0530
From: Ekansh Gupta <ekansh.gupta@....qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: srinivas.kandagatla@....qualcomm.com, linux-arm-msm@...r.kernel.org,
        gregkh@...uxfoundation.org, quic_bkumar@...cinc.com,
        linux-kernel@...r.kernel.org, quic_chennak@...cinc.com,
        dri-devel@...ts.freedesktop.org, arnd@...db.de, stable@...nel.org
Subject: Re: [PATCH v1 5/5] misc: fastrpc: Add missing unmapping
 user-requested remote heap



On 6/12/2025 1:35 PM, Dmitry Baryshkov wrote:
> On Thu, Jun 12, 2025 at 10:50:10AM +0530, Ekansh Gupta wrote:
>>
>> On 5/22/2025 5:43 PM, Dmitry Baryshkov wrote:
>>> On Thu, 22 May 2025 at 08:01, Ekansh Gupta
>>> <ekansh.gupta@....qualcomm.com> wrote:
>>>>
>>>> On 5/19/2025 7:04 PM, Dmitry Baryshkov wrote:
>>>>> On Mon, May 19, 2025 at 04:28:34PM +0530, Ekansh Gupta wrote:
>>>>>> On 5/19/2025 4:22 PM, Dmitry Baryshkov wrote:
>>>>>>> On Tue, May 13, 2025 at 09:58:25AM +0530, Ekansh Gupta wrote:
>>>>>>>> User request for remote heap allocation is supported using ioctl
>>>>>>>> interface but support for unmap is missing. This could result in
>>>>>>>> memory leak issues. Add unmap user request support for remote heap.
>>>>>>> Can this memory be in use by the remote proc?
>>>>>> Remote heap allocation request is only intended for audioPD. Other PDs
>>>>>> running on DSP are not intended to use this request.
>>>>> 'Intended'. That's fine. I asked a different question: _can_ it be in
>>>>> use? What happens if userspace by mistake tries to unmap memory too
>>>>> early? Or if it happens intentionally, at some specific time during
>>>>> work.
>>>> If the unmap is restricted to audio daemon, then the unmap will only
>>>> happen if the remoteproc is no longer using this memory.
>>>>
>>>> But without this restriction, yes it possible that some userspace process
>>>> calls unmap which tries to move the ownership back to HLOS which the
>>>> remoteproc is still using the memory. This might lead to memory access
>>>> problems.
>>> This needs to be fixed in the driver. We need to track which memory is
>>> being used by the remoteproc and unmap it once remoteproc stops using
>>> it, without additional userspace intervention.
>> If it's the audio daemon which is requesting for unmap then it basically means that
>> the remoteproc is no longer using the memory. Audio PD can request for both grow
>> and shrink operations for it's dedicated heap. The case of grow is already supported
>> from fastrpc_req_mmap but the case of shrink(when remoteproc is no longer using the
>> memory) is not yet available. This memory is more specific to audio PD rather than
>> complete remoteproc.
>>
>> If we have to control this completely from driver then I see a problem in freeing/unmapping
>> the memory when the PD is no longer using the memory.
> What happens if userspace requests to free the memory that is still in
> use by the PD
I understand your point, for this I was thinking to limit the unmap functionality to the process
that is already attached to audio PD on DSP, no other process will be able to map/unmap this
memory from userspace.

>
> How does PD signal the memory is no longer in use?
PD makes a reverse fastrpc request[1] to unmap the memory when it is no longer used.

[1] https://github.com/quic/fastrpc/blob/development/src/apps_mem_imp.c#L231
>