linux-kernel - Re: [PATCH v2 2/4] dt-bindings: mailbox: mediatek: gce-mailbox: Add reference to gce-props.yaml

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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Wed, 17 Jan 2024 02:24:32 +0000
From: Jason-JH Lin (林睿祥) <Jason-JH.Lin@...iatek.com>
To: "conor@...nel.org" <conor@...nel.org>
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>,
	Singo Chang (張興國) <Singo.Chang@...iatek.com>,
	"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"chunkuang.hu@...nel.org" <chunkuang.hu@...nel.org>,
	Jason-ch Chen (陳建豪)
	<Jason-ch.Chen@...iatek.com>, Shawn Sung (宋孝謙)
	<Shawn.Sung@...iatek.com>, Nancy Lin (林欣螢)
	<Nancy.Lin@...iatek.com>, "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>, "jassisinghbrar@...il.com"
	<jassisinghbrar@...il.com>, "angelogioacchino.delregno@...labora.com"
	<angelogioacchino.delregno@...labora.com>
Subject: Re: [PATCH v2 2/4] dt-bindings: mailbox: mediatek: gce-mailbox: Add
 reference to gce-props.yaml

On Tue, 2024-01-16 at 17:22 +0000, Conor Dooley wrote:
> On Tue, Jan 16, 2024 at 08:21:15AM +0000, Jason-JH Lin (林睿祥) wrote:
> > On Mon, 2024-01-15 at 17:23 +0000, Conor Dooley wrote:
> > > On Fri, Jan 12, 2024 at 07:44:13AM +0000, Jason-JH Lin (林睿祥)
> > > wrote:
> > > > On Thu, 2024-01-11 at 17:31 +0000, Conor Dooley wrote:
> > > > > On Wed, Jan 10, 2024 at 04:36:20PM +0000, Jason-JH Lin (林睿祥)
> > > > > > 2. We'll have the secure CMDQ mailbox driver in the future
> > > > > > patch
> > > > > > [1].
> > > > > > It will request or reserve a mailbox channel, which is a
> > > > > > dedicate
> > > > > > GCE
> > > > > > thread, as a secure IRQ handler. This GCE thread executes a
> > > > > > looping
> > > > > > instruction set that keeps waiting for the gce-event set
> > > > > > from
> > > > > > another
> > > > > > GCE thread in the secure world. So we also need to tell the
> > > > > > CMDQ
> > > > > > driver
> > > > > > what gce-event need to be waited.
> > > > > 
> > > > > Ditto here, what level does this vary at? Do different SoCs
> > > > > or
> > > > > different
> > > > > boards/platforms dictate the value?
> > > > 
> > > > It's a SoC level, the SoC supports secure feature will need
> > > > this
> > > > property.
> > > > 
> > > > > Could this channel be determined from the soc-specific
> > > > > compatible?
> > > > > 
> > > > > In other words, please explain in your commit message why
> > > > > this
> > > > > requires
> > > > > a property and is not detectable from any existing mechanism.
> > > > > From
> > > > > reading this I don't know what is preventing the secure
> > > > > mailbox
> > > > > channel
> > > > > from picking a "random" unused channel.
> > > > 
> > > > The secure channel could be dedicated from the soc-specific
> > > > compatible,
> > > > but the event ID couldn't.
> > > > 
> > > > The same event signal corresponding event ID may changes in
> > > > different
> > > > SoC.
> > > > E.g.
> > > > The HW event signal for CMDQ_EVENT_VDO0_MUTEX_STREAM_DONE_0 is
> > > > corresponding to GCE event ID: 574 in MT8188, but it's
> > > > corresponding to
> > > > eventID: 597 in MT8195.
> > > 
> > > Is it always 574 in MT8188 and always 597 in MT8195?
> > > 
> > 
> > Yes, some gce-events are hardware bound and they can not change by
> > software. For example, in MT8195, when VDO0_MUTEX is stream done,
> > VDO_MUTEX will send an event signal to GCE, and the value of event
> > ID:597 will be set to 1. In MT8188, the value of event ID: 574 will
> > be
> > set to 1 when VOD0_MUTEX is stream done.
> > 
> > Some of gce-events are not hardware bound and they can change by
> > software. For example, in MT8188, we can take the event ID: 855
> > that is
> > not bound to any hardware to set its value to 1 when the driver in
> > secure world completes a task. But in MT8195, the event ID: 855 is
> > already bound to VDEC_LAT1, so we have to take another event ID to
> > achieve the same purpose.
> > This event ID can be change to any IDs that is not bound to any
> > hardware
> > and is not used in any software driver yet.
> > We can see if the event ID is bound to the hardware or is used by
> > software driver in the header
> > include/de-bindings/mailbox/mediatek,mt8188-gce.h.
> 
> I see. Bring this particular patch back with your future series that
> adds support for the secure channel then.
> 

OK, I'll move this particular patch to the future secure series that
adds support for the secure channel. Thanks!

Regards,
Jason-JH.Lin

> Thanks,
> Conor.