<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">On Monday 18 June 2018 01:34 PM, Pekka Paalanen wrote: </div> <blockquote type="cite" cite="mid:20180618110442.661d4733@eldfell"> <pre wrap="">On Sat, 16 Jun 2018 12:50:52 +0530 Ramalingam C <a class="moz-txt-link-rfc2396E" href="mailto:ramalingam.c@intel.com"><ramalingam.c@intel.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">On Friday 15 June 2018 04:16 PM, Nautiyal, Ankit K wrote: </pre> <blockquote type="cite"> <pre wrap=""> Hi Pekka, Thanks for the suggestions. Please find my responses inline: On 6/15/2018 1:16 PM, Pekka Paalanen wrote: </pre> <blockquote type="cite"> <pre wrap="">On Wed, 13 Jun 2018 10:34:45 +0000 "Nautiyal, Ankit K"<a class="moz-txt-link-rfc2396E" href="mailto:ankit.k.nautiyal@intel.com"><ankit.k.nautiyal@intel.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">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 :<a class="moz-txt-link-freetext" href="https://patchwork.freedesktop.org/series/39596/">https://patchwork.freedesktop.org/series/39596/</a> </pre> </blockquote> </blockquote> </blockquote> </blockquote> <pre wrap=""> </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap=""> 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. </pre> </blockquote> <pre wrap=""> Yes agreed. The app will have a listener to content protection status. It makes sense to have the even named as on/off. </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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.</pre> </blockquote> 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. <blockquote type="cite" cite="mid:20180618110442.661d4733@eldfell"> <pre wrap=""> </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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. </pre> </blockquote> <pre wrap=""> 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.</pre> </blockquote> <blockquote type="cite" cite="mid:20180618110442.661d4733@eldfell"> <pre wrap=""> 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.</pre> </blockquote> 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. <blockquote type="cite" cite="mid:20180618110442.661d4733@eldfell"> <pre wrap=""> 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? </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">* Downstream topology handling by the compositor, in case of, HDCP repeaters. </pre> </blockquote> <pre wrap="">Why would that be an issue affecting the protocol? </pre> </blockquote> <pre wrap=""> The topology information needs to be sent to client, in case of repeater. I thin Ram can shed more light on it. </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> Good, because I really didn't quite understand who does what now in there.</pre> </blockquote> I have already composed this and shared on the list, please share your suggestion on it. Thanks you. Thanks, Ram <blockquote type="cite" cite="mid:20180618110442.661d4733@eldfell"> <pre wrap=""> Thanks, pq </pre>  <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">_______________________________________________ wayland-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> </pre> </blockquote> </body> </html>