| 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
| ||
|
Message-ID: <rb3xf7pumyegck2reyj73sfnpgeyr3sufgcycteozpquah5py4@jpjvcwy5k2kz>
Date: Fri, 29 Sep 2023 10:29:44 -0500
From: Andrew Halaney <ahalaney@...hat.com>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Maximilian Luz <luzmaximilian@...il.com>,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
kernel@...cinc.com,
Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH v2 00/11] arm64: qcom: add and enable SHM Bridge support
On Thu, Sep 28, 2023 at 11:20:29AM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
>
> This is technically the second iteration of the SHM Bridge enablement on
> QCom platforms but in practice it's a complete rewrite.
>
> During the internal discussion with QCom the requirement has been established
> as an SHM Bridge pool manager with the assumption that there will be multiple
> users, each with their own pool. The problem with this is that we don't have
> many potential users of SHM pools upstream at the moment which was rightfully
> pointed out in the reviews under v1 (which even had some unused symbols etc.).
>
> Moreover: after some investigating, it turns out that there simply isn't any
> need for multiple pools as the core SCM only allocates a buffer if given call
> requires more than 4 arguments and there are only a handful of SCM calls that
> need to pass a physical address to a buffer as argument to the trustzone.
>
> Additionally all but one SCM call allocate buffers passed to the TZ only for
> the duration of the call and then free it right aftr it returns. The one
> exception is called once and the buffer it uses can remain in memory until
> released by the user.
>
> This all makes using multiple pools wasteful as most of that memory will be
> reserved but remain unused 99% of the time. What we need is a single pool of
> SCM memory that deals out chunks of suitable format (coherent and
> page-aligned) that fulfills the requirements of all calls.
>
> As not all architectures support SHM bridge, it makes sense to first unify the
> memory operations in SCM calls. All users do some kind of DMA mapping to obtain
> buffers, most using dma_alloc_coherent() which impacts performance.
>
> Genalloc pools are very fast so let's use them instead. Create a custom
> allocator that also deals with the mapping and use it across all SCM calls.
>
> Then once this is done, let's extend the allocator to use the SHM bridge
> functionality if available on the given platform.
>
> While at it: let's create a qcom specific directory in drivers/firmware/ and
> move relevant code in there.
>
> I couldn't test all SCM calls but tested with the inline crypto engine on
> sm8550 and sa8775p that runs most of new code paths (with and without SHM
> bridge). At least qseecom would need some Tested-by.
I have been playing around with this on my x13s (sc8280xp). It seems
that efivars works ok (and therefore the qseecom stuff I believe), but
with these patches applied I'm getting -22 when loading any firmware.
I'll try to dig a little more, but thought I'd report that before I
context switch for a little bit.
dmesg | grep "firmware\|-22"
[ 0.000000] psci: PSCIv1.1 detected in firmware.
[ 2.351999] qcom_scm firmware:scm: SHM Bridge enabled
[ 2.353002] qcom_scm firmware:scm: qseecom: found qseecom with version 0x1402000
[ 6.727604] systemd[1]: systemd-pcrmachine.service - TPM2 PCR Machine ID Measurement was skipped because of an unmet condition check (ConditionPathExists=/sys/firmware/efi/efivars/StubPcrKernelImage-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f).
[ 8.198381] qcom_q6v5_pas 1b300000.remoteproc: error -22 initializing firmware qcom/sc8280xp/LENOVO/21BX/qccdsp8280.mbn
[ 8.198418] remoteproc remoteproc1: can't start rproc 1b300000.remoteproc: -22
[ 8.407641] qcom_q6v5_pas 3000000.remoteproc: error -22 initializing firmware qcom/sc8280xp/LENOVO/21BX/qcadsp8280.mbn
[ 8.407742] remoteproc remoteproc0: can't start rproc 3000000.remoteproc: -22
[ 8.588496] adreno 3d00000.gpu: error -22 initializing firmware qcom/sc8280xp/LENOVO/21BX/qcdxkmsuc8280.mbn
[ 8.588509] msm_dpu ae01000.display-controller: [drm:adreno_load_gpu [msm]] *ERROR* gpu hw init failed: -22
[ 9.392185] ath11k_pci 0006:01:00.0: fw_version 0x110b196e fw_build_timestamp 2022-12-22 12:54 fw_build_id WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
[ 10.229367] adreno 3d00000.gpu: error -22 initializing firmware qcom/sc8280xp/LENOVO/21BX/qcdxkmsuc8280.mbn
[ 10.229383] msm_dpu ae01000.display-controller: [drm:adreno_load_gpu [msm]] *ERROR* gpu hw init failed: -22
[ 11.041385] adreno 3d00000.gpu: error -22 initializing firmware qcom/sc8280xp/LENOVO/21BX/qcdxkmsuc8280.mbn
[ 11.041399] msm_dpu ae01000.display-controller: [drm:adreno_load_gpu [msm]] *ERROR* gpu hw init failed: -22
[ 11.070144] adreno 3d00000.gpu: error -22 initializing firmware qcom/sc8280xp/LENOVO/21BX/qcdxkmsuc8280.mbn
[ 11.070160] msm_dpu ae01000.display-controller: [drm:adreno_load_gpu [msm]] *ERROR* gpu hw init failed: -22
[ 11.321999] adreno 3d00000.gpu: error -22 initializing firmware qcom/sc8280xp/LENOVO/21BX/qcdxkmsuc8280.mbn
[ 11.322015] msm_dpu ae01000.display-controller: [drm:adreno_load_gpu [msm]] *ERROR* gpu hw init failed: -22
[ 11.340989] adreno 3d00000.gpu: error -22 initializing firmware qcom/sc8280xp/LENOVO/21BX/qcdxkmsuc8280.mbn
[ 11.341002] msm_dpu ae01000.display-controller: [drm:adreno_load_gpu [msm]] *ERROR* gpu hw init failed: -22
[ 11.576180] adreno 3d00000.gpu: error -22 initializing firmware qcom/sc8280xp/LENOVO/21BX/qcdxkmsuc8280.mbn
[ 11.576198] msm_dpu ae01000.display-controller: [drm:adreno_load_gpu [msm]] *ERROR* gpu hw init failed: -22
[ 11.593647] adreno 3d00000.gpu: error -22 initializing firmware qcom/sc8280xp/LENOVO/21BX/qcdxkmsuc8280.mbn
[ 11.593661] msm_dpu ae01000.display-controller: [drm:adreno_load_gpu [msm]] *ERROR* gpu hw init failed: -22
[ 11.854212] adreno 3d00000.gpu: error -22 initializing firmware qcom/sc8280xp/LENOVO/21BX/qcdxkmsuc8280.mbn
[ 11.854226] msm_dpu ae01000.display-controller: [drm:adreno_load_gpu [msm]] *ERROR* gpu hw init failed: -22
[ 11.879925] adreno 3d00000.gpu: error -22 initializing firmware qcom/sc8280xp/LENOVO/21BX/qcdxkmsuc8280.mbn
[ 11.879937] msm_dpu ae01000.display-controller: [drm:adreno_load_gpu [msm]] *ERROR* gpu hw init failed: -22
[ 12.157090] adreno 3d00000.gpu: error -22 initializing firmware qcom/sc8280xp/LENOVO/21BX/qcdxkmsuc8280.mbn
[ 12.157106] msm_dpu ae01000.display-controller: [drm:adreno_load_gpu [msm]] *ERROR* gpu hw init failed: -22
[ 12.183074] adreno 3d00000.gpu: error -22 initializing firmware qcom/sc8280xp/LENOVO/21BX/qcdxkmsuc8280.mbn
[ 12.183088] msm_dpu ae01000.display-controller: [drm:adreno_load_gpu [msm]] *ERROR* gpu hw init failed: -22
Thanks,
Andrew
>
> v1 -> v2:
> - too many changes to list, it's a complete rewrite as explained above
>
> Bartosz Golaszewski (11):
> firmware: qcom: move Qualcomm code into its own directory
> firmware: qcom: scm: add a dedicated SCM memory allocator
> firmware: qcom: scm: switch to using the SCM allocator
> firmware: qcom: scm: make qcom_scm_assign_mem() use the SCM allocator
> firmware: qcom: scm: make qcom_scm_ice_set_key() use the SCM allocator
> firmware: qcom: scm: make qcom_scm_pas_init_image() use the SCM
> allocator
> firmware: qcom: scm: make qcom_scm_lmh_dcvsh() use the SCM allocator
> firmware: qcom: scm: make qcom_scm_qseecom_app_get_id() use the SCM
> allocator
> firmware: qcom: qseecom: convert to using the SCM allocator
> firmware: qcom-scm: add support for SHM bridge operations
> firmware: qcom: scm: enable SHM bridge
>
> MAINTAINERS | 4 +-
> drivers/firmware/Kconfig | 48 +---
> drivers/firmware/Makefile | 5 +-
> drivers/firmware/qcom/Kconfig | 56 ++++
> drivers/firmware/qcom/Makefile | 9 +
> drivers/firmware/{ => qcom}/qcom_qseecom.c | 0
> .../{ => qcom}/qcom_qseecom_uefisecapp.c | 251 ++++++------------
> drivers/firmware/{ => qcom}/qcom_scm-legacy.c | 0
> drivers/firmware/qcom/qcom_scm-mem.c | 170 ++++++++++++
> drivers/firmware/{ => qcom}/qcom_scm-smc.c | 21 +-
> drivers/firmware/{ => qcom}/qcom_scm.c | 149 ++++++-----
> drivers/firmware/{ => qcom}/qcom_scm.h | 9 +
> include/linux/firmware/qcom/qcom_qseecom.h | 4 +-
> include/linux/firmware/qcom/qcom_scm.h | 13 +
> 14 files changed, 427 insertions(+), 312 deletions(-)
> create mode 100644 drivers/firmware/qcom/Kconfig
> create mode 100644 drivers/firmware/qcom/Makefile
> rename drivers/firmware/{ => qcom}/qcom_qseecom.c (100%)
> rename drivers/firmware/{ => qcom}/qcom_qseecom_uefisecapp.c (84%)
> rename drivers/firmware/{ => qcom}/qcom_scm-legacy.c (100%)
> create mode 100644 drivers/firmware/qcom/qcom_scm-mem.c
> rename drivers/firmware/{ => qcom}/qcom_scm-smc.c (92%)
> rename drivers/firmware/{ => qcom}/qcom_scm.c (94%)
> rename drivers/firmware/{ => qcom}/qcom_scm.h (95%)
>
> --
> 2.39.2
>
Powered by blists - more mailing lists