[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a20254c855ba761fbc7a03b9c8dc6625549ba4b6.camel@mediatek.com>
Date: Thu, 28 Sep 2023 09:12:08 +0000
From: Jason-JH Lin (林睿祥)
<Jason-JH.Lin@...iatek.com>
To: CK Hu (胡俊光) <ck.hu@...iatek.com>,
"jkardatzke@...gle.com" <jkardatzke@...gle.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mediatek@...ts.infradead.org"
<linux-mediatek@...ts.infradead.org>,
"robh+dt@...nel.org" <robh+dt@...nel.org>,
Johnson Wang (王聖鑫)
<Johnson.Wang@...iatek.com>,
"linaro-mm-sig@...ts.linaro.org" <linaro-mm-sig@...ts.linaro.org>,
"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
"chunkuang.hu@...nel.org" <chunkuang.hu@...nel.org>,
Singo Chang (張興國)
<Singo.Chang@...iatek.com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
Shawn Sung (宋孝謙)
<Shawn.Sung@...iatek.com>,
Nancy Lin (林欣螢) <Nancy.Lin@...iatek.com>,
Jason-ch Chen (陳建豪)
<Jason-ch.Chen@...iatek.com>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"conor+dt@...nel.org" <conor+dt@...nel.org>,
Project_Global_Chrome_Upstream_Group
<Project_Global_Chrome_Upstream_Group@...iatek.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"krzysztof.kozlowski+dt@...aro.org"
<krzysztof.kozlowski+dt@...aro.org>,
"matthias.bgg@...il.com" <matthias.bgg@...il.com>,
"angelogioacchino.delregno@...labora.com"
<angelogioacchino.delregno@...labora.com>
Subject: Re: [PATCH 00/10] Add mediate-drm secure flow for SVP
Hi CK,
Thanks for the reviews.
[snip]
> >
> > We'll use cmdq_sec_pkt_set_data() to bring the secure scenario,
> > secure
> > engine flags and some secure metadata to TEE world. Then will used
> > these information to make sure the pipeline is secure.
> >
> > We don't have the secure output feature currently, such as WiFi
> > display, so we'll do it after we have to support the feature.
> >
> > Also there are HDMITX_HDCP and DPTX_HDCP TA will check the HDCP
> > statue
> > in secure world and then CMDQ TA will get that status by calling
> > their
> > API in TEE.
> > If CMDQ TA get a HDCP checking failed sstatus, it will insert some
> > instructions in the secure cmd buffer to mute the DISP HW for each
> > frames.
>
> You enable secure path by crtc pipeline. That means it may be primary
> display is secure and secondary display is non-secure. In
> drivers/soc/mediatek/mt8195-mmsys.h, the primary display input could
> be
> routed to secondary display output. Is mmsys protected when display
> is
> secure? The whole mmsys is protected or partial mmsys is protected?
VDOSYS0 has 2 pipelines and considering the scenario of using VDOSYS0-0
as secure and VDOSYS0-0 as normal, we can not protect mmsys path mux
register.
> If
> the whole mmsys is protected, the non-secure display pipeline would
> be
> malfunctioned because the control of non-secure display is in normal
> world and it may access mmsys. Please describe how this work?
For this case, we'll use CMDQ PTA to block the invalid instructions and
re-configure current mmsys path mux registers in every vblank interval
by GCE.
But we still have some works to do.
The main idea would be moving mmsys configure operation to the ATF.
Then protected the whole mmsys registers by DAPC.
So normal world can't write mmsys registers without passing smc call
cmd to ATF. ATF would check mux configure cmd is valid to current
scenario, then configures the valid mmsys mux registers.
Regards,
Jason-JH.Lin
>
> Regards,
> CK
Powered by blists - more mailing lists