Wayland content-protection extension

[Ramalingam C]

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

Basically when a surface protected is rendered, client will be 
continuously listen for the event update for HDCP status change from the 
compositor.
>
>>> *       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.
>

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

--Ram
>
>> Thanks,
>> pq
>

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