Wayland content-protection extension

[Ramalingam C]

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:
>
>> On Friday 15 June 2018 04:16 PM, Nautiyal, Ankit K wrote:
>>> Hi Pekka,
>>>
>>> Thanks for the suggestions. Please find my responses inline:
>>>
>>> On 6/15/2018 1:16 PM, Pekka Paalanen wrote:
>>>> On Wed, 13 Jun 2018 10:34:45 +0000
>>>> "Nautiyal, Ankit K"<ankit.k.nautiyal at intel.com>  wrote:
>>>>   
>>>>> Hi All,
>>>>>
>>>>> I am working on wayland content-protection protocol extension, to
>>>>> enable content-protection (HDCP1.4, HDCP2.2) in wayland. DRM layer
>>>>> already has support for HDCP1.4 and patches for HDCP2.2 are in
>>>>> review :https://patchwork.freedesktop.org/series/39596/
>>>>>
>>>>   From what I heard, the hardware will continuously or periodically
>>>> confirm the protection status of the display data stream on the wire,
>>>> and it is possible that the hardware status will change at runtime. The
>>>> very least hotplug is a thing.
>>> Yes agreed. The app will have a listener to content protection status.
>>> It makes sense to have the even named as on/off.
>> Yes. HDCP Link status can change in run time for any connector.
>> So Compositor is expected to check the current HDCP status of all
>> connectors on those protected surface is rendered.
>> And inform the client with runtime cumulative HDCP protection for that
>> protected surface.
> How does the kernel signal to userspace that the HDCP status has
> changed? Do you piggyback on the hotplug event?
>
> Anything that would require userspace to repeatedly re-read properties
> without any events triggering it is bad design. If nothing is
> happening, the compositor needs to be able to stay asleep.
Pekka,

We proposed a uevent from kernel for indicating the HDCP status change.
But that didn't fly. Right now the merged interface expects compositor 
to poll
the property state for the runtime failures.
>
>>> As I understand the SRM messages will be delivered with content, to
>>> the kernel.
>>> There is a separate Connector proprty of type blob for this.
>>> SRM can be transmitted with a cable TV signal. It might be keep on
>>> getting updated as more devices, keep on adding to the table.
>>>   
>> SRM table will be updated by DCP LLC as and when device is revocated.
>> And updated SRM table will be shared to all protected content providers.
>> So the protected content player needs to supply the SRM to the kernel
>> for the revocation step in authentication, through compositor.
>>
>> Compositor has to store the latest version in non-volatile memory and
>> expected to provide this information as a
>> blob to all the connector for the authentication at the kernel. Storing
>> in non-volatile is required to fulfill the HDCP spec.
> That sounds like the SRM table should not be part of a Wayland extension.
>
> Let's say you have two apps: A and B. Vendor of A is shipping an
> updated SRM table. Vendor of B is not shipping it yet, so it has an
> outdated SRM table.
>
> A user launches app A, then app B, to watch both. A trivial protocol
> implementation will have app B overwrite the SRM table with an outdated
> version.

>
> 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.
>
> So I would recommend keeping the SRM table updates out of this protocol
> extension and work on that separately.
>
> Also, do you have a way or requirement to authenticate the SRM table?
> Is it signed? How do you install the verification key?
>
>
>>>   
>>>>> *       Downstream topology handling by the compositor, in case of,
>>>>> HDCP repeaters.
>>>> Why would that be an issue affecting the protocol?
>>> The topology information needs to be sent to client, in case of repeater.
>>> I thin Ram can shed more light on it.
>> This interface is required to implement the repeater using the intel
>> platforms.
>> In such scenario, each connectors will be considered as one HDCP
>> downstream ports.
>> Compositor and kernel will be used for the HDCP authentication of the
>> downstream devices.
>> And a userspace module can implement upstream port's HDCP authentication
>> through wireless/wired channel.
>>
>> So this interface will be used for collecting the downstream devices in
>> each ports and provide them
>> to the upstream hdcp device for the repeater authentication step.
>>
>> I will try to compose complete flow in a mail. That will help us to be
>> in sync about the design we need and feasible.
> Good, because I really didn't quite understand who does what now in
> there.
I have already composed this and shared on the list, please share your 
suggestion on it. Thanks you.

Thanks,
Ram
>
>
> Thanks,
> pq
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180618/59399366/attachment-0001.html>