Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver

[Jeffrey Kardatzke]

On Thu, Sep 21, 2023 at 8:46 AM Nicolas Dufresne
<nicolas.dufresne@xxxxxxxxxxxxx> wrote:
>
> Le mercredi 20 septembre 2023 à 11:20 -0700, Jeffrey Kardatzke a écrit :
> > > >
> > > > Also, regarding MTK, these are stateless decoders. I think it would be nice to
> > > > show use example code that can properly parse the un-encrypted header, pass the
> > > > data to the decryptor and decode. There is a bit of mechanic in there that lacks
> > > > clarification, a reference implementation would clearly help. Finally, does this
> > > > platform offers some clearkey implementation (or other alternative) so we can do
> > > > validation and regression testing? It would be very unfortunate to add feature
> > > > upstream that can only be tested by proprietary CDM software.
> > >
> >
> > It would be possible to use this with clearkey w/ some additional work
> > on our end. If this is then part of the public ChromiumOS build, would
> > that be satisfactory? (the TEE would have some binary blob components
> > like firmware does though)
>
> From my point of view, this would fully cover my concern. To clarify this
> concern, the  decryption into secure memory currently only ever take place in
> proprietary code that implements the protection (Widewine CDM). With clear key,
> we can have an open source CDM (made for testing purpose) so that we don't have
> to have hidden code to test the entire pipeline. So appart from the TEE
> firmware, which is just a firmware like all the others, we could have open
> source tests in kernelCI and other CI, and we could extend these test to
> eventually support other vendors.
>
> Note that currently, with other proposal, one could allocate and fill a normal
> buffer, and "secure" that buffer to test the CODECs and display, but on this
> specific architecture, with the limitation on the number of secure regions, this
> feature isn't available.
>
> Alternatives to this end-to-end solution, we could consider a TA (Trusted
> Application) that simply copy data from a untrusted chunk of memory into a
> trusted chunk of memory. That seems like a cross-platform solution. It would be
> even better if this get standardized in TEEs for course (or at least required
> with all secure memory implementation). Then copying from untrusted to trusted
> could easily become an ioctl generic to all TEE drivers. That to me would be
> equally acceptable, and perhaps easier to use.
>
> Nicolas

It's very likely for the clearkey implementation that I would just
have it copying the data from a non-secure to secure buffer in a TA.
We would never do that in production of course, but for testing images
that would suffice.