linux-kernel - Re: [PATCH RESEND,v6 8/8] soc: mediatek: mtk-cmdq: Add secure cmdq

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4ad87d6caf7788de5cfae82d5bdfa3ddd2040745.camel@mediatek.com>
Date: Wed, 29 May 2024 14:49:04 +0000
From: Jason-JH Lin (林睿祥) <Jason-JH.Lin@...iatek.com>
To: CK Hu (胡俊光) <ck.hu@...iatek.com>,
	"jassisinghbrar@...il.com" <jassisinghbrar@...il.com>,
	"matthias.bgg@...il.com" <matthias.bgg@...il.com>, "chunkuang.hu@...nel.org"
	<chunkuang.hu@...nel.org>, "robh+dt@...nel.org" <robh+dt@...nel.org>,
	"krzysztof.kozlowski+dt@...aro.org" <krzysztof.kozlowski+dt@...aro.org>,
	"angelogioacchino.delregno@...labora.com"
	<angelogioacchino.delregno@...labora.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>,
	Singo Chang (張興國) <Singo.Chang@...iatek.com>,
	Jason-ch Chen (陳建豪)
	<Jason-ch.Chen@...iatek.com>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, Shawn Sung (宋孝謙)
	<Shawn.Sung@...iatek.com>, Nancy Lin (林欣螢)
	<Nancy.Lin@...iatek.com>, "conor+dt@...nel.org" <conor+dt@...nel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.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>
Subject: Re: [PATCH RESEND,v6 8/8] soc: mediatek: mtk-cmdq: Add secure
 cmdq_pkt APIs

Hi CK,

On Wed, 2024-05-29 at 01:58 +0000, CK Hu (胡俊光) wrote:
> Hi, Jason:
> 
> On Tue, 2024-05-28 at 15:33 +0000, Jason-JH Lin (林睿祥) wrote:
> > Hi CK,
> > 
> > On Tue, 2024-05-28 at 03:01 +0000, CK Hu (胡俊光) wrote:
> > > Hi, Jason:
> > > 
> > > On Sun, 2024-05-26 at 22:44 +0800, Jason-JH.Lin wrote:
> > > > Open secure cmdq_pkt APIs to support executing commands in
> > > > secure
> > > > world.
> > > > 
> > > > 1. Add cmdq_sec_pkt_alloc_sec_data(),
> > > > cmdq_sec_pkt_free_sec_data()
> > > > and
> > > >    cmdq_sec_pkt_set_data() to prepare the sec_data in cmdq_pkt
> > > > that
> > > > will
> > > >    be referenced in the secure world.
> > > > 
> > > > 2. Add cmdq_sec_insert_backup_cookie() and cmdq_sec_pkt_write()
> > > > to
> > > >    generate commands that need to be executed in the secure
> > > > world.
> > > >    In cmdq_sec_pkt_write(), we need to prepare the metadata to
> > > > store
> > > >    buffer offset of the secure buffer handle because secure
> > > > world
> > > > can
> > > >    only translate the start address of secure buffer by secure
> > > > handle.
> > > > 
> > > > Signed-off-by: Jason-JH.Lin <jason-jh.lin@...iatek.com>
> > > > Signed-off-by: Hsiao Chien Sung <shawn.sung@...iatek.com>
> > > > ---
> > > 
> > > [snip]
> > > 
> > > > +
> > > > +int cmdq_sec_pkt_set_data(struct cmdq_pkt *pkt, enum
> > > > cmdq_sec_scenario scenario)
> > > > +{
> > > > +	struct cmdq_sec_data *sec_data;
> > > > +	int ret;
> > > > +
> > > > +	if (!pkt) {
> > > > +		pr_err("invalid pkt:%p", pkt);
> > > > +		return -EINVAL;
> > > > +	}
> > > > +
> > > > +	ret = cmdq_sec_pkt_alloc_sec_data(pkt);
> > > > +	if (ret < 0)
> > > > +		return ret;
> > > > +
> > > > +	pr_debug("[%s %d] pkt:%p sec_data:%p scen:%u",
> > > > +		 __func__, __LINE__, pkt, pkt->sec_data,
> > > > scenario);
> > > > +
> > > > +	sec_data = (struct cmdq_sec_data *)pkt->sec_data;
> > > > +	sec_data->scenario = scenario;
> > > > +
> > > > +	return 0;
> > > > +}
> > > 
> > > What does cmdq_sec_pkt_set_data() exactly do? It seems to
> > > enable/disable protection on hardware of certain pipeline.
> > > In future, you would use secure GCE for normal video and secure
> > > video.
> > > Would you also use secure display pipeline for both normal video
> > > and
> > > secure video?
> > 
> > I think I won't do that.
> > 
> > > If so, I think we could drop this function because the hardware
> > > is
> > > always protected.
> > > 
> > 
> > But we will use ENABLE and DISABLE scenario to notify secure world
> > to
> > enable/disable the protection of secure buffer and register by
> > setting
> > larb port and DAPC.
> > 
> > If there is secure memory output scenario (WiFi Display scenario)
> > in
> > the same display pipeline as main display scenario, we will need to
> > use
> > this scenario to differentiate them.
> 
> This API looks no relation with CMDQ. All the job is that display
> control larb, dapc to turn on/off protection.
> All the process is done by CPU not GCE, right?

We nee to make sure all the settings are finished during vblanking, so
all processes are done by GCE, we will insert the settings of larb and
dapc by referencing to the other instruction for display HW and also
the scenario here.

> If so, this API should be provided by display TA not CMDQ TA.
> 
Maybe we could parsing OVL layer control and WDMA instructions to
decide to on/off the larb and dapc settings and also the scenario in
secure world.

I would try to remove this as well, then we only need to pass the
command buffer and metadata list for buffer handle and its offset to
the secure world.

Regards,
Jason-JH.Lin

> Regards,
> CK
> 
> > 
> > Regards,
> > Jason-JH.Lin
> > 
> > > Regards,
> > > CK
> > > 
> > > > +EXPORT_SYMBOL_GPL(cmdq_sec_pkt_set_data);
> > > > +