[PATCH RFC wayland-protocols] Add secure output protocol
Nautiyal, Ankit K
ankit.k.nautiyal at intel.com
Thu Nov 29 09:39:55 UTC 2018
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 at collabora.com wrote:
> From: Scott Anderson <scott.anderson at 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 at 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 at 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>
More information about the wayland-devel
mailing list