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.
