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 05:48:49 +0000 [thread overview]
Message-ID: <74154b6504ec8f730eecbeb9938be97b8a0565ec.camel@mediatek.com> (raw)
In-Reply-To: <a2ddf5604052e88b9b2790f23ef89d5e16fdb172.camel@mediatek.com>
[-- Attachment #1: Type: text/html, Size: 17966 bytes --]
[-- Attachment #2: Type: text/plain, Size: 7698 bytes --]
On Mon, 2023-11-06 at 03:11 +0000, CK Hu (胡俊光) wrote:
> On Mon, 2023-11-06 at 02:59 +0000, Jason-JH Lin (林睿祥) wrote:
> > 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.
>
> In TEE, there is already a TEE sec_engine list, so checking larb port
> could use TEE sec_engine list because TEE sec_engine list would be
> identical to normal sec_engine list. Why not use TEE sec_engine list
> to
> check larb port? What is the detail of checking larb port? Describe
> it
> if necessary.
>
After checking the CMDQ PTA larb port enable/disable flow, I think it's
possible to implement the same verification like DAPC for larb port.
So I'll drop the sec_engine flags in normal world to simplify and de-
risk for the secure configuration parameters.
This also need to add a TODO on commit message:
verify instruction for enabling/disabling larb port in secure world and
drop the sec_engine flags in normal world.
Regards,
Jason-JH.Lin
> Regards,
> CK
>
> >
> > 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 5:49 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 (林睿祥)
2023-11-06 3:11 ` CK Hu (胡俊光)
2023-11-06 5:48 ` Jason-JH Lin (林睿祥) [this message]
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=74154b6504ec8f730eecbeb9938be97b8a0565ec.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).