linux-stable.git/drivers/misc/fastrpc.c, branch linux-6.3.y

misc: fastrpc: Pass proper scm arguments for secure map request

2023-06-09T08:48:19+00:00

[ Upstream commit a6e766dea0a22918735176e4af862d535962f11e ]

If a map request is made with securemap attribute, the memory
ownership needs to be reassigned to new VMID to allow access
from protection domain. Currently only DSP VMID is passed to
the reassign call which is incorrect as only a combination of
HLOS and DSP VMID is allowed for memory ownership reassignment
and passing only DSP VMID will cause assign call failure.

Also pass proper restoring permissions to HLOS as the source
permission will now carry both HLOS and DSP VMID permission.

Change is also made to get valid physical address from
scatter/gather for this allocation request.

Fixes: e90d91190619 ("misc: fastrpc: Add support to secure memory map")
Cc: stable 
Tested-by: Ekansh Gupta 
Signed-off-by: Ekansh Gupta 
Signed-off-by: Srinivas Kandagatla 
Link: https://lore.kernel.org/r/20230523152550.438363-2-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

firmware: qcom_scm: Use fixed width src vm bitmap

2023-06-09T08:48:18+00:00

[ Upstream commit 968a26a07f75377afbd4f7bb18ef587a1443c244 ]

The maximum VMID for assign_mem is 63. Use a u64 to represent this
bitmap instead of architecture-dependent "unsigned int" which varies in
size on 32-bit and 64-bit platforms.

Acked-by: Kalle Valo  (ath10k)
Tested-by: Gokul krishna Krishnakumar 
Signed-off-by: Elliot Berman 
Reviewed-by: Bjorn Andersson 
Signed-off-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20230213181832.3489174-1-quic_eberman@quicinc.com
Stable-dep-of: a6e766dea0a2 ("misc: fastrpc: Pass proper scm arguments for secure map request")
Signed-off-by: Sasha Levin

misc: fastrpc: reject new invocations during device removal

2023-06-09T08:48:16+00:00

commit 46248400d81e2aa0b65cd659d6f40188192a58b6 upstream.

The channel's rpmsg object allows new invocations to be made. After old
invocations are already interrupted, the driver shouldn't try to invoke
anymore. Invalidating the rpmsg at the end of the driver removal
function makes it easy to cause a race condition in userspace. Even
closing a file descriptor before the driver finishes its cleanup can
cause an invocation via fastrpc_release_current_dsp_process() and
subsequent timeout.

Invalidate the channel before the invocations are interrupted to make
sure that no invocations can be created to hang after the device closes.

Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method")
Cc: stable 
Signed-off-by: Richard Acayan 
Signed-off-by: Srinivas Kandagatla 
Link: https://lore.kernel.org/r/20230523152550.438363-5-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman

misc: fastrpc: return -EPIPE to invocations on device removal

2023-06-09T08:48:16+00:00

commit b6a062853ddf6b4f653af2d8b75ba45bb9a036ad upstream.

The return value is initialized as -1, or -EPERM. The completion of an
invocation implies that the return value is set appropriately, but
"Permission denied" does not accurately describe the outcome of the
invocation. Set the invocation's return value to a more appropriate
"Broken pipe", as the cleanup breaks the driver's connection with rpmsg.

Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method")
Cc: stable 
Signed-off-by: Richard Acayan 
Reviewed-by: Srinivas Kandagatla 
Signed-off-by: Srinivas Kandagatla 
Link: https://lore.kernel.org/r/20230523152550.438363-4-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

misc: fastrpc: Reassign memory ownership only for remote heap

2023-06-09T08:48:15+00:00

commit 3c7d0079a1831118ef232bd9c2f34d058a1f31c2 upstream.

The userspace map request for remote heap allocates CMA memory.
The ownership of this memory needs to be reassigned to proper
owners to allow access from the protection domain running on
DSP. This reassigning of ownership is not correct if done for
any other supported flags.

When any other flag is requested from userspace, fastrpc is
trying to reassign the ownership of memory and this reassignment
is getting skipped for remote heap request which is incorrect.
Add proper flag check to reassign the memory only if remote heap
is requested.

Fixes: 532ad70c6d44 ("misc: fastrpc: Add mmap request assigning for static PD pool")
Cc: stable 
Tested-by: Ekansh Gupta 
Signed-off-by: Ekansh Gupta 
Reviewed-by: Srinivas Kandagatla 
Signed-off-by: Srinivas Kandagatla 
Link: https://lore.kernel.org/r/20230523152550.438363-3-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman

Merge tag 'soc-drivers-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

2023-02-27T18:04:49+00:00

Pull ARM SoC driver updates from Arnd Bergmann:
 "As usual, there are lots of minor driver changes across SoC platforms
  from NXP, Amlogic, AMD Zynq, Mediatek, Qualcomm, Apple and Samsung.
  These usually add support for additional chip variations in existing
  drivers, but also add features or bugfixes.

  The SCMI firmware subsystem gains a unified raw userspace interface
  through debugfs, which can be used for validation purposes.

  Newly added drivers include:

   - New power management drivers for StarFive JH7110, Allwinner D1 and
     Renesas RZ/V2M

   - A driver for Qualcomm battery and power supply status

   - A SoC device driver for identifying Nuvoton WPCM450 chips

   - A regulator coupler driver for Mediatek MT81xxv"

