Wayland content-protection extension

[Pekka Paalanen]

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.

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

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

> *       Downstream topology handling by the compositor, in case of,
> HDCP repeaters.

Why would that be an issue affecting the protocol?


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/20180615/dbe50ce1/attachment.sig>