Wayland content-protection extension

[Ramalingam C]

On Monday 02 July 2018 06:55 PM, Pekka Paalanen wrote:
> On Fri, 29 Jun 2018 21:41:33 +0530
> Ramalingam C <ramalingam.c at intel.com> wrote:
>
>> Pekka,
>>
>> Thanks a lot for the responses.
>>
>> On Friday 29 June 2018 04:28 PM, Pekka Paalanen wrote:
>>> On Mon, 18 Jun 2018 15:56:40 +0530
>>> Ramalingam C <ramalingam.c at intel.com> wrote:
>>>   
>>>> On Monday 18 June 2018 03:52 PM, Pekka Paalanen wrote:
>>>>> On Mon, 18 Jun 2018 14:32:32 +0530
>>>>> Ramalingam C <ramalingam.c at intel.com> wrote:
>>>>>      
>>>>>> On Monday 18 June 2018 02:23 PM, Pekka Paalanen wrote:
>>>>>>> On Mon, 18 Jun 2018 13:38:09 +0530
>>>>>>> Ramalingam C <ramalingam.c at intel.com> wrote:
>>>>>>>         
>>>>>>>> On Monday 18 June 2018 01:34 PM, Pekka Paalanen wrote:
>>>>>>>>> On Sat, 16 Jun 2018 12:50:52 +0530
>>>>>>>>> Ramalingam C <ramalingam.c at intel.com> wrote:
>>>>>>>>> The SRM table smells very much like compositor configuration,
>>>>>>>>> especially because a) it is global state: you cannot program two
>>>>>>>>> different tables to the same connector, and b) the compositor is
>>>>>>>>> required to save it and use it later for all clients(?). One can also
>>>>>>>>> envision a security issue, if a system allows third party apps: an app
>>>>>>>>> could install a fake SRM table with a fake date.
>>>>>>>> Compositor is expected to store the latest SRM in the non-volatile and
>>>>>>>> update with only newest versions.
>>>>>>>> And it will supply the latest version to kernel(irrespective of what
>>>>>>>> version is provided by app). This caching is not per connector.
>>>>>>>> SRM table itself provides the version of it. and The validity of an SRM
>>>>>>>> is established by verifying the integrity of its
>>>>>>>> signature with the Digital Content Protection LLC public key, which is
>>>>>>>> specified by the Digital
>>>>>>>> Content Protection LLC. So no fake SRM will be accepted.
>>>>>>> Right, so I would propose to make that completely separate.
>>>>>> Ok. So how that should be implemented? As another protocol extension?
>>>>> I don't know. Is there a reason to do it by Wayland?
>>>> Yes. As we need to supply the SRM table through drm connector properties
>>>> to each ports HDCP authentication.
>>>> At the least we need to receive the signature validated latest SRM from
>>>> client and program into drm connector property.
>>>> Means storing SRM could be kept within the wayland client but only
>>>> drm_master can set the blob for the connectors.
>>>>
>>>> And AFAIK signature verification also a crypto calculation with DCP LLC
>>>> public Key.
>>> But nothing there requires the use of Wayland for it. Sure, the
>>> compositor will have to program the SRM table via KMS, but it doesn't
>>> mean the compositor needs to get it by Wayland.
>> True. thats what I meant. I used the word "wayland" loosely. :(
>>> The compositor does not care which process provides a SRM table,
>>> because:
>>> - the SRM table is global and cross-vendor
>>> - the SRM table is signed, so no fakes can be provided
>>> - the SRM table is versioned/dated, so always the most recent will be
>>>     in use, regardless of which version a client might propose
>>> - clients are happy to use a SRM table that is more recent than what
>>>     they have themselves
>>>
>>> Did I misunderstand something?
>> You got it completely.
>>> Let me put it in another way: we don't need to standardise a Wayland
>>> interface, it could be DBus or something else since there is no
>>> connection to window management.
>>>
>>> I'm also concerned about the maintenance of an authenticated SRM table.
>>> Would we have Weston link to a new library to validate signatures? How
>>> does Weston load a guaranteed good DCP public key? Where will Weston
>>> store and load the SRM tables?
>> DCP public key is static value. Available in the HDCP specs.
>> Storing place for the SRM from weston is not thought about.
> Hi!
>
> Ok. Maybe it's fine that the compositor only keeps the SRM table at
> runtime and never saves it into persistent memory.
>
>>> I would assume the SRM table support to be both uninteresting to
>>> upstream in general, and possibly quite specific to the system where
>>> weston is running. Therefore, I would propose the following:
>>>
>>> Have the SRM table verification, maintenance, and IPC in an external
>>> Weston plugin.
>> Actually I am afraid that I am not understanding this part.
>> By this are you referring a library which provides the function pointers
>> for weston compositor for verify the signature, update the latest SRM
>> in Non volatile memory and to get the latest SRM etc?
>>
>> If not please elaborate on this.
> Weston can load arbitrary plugins as long as the plugin provides a
> single specific entry point to initialize it. The plugin will have
> access to all exported API of Weston, both for directly exported
> functions and via the so-called plugin registry where you can look up a
> function pointer table for a specific table name.
>
> It is possible to write a plugin that lives in a separate repository,
> so it does not need to be upstreamed. The downside is that the ABI for
> plugins is not stable, you will likely have to update the plugin for
> each Weston release. OTOH, this shouldn't be a problem for vendors who
> would take a specific release of weston and build a product with it.
>
> An external plugin will allow vendors to proceed without forking
> Weston. If the plugin seems upstreamable, that can be handled in due
> time. The alternative is to modify Weston itself and propose patches
> upstream. If the patches get accepted, nice. If they don't, you have a
> Weston fork.
>
> Maybe I'm overly cautious here and things would be fine in Weston, but
> I can't really tell without seeing code. You can certainly work
> directly on weston, and if it looks like that there is something we
> don't want to have in Weston upstream, then the external plugin
> approach is a way forward for vendors.
Hi,

This makes things clear. We will start working on weston.
If required we could push it to plugin.
>
>>> In upstream Weston, only add an API through the
>>> plugin-registry to set up an already validated, single SRM table for
>>> all connectors that support it. In other words:
>>>
>>> int
>>> set_srm_table(something);
>>>
>>> libweston makes an internal copy of the data and programs the same data
>>> to any connector that gets HDCP enabled, or it will fail to enable HDCP
>>> at all for the connector. Calling set_srm_table() again will
>>> unconditionally overwrite the earlier data.
>> SRM need not be available with all players. Even if he is not providing
>> we could use the latest SRM from the non-volatile memory.
>>
>> Agreed. Here set_srm_table() will make a copy and write into Kernel
>> to overwrite the SRM exist in kernel if any.
> Yes.
>
> The idea here was that set_srm_table() is a simple API we can easily
> maintain upstream. The external plugin would check the SRM table dates
> and signatures and if they pass, call set_srm_table(). The external
> plugin would also offer the client interface, whether it is Wayland,
> DBus, or something else, to the video players. I believe this is a
> design we could the very least agree to in upstream Weston, provided
> there is a way to test set_srm_table() by feeding a sample SRM table
> e.g. through a small test plugin in upstream.
>
> Oh, and if saving the latest SRM table to persistent memory is needed,
> the external plugin could do that as well.
Yes sure.

Plugin will receive the SRM table and validate the signature, and compare
with the stored SRM for latest version and provide the latest ver to
set_srm_table exported by compositor.

We should workup on the testing foption for SRM revocation.
>>> This way upstream does not need to design for a use case they have no
>>> idea about, a vendor can implement the SRM table management any way
>>> they want, and once there is an actual working implementation suitable
>>> for serious use, we can have a look at what it involves and whether it
>>> would be suitable for Weston upstream.
>>>
>>> I actually doubt whether vendors would even want the SRM table
>>> management code open sourced.
>>>
>>> For testing the API, we would probably need a dummy SRM table plugin,
>>> which just feeds in a hardcoded table or from a file, without any
>>> authentication or runtime updates, or even better, allows the user to
>>> set the list of revoked devices so one can easily test revoking ones
>>> own HDCP display.
>>>
>>> How's that?
>> Reference SRM tables are provided in HDCP spec for testing purpose.
> What do they revoke? Everything?
No. They revoke specified HDCP receiver IDs.

Thanks,
Ram
>
>
> Thanks,
> pq