* tag 'soc-drivers-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (165 commits)
  power: supply: Introduce Qualcomm PMIC GLINK power supply
  soc: apple: rtkit: Do not copy the reg state structure to the stack
  soc: sunxi: SUN20I_PPU should depend on PM
  memory: renesas-rpc-if: Remove redundant division of dummy
  soc: qcom: socinfo: Add IDs for IPQ5332 and its variant
  dt-bindings: arm: qcom,ids: Add IDs for IPQ5332 and its variant
  dt-bindings: power: qcom,rpmpd: add RPMH_REGULATOR_LEVEL_LOW_SVS_L1
  firmware: qcom_scm: Move qcom_scm.h to include/linux/firmware/qcom/
  MAINTAINERS: Update qcom CPR maintainer entry
  dt-bindings: firmware: document Qualcomm SM8550 SCM
  dt-bindings: firmware: qcom,scm: add qcom,scm-sa8775p compatible
  soc: qcom: socinfo: Add Soc IDs for IPQ8064 and variants
  dt-bindings: arm: qcom,ids: Add Soc IDs for IPQ8064 and variants
  soc: qcom: socinfo: Add support for new field in revision 17
  soc: qcom: smd-rpm: Add IPQ9574 compatible
  soc: qcom: pmic_glink: remove redundant calculation of svid
  soc: qcom: stats: Populate all subsystem debugfs files
  dt-bindings: soc: qcom,rpmh-rsc: Update to allow for generic nodes
  soc: qcom: pmic_glink: add CONFIG_NET/CONFIG_OF dependencies
  soc: qcom: pmic_glink: Introduce altmode support
  ...

firmware: qcom_scm: Move qcom_scm.h to include/linux/firmware/qcom/

2023-02-09T03:15:16+00:00

Move include/linux/qcom_scm.h to include/linux/firmware/qcom/qcom_scm.h.
This removes 1 of a few remaining Qualcomm-specific headers into a more
approciate subdirectory under include/.

Suggested-by: Bjorn Andersson 
Signed-off-by: Elliot Berman 
Reviewed-by: Guru Das Srinagesh 
Acked-by: Mukesh Ojha 
Signed-off-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20230203210956.3580811-1-quic_eberman@quicinc.com

Merge 6.2-rc5 into char-misc-next

2023-01-22T07:37:23+00:00

We need the char/misc driver fixes in here as well.

Signed-off-by: Greg Kroah-Hartman

misc: fastrpc: Pass bitfield into qcom_scm_assign_mem

2023-01-20T12:23:57+00:00

The srcvm parameter of qcom_scm_assign_mem is a pointer to a bitfield of
VMIDs. The  bitfield is updated with which VMIDs have permissions
after the qcom_scm_assign_mem call. This makes it simpler for clients to
make qcom_scm_assign_mem calls later, they always pass in same srcvm
bitfield and do not need to closely track whether memory was originally
shared.

When restoring permissions to HLOS, fastrpc is incorrectly using the
first VMID directly -- neither the BIT nor the other possible VMIDs the
memory was already assigned to.  We already have a field intended for
this purpose: "perms" in the struct fastrpc_channel_ctx, but it was
never used. Start using the perms field.

Cc: Abel Vesa 
Cc: Vamsi Krishna Gattupalli 
Cc: Srinivas Kandagatla 
Fixes: e90d91190619 ("misc: fastrpc: Add support to secure memory map")
Fixes: 0871561055e6 ("misc: fastrpc: Add support for audiopd")
Fixes: 532ad70c6d44 ("misc: fastrpc: Add mmap request assigning for static PD pool")
Tested-by: Srinivas Kandagatla 
Signed-off-by: Elliot Berman 

drivers/misc/fastrpc.c | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

Link: https://lore.kernel.org/r/20230112182313.521467-1-quic_eberman@quicinc.com
Signed-off-by: Greg Kroah-Hartman

misc: fastrpc: Fix use-after-free race condition for maps

2023-01-20T12:23:11+00:00

It is possible that in between calling fastrpc_map_get() until
map->fl->lock is taken in fastrpc_free_map(), another thread can call
fastrpc_map_lookup() and get a reference to a map that is about to be
deleted.

Rewrite fastrpc_map_get() to only increase the reference count of a map
if it's non-zero. Propagate this to callers so they can know if a map is
about to be deleted.

Fixes this warning:
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 5 PID: 10100 at lib/refcount.c:25 refcount_warn_saturate
...
Call trace:
 refcount_warn_saturate
 [fastrpc_map_get inlined]
 [fastrpc_map_lookup inlined]
 fastrpc_map_create
 fastrpc_internal_invoke
 fastrpc_device_ioctl
 __arm64_sys_ioctl
 invoke_syscall

Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method")
Cc: stable 
Signed-off-by: Ola Jeppsson 
Signed-off-by: Abel Vesa 
Signed-off-by: Srinivas Kandagatla 
Link: https://lore.kernel.org/r/20221124174941.418450-4-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman