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: <CA+ddPcPm4aZ9LKu1D1rO3qguPN7E7jbnXTOqdjYCtDm7sk4nzw@mail.gmail.com>
Date:   Thu, 21 Sep 2023 10:58:38 -0700
From:   Jeffrey Kardatzke <jkardatzke@...gle.com>
To:     Nicolas Dufresne <nicolas.dufresne@...labora.com>
Cc:     Hans Verkuil <hverkuil-cisco@...all.nl>,
        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

On Thu, Sep 21, 2023 at 8:46 AM Nicolas Dufresne
<nicolas.dufresne@...labora.com> 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.