linux-kernel - [PATCH v3 05/17] media: venus: firmware: Leave a clue about obtaining CP VARs

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]

Date:   Wed, 17 May 2023 23:14:18 +0200
From:   Konrad Dybcio <konrad.dybcio@...aro.org>
To:     Stanimir Varbanov <stanimir.k.varbanov@...il.com>,
        Vikash Garodia <quic_vgarodia@...cinc.com>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Dikshita Agarwal <dikshita@....qualcomm.com>,
        Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        Mansur Alisha Shaik <mansur@...eaurora.org>,
        Jonathan Marek <jonathan@...ek.ca>,
        Hans Verkuil <hans.verkuil@...co.com>,
        Dikshita Agarwal <quic_dikshita@...cinc.com>
Cc:     Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
        Stanimir Varbanov <stanimir.varbanov@...aro.org>,
        linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Marijn Suijten <marijn.suijten@...ainline.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Vikash Garodia <quic_vgarodia@...cinc.com>
Subject: [PATCH v3 05/17] media: venus: firmware: Leave a clue about
 obtaining CP VARs

The qcom_scm_mem_protect_video_var accepts two sets of <addr size>
pairs as arguments. They describe the virtual address ranges of the
CP (Content Protection) and CP_NONPIXEL regions. It is however not
immediately obvious how to obtain these values.

Leave a comment explaining how one can translate the vendor device
tree properties for use with the mainline driver.

Reviewed-by: Dikshita Agarwal <quic_dikshita@...cinc.com>
Reviewed-by: Vikash Garodia <quic_vgarodia@...cinc.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@...aro.org>
---
 drivers/media/platform/qcom/venus/firmware.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/media/platform/qcom/venus/firmware.c b/drivers/media/platform/qcom/venus/firmware.c
index cfb11c551167..572b649c56f3 100644
--- a/drivers/media/platform/qcom/venus/firmware.c
+++ b/drivers/media/platform/qcom/venus/firmware.c
@@ -241,6 +241,16 @@ int venus_boot(struct venus_core *core)
 		return ret;
 
 	if (core->use_tz && res->cp_size) {
+		/*
+		 * Clues for porting using downstream data:
+		 * cp_start = 0
+		 * cp_size = venus_ns/virtual-addr-pool[0] - yes, address and not size!
+		 *   This works, as the non-secure context bank is placed
+		 *   contiguously right after the Content Protection region.
+		 *
+		 * cp_nonpixel_start = venus_sec_non_pixel/virtual-addr-pool[0]
+		 * cp_nonpixel_size = venus_sec_non_pixel/virtual-addr-pool[1]
+		 */
 		ret = qcom_scm_mem_protect_video_var(res->cp_start,
 						     res->cp_size,
 						     res->cp_nonpixel_start,

-- 
2.40.1