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

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <c7cd83c49a9226e72c272365653dc8b998b6adcb.camel@collabora.com>
Date:   Thu, 21 Sep 2023 11:46:40 -0400
From:   Nicolas Dufresne <nicolas.dufresne@...labora.com>
To:     Jeffrey Kardatzke <jkardatzke@...gle.com>,
        Hans Verkuil <hverkuil-cisco@...all.nl>
Cc:     Yunfei Dong (董云飞) 
        <Yunfei.Dong@...iatek.com>,
        "nhebert@...omium.org" <nhebert@...omium.org>,
        "benjamin.gaignard@...labora.com" <benjamin.gaignard@...labora.com>,
        "nfraprado@...labora.com" <nfraprado@...labora.com>,
        "angelogioacchino.delregno@...labora.com" 
        <angelogioacchino.delregno@...labora.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "frkoenig@...omium.org" <frkoenig@...omium.org>,
        "stevecho@...omium.org" <stevecho@...omium.org>,
        "wenst@...omium.org" <wenst@...omium.org>,
        "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "daniel@...ll.ch" <daniel@...ll.ch>,
        Project_Global_Chrome_Upstream_Group 
        <Project_Global_Chrome_Upstream_Group@...iatek.com>,
        "hsinyi@...omium.org" <hsinyi@...omium.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 12/14] media: medkatek: vcodec: set secure mode to
 decoder driver

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