[RFC,wayland-protocols] Add secure output protocol

Submitted by Scott Anderson on Nov. 29, 2018, 4:06 a.m.

Details

Message ID 20181129040650.3761-1-scott.anderson@collabora.com
State Superseded
Series "Add secure output protocol"
Headers show

Commit Message

Scott Anderson Nov. 29, 2018, 4:06 a.m.
From: Scott Anderson <scott.anderson@collabora.com>

This protocol allows a client to ask the compositor to only allow it to
be displayed on a "secure" output (e.g. HDCP).

This is based on a chromium protocol of the same name [1].

This protocol is mostly useful for closed systems, where the client can
trust the compositor, such as set-top boxes. This is not a way to
implement any kind of Digital Rights Management on desktops. The
protocol deliberately doesn't define what a "secure output" is, and the
compositor would be free to lie to the client anyway.

Signed-off-by: Scott Anderson <scott.anderson@collabora.com>

[1] https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/secure-output/secure-output-unstable-v1.xml
---

There is a proof-of-concept implementation of this protocol for weston
here: https://gitlab.freedesktop.org/ascent/weston/tree/secure-output

Changes since v1:
 - Fix formatting
 - Add 'secure_resolution' event

As Simon brought up, this may not be the type of patch that is
necessarily wanted upstream, and it's completely understandable if it's
not. There are probably multiple parties that are interested in such a
thing, but I suppose the answer depends on what wayland-protocols is
designed to accommodate.

I'm just proposing the 'secure_resolution' event, because I believe it
can allow for the client to adjust to changing security conditions
without being tied to any specific underlying technology (e.g. HDCP).
It's still largely up to compositor policy how this could be used, but
we'll have to see if this can meet everybody's requirements.

 Makefile.am                                   |   1 +
 unstable/secure-output/README                 |   4 +
 .../secure-output-unstable-v1.xml             | 144 ++++++++++++++++++
 3 files changed, 149 insertions(+)
 create mode 100644 unstable/secure-output/README
 create mode 100644 unstable/secure-output/secure-output-unstable-v1.xml

Patch hide | download patch | download mbox

diff --git a/Makefile.am b/Makefile.am
index 345ae6a..4d94747 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -23,6 +23,7 @@  unstable_protocols =								\
 	unstable/xdg-decoration/xdg-decoration-unstable-v1.xml	\
 	unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml \
 	unstable/primary-selection/primary-selection-unstable-v1.xml		\
+	unstable/secure-output/secure-output-unstable-v1.xml		\
 	$(NULL)
 
 stable_protocols =								\
