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
