Wayland content-protection extension

Fri Jun 15 10:46:26 UTC 2018

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/
>>
>> As per the IRC discussion on #wayland about content protection
>> extension for Wayland (yesterday, 12th June 2018) , please find below
>> the agreed points:
> Hi Ankit,
>
> very good to summarize the discussion.
>
>> On exposing connector info to the clients:
>> *       The Client cannot request for content protection on a
>> specific connector.
>> *       Wayland does not expose connector information to the clients.
>> Client cannot put a window on a specific connector.
>> *       Compositor always decides where the surfaces are to be shown.
>> There is no way for a client to audit that the compositor is doing
>> the right thing, compositor is trusted to begin with and there's no
>> reason to inspect it.
> Yes.
>
>> On encryption of the content:
>> *       The client will provide unencrypted data to the compositor.
>> The Kernel encrypts the content just before transmitting through the
>> wire.
>> *       Once the Sink (the monitor), is authenticated to be HDCP
>> compliant, the display engine will encrypt the data and send to the
>> sink, where it will be decrypted.
> Right. This was a fundamental point to know in designing the extension.
> This would be good to explain in the introduction of the actual
> protocol extension XML to set up expectations.
>
> Because the compositor will always receive unencrypted content, the
> compositor must always be a trusted component, including all the
> libraries it uses and the hardware drivers.
>
>> Level of protection required by a client, depends on the type of
>> content sent by the client to the compositor:
>> *       The Content sent by a client app can be :
>>     Type 0 : Supported by HDCP1.4, and HDCP2.2
>>     Type 1: Supported by only HDCP2.2
>> *       Clients just request for content protection and provide the
>> content type ie Type-0 or Type-1 to the compositor.
>> *       The compositor will check through all connectors of the
>> intended surface receivers and make sure all connectors support the
>> given content type. In case if some connector/s do not support a
>> given content type, there are multiple strategy the compositor can
>> follow: o       do not show the protected content on any of the
>> connector, return "content_protection failure" to the client. o
>> show protected content on the supporting connectors, reduce image
>> quality on unprotected connectors, and return
>> "content_protection_success" to the client.
> Rather than protection failed/success, I would word the events more
> like protection on/off, because I envision that a surface can change
> the status at runtime. It would be weird to first fail, then succeed,
> then fail again.
>
> The state would change according to where and how the surface is shown
> at times.
>
> The compositor will have a great freedom in deciding on the policy on
> how to handle protected content. If someone is developing a closed
> system, they can very well build in assumptions like "the state does
> not change after mapping" into their compositor and apps. But, I would
> prefer to leave such requirements out of the protocol specification.
>
>  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.

>> *       The display driver will take the call for providing best
>> possible protection for a given content type. It will never provide
>> information to the compositor, about which content protection
>> protocol is used, i.e. compositor will only know if the connector
>> supports a particular content-type, it would never know if HDCP1.4 or
>> 2.2 is employed.
> Right, this confused me at first, but this is your DRM UAPI design.
>
>> Scope of the protocol extension:
>> *       The protocol helps client to request for content protection.
>> The client needs to provide the content type.
>> *       It provides the client with events for
>> successful/unsuccessful content protection enablement.
>> *       Helps client to disable the content protection, and provide
>> with success/ fail events.
>> *       The policy for showing the protected content with low
>> quality, or stop showing the content on unprotected connectors is out
>> of scope for the protocol. At best it can provide some guidelines/
>> specifications, but there's no way to ensure that.
>>
> Sounds good. I would formulate the protocol like this:
>
> - a global interface with a request to create a protection object;
>    has arguments wl_surface and content type
>
> - the protection object interface has events for protection on/off,
>    initially protection being off; it has a destructor, which will
>    remove the requirement for protection

Really appreciate the given direction.
Will come up with first version of the protocol xml based on this.
>> Note: Some things that are still open, but will be discussed later:
>> *       SRM table (list of backlisted Monitors/Sinks) which need to
>> be sent from the client side.
> That list could be big, right? I mean more than, say, 1 kB. If yes, you
> would want to use a shared memory buffer.
>
> Why does the client have to send it? Can it not be just compositor
> configuration?
>
> Is the use case something like a TV set-top-box with apps from
> different content providers and those each having different blacklists
> for example?
>
> After all, the whole design relies on the compositor being a trusted
> component. If the compositor is not trusted, it can simply ignore any
> blacklists.

The revocation list will be big can be maximum of 5K.

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.

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

>
> Thanks,
> pq

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