diff --git a/unstable/secure-output/README b/unstable/secure-output/README
new file mode 100644
index 0000000..3251af9
--- /dev/null
+++ b/unstable/secure-output/README
@@ -0,0 +1,4 @@ 
+Secure output protocol
+
+Maintainers:
+David Reveman <reveman@chromium.org>
diff --git a/unstable/secure-output/secure-output-unstable-v1.xml b/unstable/secure-output/secure-output-unstable-v1.xml
new file mode 100644
index 0000000..51b2c13
--- /dev/null
+++ b/unstable/secure-output/secure-output-unstable-v1.xml
@@ -0,0 +1,144 @@ 
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="secure_output_unstable_v1">
+
+  <copyright>
+    Copyright 2016 The Chromium Authors.
+    Copyright 2018 Collabora, Ltd.
+
+    Permission is hereby granted, free of charge, to any person obtaining a
+    copy of this software and associated documentation files (the "Software"),
+    to deal in the Software without restriction, including without limitation
+    the rights to use, copy, modify, merge, publish, distribute, sublicense,
+    and/or sell copies of the Software, and to permit persons to whom the
+    Software is furnished to do so, subject to the following conditions:
+
+    The above copyright notice and this permission notice (including the next
+    paragraph) shall be included in all copies or substantial portions of the
+    Software.
+
+    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+    DEALINGS IN THE SOFTWARE.
+  </copyright>
+
+  <description summary="Protocol for providing secure output">
+    This protocol specifies a set of interfaces used to prevent surface
+    contents from appearing in screenshots or from being visible on non-secure
+    outputs.
+
+    In order to prevent surface contents from appearing in screenshots or from
+    being visible on non-secure outputs, a client must first bind the global
+    interface "wp_secure_output" which, if a compositor supports secure output,
+    is exposed by the registry. Using the bound global object, the client uses
+    the "get_security" request to instantiate an interface extension for a
+    wl_surface object. This extended interface will then allow surfaces
+    to be marked as only visible on secure outputs.
+
+    Warning! The protocol described in this file is experimental and backward
+    incompatible changes may be made. Backward compatible changes may be added
+    together with the corresponding interface version bump. Backward
+    incompatible changes are done by bumping the version number in the protocol
+    and interface names and resetting the interface version. Once the protocol
+    is to be declared stable, the 'z' prefix and the version number in the
+    protocol and interface names are removed and the interface version number is
+    reset.
+  </description>
+
+  <interface name="zwp_secure_output_v1" version="1">
+    <description summary="secure output">
+      The global interface exposing secure output capabilities is used
+      to instantiate an interface extension for a wl_surface object.
+      This extended interface will then allow surfaces to be marked as
+      as only visible on secure outputs.
+    </description>
+
+    <request name="destroy" type="destructor">
+      <description summary="unbind from the secure output interface">
+        Informs the server that the client will not be using this
+        protocol object anymore. This does not affect any other objects,
+        security objects included.
+      </description>
+    </request>
+
+    <enum name="error">
+      <entry name="security_exists" value="0"
+             summary="the surface already has a security object associated"/>
+    </enum>
+
+    <request name="get_security">
+      <description summary="extend surface interface for security">
+        Instantiate an interface extension for the given wl_surface to
+        provide surface security. If the given wl_surface already has
+        a security object associated, the security_exists protocol error
+        is raised.
+      </description>
+
+      <arg name="id" type="new_id" interface="zwp_security_v1"
+           summary="the new security interface id"/>
+      <arg name="surface" type="object" interface="wl_surface"
+           summary="the surface"/>
+    </request>
+  </interface>
+
+  <interface name="zwp_security_v1" version="1">
+    <description summary="security interface to a wl_surface">
+      An additional interface to a wl_surface object, which allows the
+      client to specify that a surface should not appear in screenshots
+      or be visible on non-secure outputs.
+
+      If the wl_surface associated with the security object is destroyed,
+      the security object becomes inert.
+
+      If the security object is destroyed, the security state is removed
+      from the wl_surface. The change will be applied on the next
+      wl_surface.commit.
+    </description>
+
+    <request name="destroy" type="destructor">
+      <description summary="remove security from the surface">
+        The associated wl_surface's security state is removed.
+        The change is applied on the next wl_surface.commit.
+      </description>
+    </request>
+
+    <request name="only_visible_on_secure_output">
+      <description summary="set the only visible on secure output state">
+        Constrain visibility of wl_surface contents to secure outputs.
+        See wp_secure_output for the description.
+
+        The only visible on secure output state is double-buffered state,
+        and will be applied on the next wl_surface.commit.
+      </description>
+    </request>
+
+    <event name="secure_resolution">
+      <description summary="largest resolution that can be output securely"/>
+        This event tells the client the largest resolution at which the
+        client's content can be show securely. If the client uses attaches
+        a buffer to the surface this wp_security object was created with
+        that is a larger size than this resolution, the behaviour is
+        compositor-defined. As an example, the compositor may choose to
+        downscale the content or simply refuse to display it, but is not
+        limited to these behaviours.
+
+        The server may send this event multiple times over the lifetime of this
+        object, as the status of security changes.
+
+        If the server sends this event with both width and height as zero,
+        then no content can currently be output securely. The server must not
+        send any event where only one of width or height are zero.
+
+        Before the server has sent the first of these events, the client
+        should assume that no content can be output securely, i.e. width
+        and height are both zero.
+      </description>
+      <arg name="width" type="int" summary="largest secure width"/>
+      <arg name="height" type="int" summary="largest secure height"/>
+    </event>
+  </interface>
+
+</protocol>

Comments

Nautiyal, Ankit K Nov. 29, 2018, 9:39 a.m.
Hi Scott,

As this was under discussion in last patchset, summarizing it here again:

HDCP2.2 spec leaves the content-type classification to the 
content-provider (client).

The same had been discussed earlier in #wayland, and the mailing list:

https://lists.freedesktop.org/archives/wayland-devel/2018-June/038446.html
https://lists.freedesktop.org/archives/wayland-devel/2018-June/038511.html

