| da8d493a | 20-Jan-2025 |
Johan Hovold <[email protected]> |
firmware: qcom: uefisecapp: fix efivars registration race
Since the conversion to using the TZ allocator, the efivars service is
registered before the memory pool has been allocated, something which
firmware: qcom: uefisecapp: fix efivars registration race
Since the conversion to using the TZ allocator, the efivars service is
registered before the memory pool has been allocated, something which
can lead to a NULL-pointer dereference in case of a racing EFI variable
access.
Make sure that all resources have been set up before registering the
efivars.
Fixes: 6612103ec35a ("firmware: qcom: qseecom: convert to using the TZ allocator")
Cc: [email protected] # 6.11
Cc: Bartosz Golaszewski <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Reviewed-by: Konrad Dybcio <[email protected]>
Reviewed-by: Maximilian Luz <[email protected]>
Reviewed-by: Bartosz Golaszewski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>
show more ...
|
| 1d45a1cd | 13-Dec-2024 |
Gaurav Kashyap <[email protected]> |
firmware: qcom: scm: add calls for wrapped key support
Add helper functions for the SCM calls required to support
hardware-wrapped inline storage encryption keys. These SCM calls manage
wrapped key
firmware: qcom: scm: add calls for wrapped key support
Add helper functions for the SCM calls required to support
hardware-wrapped inline storage encryption keys. These SCM calls manage
wrapped keys via Qualcomm's Hardware Key Manager (HWKM), which can only
be accessed from TrustZone.
QCOM_SCM_ES_GENERATE_ICE_KEY and QCOM_SCM_ES_IMPORT_ICE_KEY create a new
long-term wrapped key, with the former making the hardware generate the
key and the latter importing a raw key. QCOM_SCM_ES_PREPARE_ICE_KEY
converts the key to ephemerally-wrapped form so that it can be used for
inline storage encryption. These are planned to be wired up to new
ioctls via the blk-crypto framework; see the proposed documentation for
the hardware-wrapped keys feature for more information.
Similarly there's also QCOM_SCM_ES_DERIVE_SW_SECRET which derives a
"software secret" from an ephemerally-wrapped key and will be wired up
to the corresponding operation in the blk_crypto_profile.
These will all be used by the ICE driver in drivers/soc/qcom/ice.c.
[EB: merged related patches, fixed error handling, fixed naming, fixed
docs for size parameters, fixed qcom_scm_has_wrapped_key_support(),
improved comments, improved commit message.]
Signed-off-by: Gaurav Kashyap <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Eric Biggers <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>
show more ...
|
| a4332f6c | 09-Dec-2024 |
Krzysztof Kozlowski <[email protected]> |
firmware: qcom: scm: smc: Narrow 'mempool' variable scope
Only part of the __scm_smc_call() function uses 'mempool' variable, so
narrow the scope to make it more readable.
Reviewed-by: Bartosz Gola
firmware: qcom: scm: smc: Narrow 'mempool' variable scope
Only part of the __scm_smc_call() function uses 'mempool' variable, so
narrow the scope to make it more readable.
Reviewed-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/r/20241209-qcom-scm-missing-barriers-and-all-sort-of-srap-v2-6-9061013c8d92@linaro.org
Signed-off-by: Bjorn Andersson <[email protected]>
show more ...
|
| 94f48ecf | 09-Dec-2024 |
Krzysztof Kozlowski <[email protected]> |
firmware: qcom: scm: smc: Handle missing SCM device
Commit ca61d6836e6f ("firmware: qcom: scm: fix a NULL-pointer
dereference") makes it explicit that qcom_scm_get_tzmem_pool() can
return NULL, ther
firmware: qcom: scm: smc: Handle missing SCM device
Commit ca61d6836e6f ("firmware: qcom: scm: fix a NULL-pointer
dereference") makes it explicit that qcom_scm_get_tzmem_pool() can
return NULL, therefore its users should handle this.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Reviewed-by: Bartosz Golaszewski <[email protected]>
Link: https://lore.kernel.org/r/20241209-qcom-scm-missing-barriers-and-all-sort-of-srap-v2-5-9061013c8d92@linaro.org
Signed-off-by: Bjorn Andersson <[email protected]>
show more ...
|
| 1e76b546 | 09-Dec-2024 |
Krzysztof Kozlowski <[email protected]> |
firmware: qcom: scm: Cleanup global '__scm' on probe failures
If SCM driver fails the probe, it should not leave global '__scm'
variable assigned, because external users of this driver will assume t
firmware: qcom: scm: Cleanup global '__scm' on probe failures
If SCM driver fails the probe, it should not leave global '__scm'
variable assigned, because external users of this driver will assume the
probe finished successfully. For example TZMEM parts ('__scm->mempool')
are initialized later in the probe, but users of it (__scm_smc_call())
rely on the '__scm' variable.
This fixes theoretical NULL pointer exception, triggered via introducing
probe deferral in SCM driver with call trace:
qcom_tzmem_alloc+0x70/0x1ac (P)
qcom_tzmem_alloc+0x64/0x1ac (L)
qcom_scm_assign_mem+0x78/0x194
qcom_rmtfs_mem_probe+0x2d4/0x38c
platform_probe+0x68/0xc8
Fixes: 40289e35ca52 ("firmware: qcom: scm: enable the TZ mem allocator")
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/r/20241209-qcom-scm-missing-barriers-and-all-sort-of-srap-v2-4-9061013c8d92@linaro.org
Signed-off-by: Bjorn Andersson <[email protected]>
show more ...
|
| b6285103 | 09-Dec-2024 |
Krzysztof Kozlowski <[email protected]> |
firmware: qcom: scm: Fix missing read barrier in qcom_scm_get_tzmem_pool()
Commit 2e4955167ec5 ("firmware: qcom: scm: Fix __scm and waitq
completion variable initialization") introduced a write barr
firmware: qcom: scm: Fix missing read barrier in qcom_scm_get_tzmem_pool()
Commit 2e4955167ec5 ("firmware: qcom: scm: Fix __scm and waitq
completion variable initialization") introduced a write barrier in probe
function to store global '__scm' variable. We all known barriers are
paired (see memory-barriers.txt: "Note that write barriers should
normally be paired with read or address-dependency barriers"), therefore
accessing it from concurrent contexts requires read barrier. Previous
commit added such barrier in qcom_scm_is_available(), so let's use that
directly.
Lack of this read barrier can result in fetching stale '__scm' variable
value, NULL, and dereferencing it.
Note that barrier in qcom_scm_is_available() satisfies here the control
dependency.
Fixes: ca61d6836e6f ("firmware: qcom: scm: fix a NULL-pointer dereference")
Fixes: 449d0d84bcd8 ("firmware: qcom: scm: smc: switch to using the SCM allocator")
Cc: [email protected]
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/r/20241209-qcom-scm-missing-barriers-and-all-sort-of-srap-v2-2-9061013c8d92@linaro.org
Signed-off-by: Bjorn Andersson <[email protected]>
show more ...
|
| 0a744cce | 09-Dec-2024 |
Krzysztof Kozlowski <[email protected]> |
firmware: qcom: scm: Fix missing read barrier in qcom_scm_is_available()
Commit 2e4955167ec5 ("firmware: qcom: scm: Fix __scm and waitq
completion variable initialization") introduced a write barrie
firmware: qcom: scm: Fix missing read barrier in qcom_scm_is_available()
Commit 2e4955167ec5 ("firmware: qcom: scm: Fix __scm and waitq
completion variable initialization") introduced a write barrier in probe
function to store global '__scm' variable. It also claimed that it
added a read barrier, because as we all known barriers are paired (see
memory-barriers.txt: "Note that write barriers should normally be paired
with read or address-dependency barriers"), however it did not really
add it.
The offending commit used READ_ONCE() to access '__scm' global which is
not a barrier.
The barrier is needed so the store to '__scm' will be properly visible.
This is most likely not fatal in current driver design, because missing
read barrier would mean qcom_scm_is_available() callers will access old
value, NULL. Driver does not support unbinding and does not correctly
handle probe failures, thus there is no risk of stale or old pointer in
'__scm' variable.
However for code correctness, readability and to be sure that we did not
mess up something in this tricky topic of SMP barriers, add a read
barrier for accessing '__scm'. Change also comment from useless/obvious
what does barrier do, to what is expected: which other parts of the code
are involved here.
Fixes: 2e4955167ec5 ("firmware: qcom: scm: Fix __scm and waitq completion variable initialization")
Cc: [email protected]
Reviewed-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/r/20241209-qcom-scm-missing-barriers-and-all-sort-of-srap-v2-1-9061013c8d92@linaro.org
Signed-off-by: Bjorn Andersson <[email protected]>
show more ...
|
| 96ac7982 | 02-Dec-2024 |
Jens Glathe <[email protected]> |
firmware: qcom: scm: Allow QSEECOM for Windows Dev Kit 2023
add "microsoft,blackrock" as compatible device for QSEECOM
This is required to get access to efivars and uefi boot loader support.
Signe
firmware: qcom: scm: Allow QSEECOM for Windows Dev Kit 2023
add "microsoft,blackrock" as compatible device for QSEECOM
This is required to get access to efivars and uefi boot loader support.
Signed-off-by: Jens Glathe <[email protected]>
Link: https://lore.kernel.org/r/20241202-jg-blackrock-for-upstream-v9-2-385bb46ca122@oldschoolsolutions.biz
Signed-off-by: Bjorn Andersson <[email protected]>
show more ...
|
| 7d467c1b | 02-Dec-2024 |
Jens Glathe <[email protected]> |
firmware: qcom: scm: Allow QSEECOM for HP Omnibook X14
add "hp,omnibook-x14" as compatible device for QSEECOM
This is required to get access to efivars and uefi boot loader support.
Signed-off-by:
firmware: qcom: scm: Allow QSEECOM for HP Omnibook X14
add "hp,omnibook-x14" as compatible device for QSEECOM
This is required to get access to efivars and uefi boot loader support.
Signed-off-by: Jens Glathe <[email protected]>
Link: https://lore.kernel.org/r/20241202-hp-omnibook-x14-v3-2-0fcd96483723@oldschoolsolutions.biz
Signed-off-by: Bjorn Andersson <[email protected]>
show more ...
|
| 1af75b2a | 10-Nov-2024 |
Bjorn Andersson <[email protected]> |
firmware: qcom: scm: Introduce CP_SMMU_APERTURE_ID
The QCOM_SCM_SVC_MP service provides QCOM_SCM_MP_CP_SMMU_APERTURE_ID,
which is used to trigger the mapping of register banks into the SMMU
context
firmware: qcom: scm: Introduce CP_SMMU_APERTURE_ID
The QCOM_SCM_SVC_MP service provides QCOM_SCM_MP_CP_SMMU_APERTURE_ID,
which is used to trigger the mapping of register banks into the SMMU
context for per-processes page tables to function (in case this isn't
statically setup by firmware).
This is necessary on e.g. QCS6490 Rb3Gen2, in order to avoid "CP | AHB
bus error"-errors from the GPU.
Introduce a function to allow the msm driver to invoke this call.
Signed-off-by: Bjorn Andersson <[email protected]>
Reviewed-by: Rob Clark <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>
show more ...
|
| f489f6c6 | 22-Oct-2024 |
Qingqing Zhou <[email protected]> |
firmware: qcom: scm: Return -EOPNOTSUPP for unsupported SHM bridge enabling
When enabling SHM bridge, QTEE returns 0 and sets error 4 in result to
qcom_scm for unsupported platforms. Currently, tzme
firmware: qcom: scm: Return -EOPNOTSUPP for unsupported SHM bridge enabling
When enabling SHM bridge, QTEE returns 0 and sets error 4 in result to
qcom_scm for unsupported platforms. Currently, tzmem interprets this as
an unknown error rather than recognizing it as an unsupported platform.
Error log:
[ 0.177224] qcom_scm firmware:scm: error (____ptrval____): Failed to enable the TrustZone memory allocator
[ 0.177244] qcom_scm firmware:scm: probe with driver qcom_scm failed with error 4
To address this, modify the function call qcom_scm_shm_bridge_enable()
to remap result to indicate an unsupported error. This way, tzmem will
correctly identify it as an unsupported platform case instead of
reporting it as an error.
Fixes: 178e19c0df1b ("firmware: qcom: scm: add support for SHM bridge operations")
Signed-off-by: Qingqing Zhou <[email protected]>
Co-developed-by: Kuldeep Singh <[email protected]>
Signed-off-by: Kuldeep Singh <[email protected]>
Reviewed-by: Bartosz Golaszewski <[email protected]>
Reviewed-by: Mukesh Ojha <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>
show more ...
|
| db213b0c | 29-Aug-2024 |
Dan Carpenter <[email protected]> |
firmware: qcom: uefisecapp: Fix deadlock in qcuefi_acquire()
If the __qcuefi pointer is not set, then in the original code, we would
hold onto the lock. That means that if we tried to set it later,
firmware: qcom: uefisecapp: Fix deadlock in qcuefi_acquire()
If the __qcuefi pointer is not set, then in the original code, we would
hold onto the lock. That means that if we tried to set it later, then
it would cause a deadlock. Drop the lock on the error path. That's
what all the callers are expecting.
Fixes: 759e7a2b62eb ("firmware: Add support for Qualcomm UEFI Secure Application")
Signed-off-by: Dan Carpenter <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>
show more ...
|
| d4d4049e | 15-Jul-2024 |
Mukesh Ojha <[email protected]> |
firmware: qcom: scm: Add multiple download mode support
Currently, scm driver only supports full dump when download
mode is selected. Add support to enable minidump as well as
enable it along with f
firmware: qcom: scm: Add multiple download mode support
Currently, scm driver only supports full dump when download
mode is selected. Add support to enable minidump as well as
enable it along with fulldump.
Signed-off-by: Mukesh Ojha <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>
show more ...
|