Wayland content-protection extension

[Pekka Paalanen]

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.

> > 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.

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.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180618/e24e6a36/attachment.sig>