The compositor in that case have to just pass on, the type of content to 
the kernel, which will take care of which protocol to use, based on 
content-type.
Compositor, keeping track of the resolution and content-type is 
undesirable in my opinion.

Regards,
Ankit

On 11/29/2018 9:36 AM, scott.anderson@collabora.com wrote:
> From: Scott Anderson <scott.anderson@collabora.com>
>
> This protocol allows a client to ask the compositor to only allow it to
> be displayed on a "secure" output (e.g. HDCP).
>
> This is based on a chromium protocol of the same name [1].
>
> This protocol is mostly useful for closed systems, where the client can
> trust the compositor, such as set-top boxes. This is not a way to
> implement any kind of Digital Rights Management on desktops. The
> protocol deliberately doesn't define what a "secure output" is, and the
> compositor would be free to lie to the client anyway.
>
> Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
>
> [1] https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/secure-output/secure-output-unstable-v1.xml
> ---
>
> There is a proof-of-concept implementation of this protocol for weston
> here: https://gitlab.freedesktop.org/ascent/weston/tree/secure-output
>
> Changes since v1:
>   - Fix formatting
>   - Add 'secure_resolution' event
>
> As Simon brought up, this may not be the type of patch that is
> necessarily wanted upstream, and it's completely understandable if it's
> not. There are probably multiple parties that are interested in such a
> thing, but I suppose the answer depends on what wayland-protocols is
> designed to accommodate.
>
> I'm just proposing the 'secure_resolution' event, because I believe it
> can allow for the client to adjust to changing security conditions
> without being tied to any specific underlying technology (e.g. HDCP).
> It's still largely up to compositor policy how this could be used, but
> we'll have to see if this can meet everybody's requirements.
>
>   Makefile.am                                   |   1 +
>   unstable/secure-output/README                 |   4 +
>   .../secure-output-unstable-v1.xml             | 144 ++++++++++++++++++
>   3 files changed, 149 insertions(+)
>   create mode 100644 unstable/secure-output/README
>   create mode 100644 unstable/secure-output/secure-output-unstable-v1.xml
>
> diff --git a/Makefile.am b/Makefile.am
> index 345ae6a..4d94747 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -23,6 +23,7 @@ unstable_protocols =								\
>   	unstable/xdg-decoration/xdg-decoration-unstable-v1.xml	\
>   	unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml \
>   	unstable/primary-selection/primary-selection-unstable-v1.xml		\
> +	unstable/secure-output/secure-output-unstable-v1.xml		\
>   	$(NULL)
>   
>   stable_protocols =								\
> diff --git a/unstable/secure-output/README b/unstable/secure-output/README
> new file mode 100644
> index 0000000..3251af9
> --- /dev/null
> +++ b/unstable/secure-output/README
> @@ -0,0 +1,4 @@
> +Secure output protocol
> +
> +Maintainers:
> +David Reveman <reveman@chromium.org>
> diff --git a/unstable/secure-output/secure-output-unstable-v1.xml b/unstable/secure-output/secure-output-unstable-v1.xml
> new file mode 100644
> index 0000000..51b2c13
> --- /dev/null
> +++ b/unstable/secure-output/secure-output-unstable-v1.xml
> @@ -0,0 +1,144 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +<protocol name="secure_output_unstable_v1">
> +
> +  <copyright>
> +    Copyright 2016 The Chromium Authors.
> +    Copyright 2018 Collabora, Ltd.
> +
> +    Permission is hereby granted, free of charge, to any person obtaining a
> +    copy of this software and associated documentation files (the "Software"),
> +    to deal in the Software without restriction, including without limitation
> +    the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +    and/or sell copies of the Software, and to permit persons to whom the
> +    Software is furnished to do so, subject to the following conditions:
> +
> +    The above copyright notice and this permission notice (including the next
> +    paragraph) shall be included in all copies or substantial portions of the
> +    Software.
> +
> +    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> +    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> +    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> +    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +    DEALINGS IN THE SOFTWARE.
> +  </copyright>
> +
> +  <description summary="Protocol for providing secure output">
> +    This protocol specifies a set of interfaces used to prevent surface
> +    contents from appearing in screenshots or from being visible on non-secure
> +    outputs.
> +
> +    In order to prevent surface contents from appearing in screenshots or from
> +    being visible on non-secure outputs, a client must first bind the global
> +    interface "wp_secure_output" which, if a compositor supports secure output,
> +    is exposed by the registry. Using the bound global object, the client uses
> +    the "get_security" request to instantiate an interface extension for a
> +    wl_surface object. This extended interface will then allow surfaces
> +    to be marked as only visible on secure outputs.
> +
> +    Warning! The protocol described in this file is experimental and backward
> +    incompatible changes may be made. Backward compatible changes may be added
> +    together with the corresponding interface version bump. Backward
> +    incompatible changes are done by bumping the version number in the protocol
> +    and interface names and resetting the interface version. Once the protocol
> +    is to be declared stable, the 'z' prefix and the version number in the
> +    protocol and interface names are removed and the interface version number is
> +    reset.
> +  </description>
> +
> +  <interface name="zwp_secure_output_v1" version="1">
> +    <description summary="secure output">
> +      The global interface exposing secure output capabilities is used
> +      to instantiate an interface extension for a wl_surface object.
> +      This extended interface will then allow surfaces to be marked as
> +      as only visible on secure outputs.
> +    </description>
> +
> +    <request name="destroy" type="destructor">
> +      <description summary="unbind from the secure output interface">
> +        Informs the server that the client will not be using this
> +        protocol object anymore. This does not affect any other objects,
> +        security objects included.
> +      </description>
> +    </request>
> +
> +    <enum name="error">
> +      <entry name="security_exists" value="0"
> +             summary="the surface already has a security object associated"/>
> +    </enum>
> +
> +    <request name="get_security">
> +      <description summary="extend surface interface for security">
> +        Instantiate an interface extension for the given wl_surface to
> +        provide surface security. If the given wl_surface already has
> +        a security object associated, the security_exists protocol error
> +        is raised.
> +      </description>
> +
> +      <arg name="id" type="new_id" interface="zwp_security_v1"
> +           summary="the new security interface id"/>
> +      <arg name="surface" type="object" interface="wl_surface"
> +           summary="the surface"/>
> +    </request>
> +  </interface>
> +
> +  <interface name="zwp_security_v1" version="1">
> +    <description summary="security interface to a wl_surface">
> +      An additional interface to a wl_surface object, which allows the
> +      client to specify that a surface should not appear in screenshots
> +      or be visible on non-secure outputs.
> +
> +      If the wl_surface associated with the security object is destroyed,
> +      the security object becomes inert.
> +
> +      If the security object is destroyed, the security state is removed
> +      from the wl_surface. The change will be applied on the next
> +      wl_surface.commit.
> +    </description>
> +
> +    <request name="destroy" type="destructor">
> +      <description summary="remove security from the surface">
> +        The associated wl_surface's security state is removed.
> +        The change is applied on the next wl_surface.commit.
> +      </description>
> +    </request>
> +
> +    <request name="only_visible_on_secure_output">
> +      <description summary="set the only visible on secure output state">
> +        Constrain visibility of wl_surface contents to secure outputs.
> +        See wp_secure_output for the description.
> +
> +        The only visible on secure output state is double-buffered state,
> +        and will be applied on the next wl_surface.commit.
> +      </description>
> +    </request>
> +
> +    <event name="secure_resolution">
> +      <description summary="largest resolution that can be output securely"/>
> +        This event tells the client the largest resolution at which the
> +        client's content can be show securely. If the client uses attaches
> +        a buffer to the surface this wp_security object was created with
> +        that is a larger size than this resolution, the behaviour is
> +        compositor-defined. As an example, the compositor may choose to
> +        downscale the content or simply refuse to display it, but is not
> +        limited to these behaviours.
> +
> +        The server may send this event multiple times over the lifetime of this
> +        object, as the status of security changes.
> +
> +        If the server sends this event with both width and height as zero,
> +        then no content can currently be output securely. The server must not
> +        send any event where only one of width or height are zero.
> +
> +        Before the server has sent the first of these events, the client
> +        should assume that no content can be output securely, i.e. width
> +        and height are both zero.
> +      </description>
> +      <arg name="width" type="int" summary="largest secure width"/>
> +      <arg name="height" type="int" summary="largest secure height"/>
> +    </event>
> +  </interface>
> +
> +</protocol>