devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"Singo Chang (張興國)" <Singo.Chang@mediatek.com>,
	"Johnson Wang (王聖鑫)" <Johnson.Wang@mediatek.com>,
	"linaro-mm-sig@lists.linaro.org" <linaro-mm-sig@lists.linaro.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"Jason-ch Chen (陳建豪)" <Jason-ch.Chen@mediatek.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"Shawn Sung (宋孝謙)" <Shawn.Sung@mediatek.com>,
	"Nancy Lin (林欣螢)" <Nancy.Lin@mediatek.com>,
	"jkardatzke@google.com" <jkardatzke@google.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"conor+dt@kernel.org" <conor+dt@kernel.org>,
	Project_Global_Chrome_Upstream_Group
	<Project_Global_Chrome_Upstream_Group@mediatek.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 09/11] drm/mediatek: Add secure flow support to mediatek-drm
Date: Wed, 25 Oct 2023 08:31:20 +0000	[thread overview]
Message-ID: <96d97143f287718c596657589fa651797c6298bc.camel@mediatek.com> (raw)
In-Reply-To: <e89c5a96219f60650829e51063af7c31dec0e796.camel@mediatek.com>

Hi CK,

Thanks for the reviews.

On Tue, 2023-10-24 at 07:42 +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(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index b6fa4ad2f94d..6c2cf339b923 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -56,6 +56,11 @@ struct mtk_drm_crtc {
> >  	u32				cmdq_event;
> >  	u32				cmdq_vblank_cnt;
> >  	wait_queue_head_t		cb_blocking_queue;
> > +
> > +	struct cmdq_client		sec_cmdq_client;
> > +	struct cmdq_pkt			sec_cmdq_handle;
> > +	bool				sec_cmdq_working;
> > +	wait_queue_head_t		sec_cb_blocking_queue;
> >  #endif
> >  
> >  	struct device			*mmsys_dev;
> > @@ -67,6 +72,7 @@ struct mtk_drm_crtc {
> >  	/* lock for display hardware access */
> >  	struct mutex			hw_lock;
> >  	bool				config_updating;
> > +	bool				sec_on;
> >  };
> >  
> >  struct mtk_crtc_state {
> > @@ -109,6 +115,154 @@ static void mtk_drm_finish_page_flip(struct
> > mtk_drm_crtc *mtk_crtc)
> >  	}
> >  }
> >  
> > +void mtk_crtc_disable_secure_state(struct drm_crtc *crtc)
> > +{
> > +#if IS_REACHABLE(CONFIG_MTK_CMDQ)
> > +	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 */
> > +
> > +	mutex_lock(&mtk_crtc->hw_lock);
> > +
> > +	if (!mtk_crtc->sec_cmdq_client.chan) {
> > +		pr_err("crtc-%d secure mbox channel is NULL\n",
> > drm_crtc_index(crtc));
> > +		goto err;
> > +	}
> > +
> > +	if (!mtk_crtc->sec_on) {
> > +		pr_debug("crtc-%d is already disabled!\n",
> > drm_crtc_index(crtc));
> > +		goto err;
> > +	}
> > +
> > +	mbox_flush(mtk_crtc->sec_cmdq_client.chan, 0);
> > +	mtk_crtc->sec_cmdq_handle.cmd_buf_size = 0;
> > +
> > +	if (mtk_crtc->sec_cmdq_handle.sec_data) {
> > +		struct cmdq_sec_data *sec_data;
> > +
> > +		sec_data = mtk_crtc->sec_cmdq_handle.sec_data;
> > +		sec_data->addrMetadataCount = 0;
> > +		sec_data->addrMetadatas = (uintptr_t)NULL;
> > +	}
> > +
> > +	/*
> > +	 * Secure path only support DL mode, so we just wait
> > +	 * the first path frame done here
> > +	 */
> > +	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++) {
> > +		struct drm_plane *plane = &mtk_crtc->planes[i];
> > +
> > +		sec_port |=
> > mtk_ddp_comp_layer_get_sec_port(ddp_first_comp, i);
> > +
> > +		/* make sure secure layer off before switching secure
> > state */
> > +		if (!mtk_plane_fb_is_secure(plane->state->fb)) {
> > +			struct mtk_plane_state *plane_state =
> > to_mtk_plane_state(plane->state);
> > +
> > +			plane_state->pending.enable = false;
> > +			mtk_ddp_comp_layer_config(ddp_first_comp, i,
> > plane_state,
> > +						  &mtk_crtc-
> > > sec_cmdq_handle);
> 
> You disable layer here and disable secure path in
> cmdq_sec_pkt_set_data() later. But this is real world and could be
> hacked by hacker. If hacker do not disable layer here but disable
> secure path in cmdq_sec_pkt_set_data() later, the hardware would keep
> reading secure buffer and path is not secure? That means video could
> output to HDMI without HDCP?

Disabling secure path by cmdq_sec_pkt_set_data() will also switch the
larb used by OVL to non-secure identity. So even if the secure layer is
enabled, OVL can not access secure DRAM with non-secure larb.

And it will cause a IOMMU translation fault when non-secure larb access
the address of secure DRAM.

Regards,
Jason-JH.Lin

> 
> Regards,
> CK 
> 

  reply	other threads:[~2023-10-25  8:31 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 (林睿祥) [this message]
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 (林睿祥)
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=96d97143f287718c596657589fa651797c6298bc.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).