Posted on 11/12/2017 by Daniel Stone
Recently, Sean Paul from Google's ChromeOS team, submitted a patch series to enable HDCP support for the Intel display driver. HDCP - or High-bandwidth Digital Content Protection to its parents - is used to encrypt content over HDMI and DisplayPort links, which can only be decoded by trusted devices.
HDCP is typically used to protect high-quality content. A source device will try to negotiate a HDCP link with its downstream receiver such as your TV or a frame-capture device. If a HDCP link can be negotiated, the pixel content will be encrypted over the wire and decrypted by the trusted downstream device. If a HDCP link cannot be successfully negotiated and pixel data remains unencrypted, the typical behaviour is to fall back to a lower resolution, or quality that is in some way less desirable to capture.
This is a form of copy protection usually lumped in with Digital Rights Management, something the open source community is often jumpy about. Most of the sound and fury typically comes from people mixing up the acronym with the kernel's display management framework called the Direct Rendering Manager; this is thus the first known upstream submission of DRM for DRM.
Regardless, there is no reason for the open-source community to worry at all.
HDCP support is implemented almost entirely in the hardware. Rather than adding a mandatory encryption layer for content, the HDCP kernel support is dormant unless userspace explicitly requests an encrypted link. It then attempts to enable encryption in the hardware and informs userspace of the result. So there's the first out: if you don't want to use HDCP, then don't enable it! The kernel doesn't force anything on an unwilling userspace. Sinks (such as TVs) cannot demand an upstream link provide HDCP, either.
HDCP support is also only over the wire, not on your device. A common misconception is that DRM means that the pixel frames coming from your video decoder are encrypted. Not so: all content is completely unencrypted locally, with encryption only occurring at the very last step before the stream of pixels becomes a stream of physical electrons on a wire.
Technically speaking, this means that all framebuffers presented to DRM/KMS, are provided unencrypted; if GPU composition is involved, the buffers presented through OpenGL or Vulkan for composition are also unencrypted, as is the GPU output. These unencrypted buffers are placed on a plane, which is mixed into a single CRTC's unencrypted output by the display controller. Only once the final CRTC pixel stream makes it to the encoder stage (where it is transformed from pixel content into a stream of DisplayPort/HDMI signals) does the encryption occur. By this stage, the content is already unrecognisable, as it has been prepared for electrical transmission by 8/10b encoding, potentially cut into DisplayPort packets, and so on.
HDCP is only downstream facing: it allows your computer to trust that the device it has been plugged into is trusted by the HDCP certification authority, and nothing more. It does not reduce user freedom, or impose any additional limitations on device usage.
The only way for a secure decode pipeline to be implemented, is a complete hardware-backed verified boot sequence. In this, the hardware itself must be a vital link in the content pipeline (holding, e.g., decryption keys for content), and it must be able to attest that the device is only running trusted code which is unwilling to leak content. There are a number of ways to boil that particular ocean, but having your display hardware enable over-the-wire encryption is pretty much irrelevant.
In short, if you already run your own code on a free device, HDCP is an irrelevance and does not reduce freedom in any way.
A look at the work and motivation behind implementing the Khronos EGLDevice extensions in Mesa. These extensions allow users of open source…
GNOME Builder is an Integrated Development Environment designed for the GNOME ecosystem. It most notably features a deep integration to…
Presenting a new, hardware-backed, software graphics driver, built upon the Mesa gallium driver framework, which uses kernel kms drm nodes…
Last week, a new version of docker.io, the Docker package provided by Debian, was uploaded to Debian Unstable. Quickly afterwards, the package…
In Debian and derivative systems, there are many ways to build images. The simplest tool of choice is often debootstrap. It works by downloading…
Launched by Haivision in 2017, and freely available on GitHub via the Mozilla Public License 2.0, SRT is an innovative UDP-based protocol…