From: "Jason-JH Lin (林睿祥)" <Jason-JH.Lin@mediatek.com>
To: "CK Hu (胡俊光)" <ck.hu@mediatek.com>,
"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
"angelogioacchino.delregno@collabora.com"
<angelogioacchino.delregno@collabora.com>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"krzysztof.kozlowski+dt@linaro.org"
<krzysztof.kozlowski+dt@linaro.org>,
"chunkuang.hu@kernel.org" <chunkuang.hu@kernel.org>
Cc: "jkardatzke@google.com" <jkardatzke@google.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"conor+dt@kernel.org" <conor+dt@kernel.org>,
Project_Global_Chrome_Upstream_Group
<Project_Global_Chrome_Upstream_Group@mediatek.com>,
"Singo Chang (張興國)" <Singo.Chang@mediatek.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linaro-mm-sig@lists.linaro.org" <linaro-mm-sig@lists.linaro.org>,
"Jason-ch Chen (陳建豪)" <Jason-ch.Chen@mediatek.com>,
"Nancy Lin (林欣螢)" <Nancy.Lin@mediatek.com>,
"Johnson Wang (王聖鑫)" <Johnson.Wang@mediatek.com>,
"Shawn Sung (宋孝謙)" <Shawn.Sung@mediatek.com>,
"linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [PATCH v2 09/11] drm/mediatek: Add secure flow support to mediatek-drm
Date: Mon, 6 Nov 2023 02:59:36 +0000 [thread overview]
Message-ID: <310f3588d65d18ead5e07c85ae656a8d94507a04.camel@mediatek.com> (raw)
In-Reply-To: <137cd99b6749e7a2e3b7fa091fd9a20d3c798c53.camel@mediatek.com>
[-- Attachment #1: Type: text/html, Size: 12355 bytes --]
[-- Attachment #2: Type: text/plain, Size: 5818 bytes --]
On Mon, 2023-11-06 at 01:27 +0000, CK Hu (胡俊光) wrote:
> On Sun, 2023-11-05 at 13:04 +0000, Jason-JH Lin (林睿祥) wrote:
> > On Tue, 2023-10-31 at 06:01 +0000, CK Hu (胡俊光) wrote:
> > > Hi, Jason:
> > >
> > > On Mon, 2023-10-23 at 12:45 +0800, Jason-JH.Lin wrote:
> > > > To add secure flow support for mediatek-drm, each crtc have to
> > > > create a secure cmdq mailbox channel. Then cmdq packets with
> > > > display HW configuration will be sent to secure cmdq mailbox
> > > > channel
> > > > and configured in the secure world.
> > > >
> > > > Each crtc have to use secure cmdq interface to configure some
> > > > secure
> > > > settings for display HW before sending cmdq packets to secure
> > > > cmdq
> > > > mailbox channel.
> > > >
> > > > If any of fb get from current drm_atomic_state is secure, then
> > > > crtc
> > > > will switch to the secure flow to configure display HW.
> > > > If all fbs are not secure in current drm_atomic_state, then
> > > > crtc
> > > > will
> > > > switch to the normal flow.
> > > >
> > > > Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
> > > > ---
> > > > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 272
> > > > ++++++++++++++++++++++-
> > > > drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 1 +
> > > > drivers/gpu/drm/mediatek/mtk_drm_plane.c | 7 +
> > > > 3 files changed, 269 insertions(+), 11 deletions(-)
> > > >
>
> [snip]
>
> > > > +
> > > > +#if IS_REACHABLE(CONFIG_MTK_CMDQ)
> > > > +static void mtk_crtc_enable_secure_state(struct drm_crtc
> > > > *crtc)
> > > > +{
> > > > + enum cmdq_sec_scenario sec_scn = CMDQ_MAX_SEC_COUNT;
> > > > + int i;
> > > > + struct mtk_ddp_comp *ddp_first_comp;
> > > > + struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> > > > + u64 sec_engine = 0; /* for hw engine write output
> > > > secure fb */
> > > > + u64 sec_port = 0; /* for larb port read input secure fb
> > > > */
> > > > +
> > > > + cmdq_pkt_wfe(&mtk_crtc->sec_cmdq_handle, mtk_crtc-
> > > > >cmdq_event,
> > > > false);
> > > > +
> > > > + ddp_first_comp = mtk_crtc->ddp_comp[0];
> > > > + for (i = 0; i < mtk_crtc->layer_nr; i++)
> > > > + if (mtk_crtc->planes[i].type ==
> > > > DRM_PLANE_TYPE_CURSOR)
> > > > + sec_port |=
> > > > mtk_ddp_comp_layer_get_sec_port(ddp_first_comp, i);
> > > > +
> > > > + if (drm_crtc_index(crtc) == 0)
> > > > + sec_scn = CMDQ_SEC_PRIMARY_DISP;
> > > > + else if (drm_crtc_index(crtc) == 1)
> > > > + sec_scn = CMDQ_SEC_SUB_DISP;
> > > > +
> > > > + cmdq_sec_pkt_set_data(&mtk_crtc->sec_cmdq_handle,
> > > > sec_engine,
> > > > sec_port, sec_scn);
> > >
> > > In cmdq driver, sec_engine means engine which need dapc. You set
> > > 0
> > > to
> > > sec_engine, does it mean that no engine is protected by dapc? If
> > > OVL
> > > is
> > > not protected by dapc, I think we could use cmdq normal thread to
> > > write
> > > OVL register instead of cmdq secure thread.
> > >
> >
> > We enable DPAC protection for the engine that is able to write data
> > to
> > the DRAM address set on their register, such as WDMA and WROT, to
> > avoid
> > their register being set to the normal DRAM address.
> >
> > We enable larb port protection for the engine that is able to read
> > data
> > from the DRAM address, such as OVL, RDMA and MDP_RDMA, to avoid
> > secure
> > DRAM being read by the non-secure larb port. So we don't need
> > toenable
> > DAPC for these engines.
> >
> > No mater DAPC protection or larb port protection, they both need to
> > use
> > sec_engine to tell TEE which engines need to be protected.
> >
> > But OVL is a special HW engine, it can only set its
> > DISP_REG_OVL_SECURE
> > register in [PATCH v2 07/11] to enable its larb port protection, so
> > OVL
> > no need to set the sec_engine. But we'll move that part to the TEE
> > secure world, so that means OVL sec_engine will be set here in the
> > next
> > version.
> >
> > > It's weird that normal world could decide which engine is
> > > protected
> > > by
> > > dapc. If hacker set 0 for output engine, then outout engine would
> > > not
> > > be protected?
> > >
> >
> > If hacker set 0 for output engine, TEE world will check that output
> > engine didn't set sec_engine from normal world by verifying
> > instruction
> > where the output engine instruction set the secure handle.
> >
> > We still need to set sec_engine to check that all the sec_engine
> > fags
> > are matched to the scenario and instruction verification in the
> > secure
> > world.
>
> So after secure scenario is set, TEE already have a sec_engine list.
> Let's call it TEE sec_engine list. And normal world has another
> sec_engine list, let's call it normal sec_engine list. Normal world
> pass normal sec_engine list to TEE by cmdq_sec_pkt_set_data() and TEE
> would check normal sec_engine list is identical to TEE sec_engine
> list
> or not. If TEE already have a TEE sec_engine list, I think it's not
> necessary that normal world have another normal sec_engine list. So
> drop this normal sec_engine list parameter.
>
The TEE sec_engine list is align to the sec_engine list in normal
world. I think the sec_engine for DAPC can be dropped and it can be
enabled/disabled by the TEE sec_engine, but the sec_engine for larb
port won't do that verification in the secure world. If sec_engine for
larb port is not set in normal world, it'll cause iova translation
fault. So we still need this sec_engine for larb port.
Regards,
Jason-JH.Lin
> Regards,
> CK
>
> >
> > Regards,
> > Jason-JH.Lin
> >
> > > Regards,
> > > CK
> > >
> > > > +
> > > > + pr_debug("crtc-%d enable secure plane!\n",
> > > > drm_crtc_index(crtc));
> > > > +}
> > > > +#endif
> > > >
next prev parent reply other threads:[~2023-11-06 2:59 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-23 4:45 [PATCH v2 00/11] Add mediate-drm secure flow for SVP Jason-JH.Lin
2023-10-23 4:45 ` [PATCH v2 01/11] drm/mediatek: Add interface to allocate MediaTek GEM buffer Jason-JH.Lin
2023-10-24 8:37 ` AngeloGioacchino Del Regno
2023-10-25 7:47 ` Jason-JH Lin (林睿祥)
2023-10-23 4:45 ` [PATCH v2 02/11] drm/mediatek/uapi: Add DRM_MTK_GEM_CREATED_ENCRYPTTED flag Jason-JH.Lin
2023-10-24 8:37 ` AngeloGioacchino Del Regno
2023-10-25 7:51 ` Jason-JH Lin (林睿祥)
2023-10-23 4:45 ` [PATCH v2 03/11] drm/mediatek: Add secure buffer control flow to mtk_drm_gem Jason-JH.Lin
2023-10-24 8:37 ` AngeloGioacchino Del Regno
2023-10-25 7:50 ` Jason-JH Lin (林睿祥)
2023-10-23 4:45 ` [PATCH v2 04/11] drm/mediatek: Add secure identify flag and funcution to mtk_drm_plane Jason-JH.Lin
2023-10-24 3:35 ` CK Hu (胡俊光)
2023-10-25 6:39 ` Jason-JH Lin (林睿祥)
2023-10-23 4:45 ` [PATCH v2 05/11] drm/mediatek: Add mtk_ddp_sec_write to config secure buffer info Jason-JH.Lin
2023-10-24 8:37 ` AngeloGioacchino Del Regno
2023-10-25 7:53 ` Jason-JH Lin (林睿祥)
2023-10-23 4:45 ` [PATCH v2 06/11] drm/mediatek: Add get_sec_port interface to mtk_ddp_comp Jason-JH.Lin
2023-10-23 4:45 ` [PATCH v2 07/11] drm/mediatek: Add secure layer config support for ovl Jason-JH.Lin
2023-10-24 8:37 ` AngeloGioacchino Del Regno
2023-10-25 7:57 ` Jason-JH Lin (林睿祥)
2023-10-25 3:08 ` CK Hu (胡俊光)
2023-10-25 8:01 ` Jason-JH Lin (林睿祥)
2023-10-26 10:07 ` CK Hu (胡俊光)
2023-11-05 13:18 ` Jason-JH Lin (林睿祥)
2023-11-06 1:33 ` CK Hu (胡俊光)
2023-11-06 2:51 ` Jason-JH Lin (林睿祥)
2023-10-23 4:45 ` [PATCH v2 08/11] drm/mediatek: Add secure layer config support for ovl_adaptor Jason-JH.Lin
2023-10-24 8:37 ` AngeloGioacchino Del Regno
2023-10-25 8:03 ` Jason-JH Lin (林睿祥)
2023-10-23 4:45 ` [PATCH v2 09/11] drm/mediatek: Add secure flow support to mediatek-drm Jason-JH.Lin
2023-10-24 7:42 ` CK Hu (胡俊光)
2023-10-25 8:31 ` Jason-JH Lin (林睿祥)
2023-10-31 6:01 ` CK Hu (胡俊光)
2023-11-05 13:04 ` Jason-JH Lin (林睿祥)
2023-11-06 1:27 ` CK Hu (胡俊光)
2023-11-06 2:59 ` Jason-JH Lin (林睿祥) [this message]
2023-11-06 3:11 ` CK Hu (胡俊光)
2023-11-06 5:48 ` Jason-JH Lin (林睿祥)
2023-10-23 4:45 ` [PATCH v2 10/11] drm/mediatek: Add cmdq_insert_backup_cookie before secure pkt finalize Jason-JH.Lin
2023-10-26 2:26 ` CK Hu (胡俊光)
2023-11-05 13:35 ` Jason-JH Lin (林睿祥)
2023-11-06 1:36 ` CK Hu (胡俊光)
2023-11-06 1:59 ` Jason-JH Lin (林睿祥)
2023-10-23 4:45 ` [PATCH v2 11/11] arm64: dts: mt8195: Add secure mbox settings for vdosys Jason-JH.Lin
2023-10-31 2:12 ` [PATCH v2 00/11] Add mediate-drm secure flow for SVP CK Hu (胡俊光)
2023-11-05 13:44 ` Jason-JH Lin (林睿祥)
2023-11-06 1:37 ` CK Hu (胡俊光)
2023-11-06 2:00 ` Jason-JH Lin (林睿祥)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=310f3588d65d18ead5e07c85ae656a8d94507a04.camel@mediatek.com \
--to=jason-jh.lin@mediatek.com \
--cc=Jason-ch.Chen@mediatek.com \
--cc=Johnson.Wang@mediatek.com \
--cc=Nancy.Lin@mediatek.com \
--cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
--cc=Shawn.Sung@mediatek.com \
--cc=Singo.Chang@mediatek.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=chunkuang.hu@kernel.org \
--cc=ck.hu@mediatek.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jkardatzke@google.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).