Wayland content-protection extension

[Ramalingam C]

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.

Thanks
Ram
>
> Requesting content protection is a good fit to do by Wayland, because
> it is per-window. Uploading a new SRB table is not tied to any window
> or even a Wayland client, so why should it be a Wayland extension?
>
> Is maintaining the SRB table the compositor's job, or is it a separate
> service in the system that the compositor contacts?
>
> I think this digs into the system design, and there is no obvious
> benefit from using Wayland for it, that I don't think I can make a
> recommendation.
>
> For instance, if installing a new SRB table optionally uses internet
> access to e.g. verify the signing key is still valid, then I don't
> think it should be the compositor in charge of maintaining the SRB
> table.
>
>
> Thanks,
> pq