Wayland content-protection extension

[Arnaud Vrac]

On Fri, Jun 15, 2018 at 10:08 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
> On Thu, 14 Jun 2018 13:09:24 +0200
> Arnaud Vrac <rawoul at gmail.com> wrote:
>
> > 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.
>
> Hi,
>
> generally there cannot be in-advance information. Until a window is
> actually mapped, the compositor will not know where it will show up as
> the scenegraph may change due to the client, other clients, or hotplug,
> etc.
>
> It would be a narrow special case compositor that would know
> before-hand what the protection for a surface would be.
>
> I have assumed that applications are able to switch the content quality
> at runtime to match changes in the protection status. If this is not
> the case, the issue needs to be brought up now.
>
> OTOH, an application can always map the window with non-sensitive
> content to see what it will get. I don't think that would be a problem
> if the system design otherwise guarantees that the protection status
> does not change while the window is mapped. However, I don't think we
> should make the demand of status not changing in the protocol extension.

Hi Pekka,

A content provider can provide many stream versions for the same
content, based on the codec, profile, level supported by the video
decoders of the platform, the capabilities of the display hardware
(max resolution, hdcp level support, hdr modes), and the capabilities
of the connected outputs. There's no point in serving 4k content if
the display or decoders do not support it, or if the display block or
connected sink does not support the required protection level.

So I believe wl_output (or an extension of it via a separate protocol)
should expose its supported protection levels (which would be the
intersection of the display block and the connected sink
capabilities). This does require negotiating with the connected output
for its protection capabilities beforehand.

> > 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.
>
> I'm not sure knowing the chance is possible given how the DRM UAPI for
> it has been designed: you will know only after attempting to enable a
> specific content type whether you got what you asked for. If you ask
> for Type 1 and receive "no", that won't tell you anything about whether
> Type 0 would succeed, so the compositor has to try again. I'm told that
> HDCP negotiation can take a noticeable amount of time, so I assume
> compositors would not want to attempt it speculatively.
>
> At least I am assuming that a compositor would not want to enable HDCP
> unless it is actually wanted. If a compositor is enabling maximum
> protection at all times, then it would know the chances.

You're right, enabling HDCP can take time and even cause screen
flickering. To avoid this it is preferable to negotiate the highest
level supported to avoid switching at runtime. This is not required
though to query the sink HDCP capabilities, so exposing the wl_output
HDCP capabilities is still possible without enabling encryption.

>
> Then again, I suppose if a compositor knows what the protection status
> will be, it can send events for it even before mapping the window. I
> just don't want to require it, and I would not want to imply that apps
> can rely on it.

Unfortunately all the major content providers already require this for
their "official" app to work correctly and expose the proper video
streams (and their PlayReady/Widevine/foo DRM license, which contains
the stream output protection level requirement). I don't see how they
could handle this use-case efficiently without this information.

>
> All this really becomes a question of scope for the protocol extension,
> how narrow or wide the use cases will be. If we narrow down the
> intended use cases, we could have more restrictions written down in the
> specification.

I agree, and I think the proposition from Ankit is already very good
as-is, interfacing with wl_surface to enforce the output protection at
the compositior level. What I'm proposing here is to also extend
wl_output with the actual sink capabilities for output protection, so
it could either be included in the same protocol or another one (which
could at least share some enums for protection levels, etc).

>
> I have a funny thought that normal desktop applications that show
> sensitive information like password lists might be able to use this
> extension to protect the window content from being leaked to
> screenshots or such. Of course, such use cases would need consideration
> right now to set the expectations in the protocol introduction
> correctly. That use case might well be better served by an extension
> explicitly designed for it.

Thanks,
-Arnaud