Wayland content-protection extension

[Arnaud Vrac]

On Wed, Jun 13, 2018 at 12:34 PM, 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,

Thanks for working on this, overall I agree with your design, which
provides a first level of security when more advanced output
protection enforcement is not available. I missed the discussion on
IRC so I'm sorry if my comments are reduntant.

I see one problem with this approach of hiding the output state to the
client: there is no way to choose the content in advance based on the
output protection capabilities. Most content providers have the same
content available in multiple qualities, and the better qualities will
be available based on the device and output capabilities.

Since the client has no way of knowing on which output the video
surface will be shown, the maximum protection level supported by all
outputs should be exposed to the client, and the client can then
determine if it's worth switching to a higher quality, and if there's
a chance it will be displayed on at least one output.

Regards,
-Arnaud

> 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.
>
>
> 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.
>
>
> 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:
>
> do not show the protected content on any of the connector, return
> "content_protection failure" to the client.
> show protected content on the supporting connectors, reduce image quality on
> unprotected connectors, and return "content_protection_success" to the
> client.
>
> 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.
>
>
> 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.
>
>
> 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.
> Downstream topology handling by the compositor, in case of, HDCP repeaters.
>
>
>
> Thanks & Regards,
> Ankit
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



--
Arnaud