Kernel support for HDCP

HDCP is based on encryption and authentication. An HDCP-compliant device is not allowed to send high-quality media streams to any other device that cannot authenticate itself under the HDCP protocol and show that it contains a suitable key. In theory, HDCP prevents the extraction of digital media streams from a chain of devices using it; the practice is, as is often the case, a bit less certain. That notwithstanding, various content providers require HDCP to be present before making their offerings available.

Many of the devices implementing HDCP — set-top boxes, televisions, etc. — run Linux, but the kernel itself does not currently have HDCP support. That may be about to change with this patch set from Sean Paul implementing HDCP for Intel i915 graphics. One part of the patch set in particular provides a generic capability in the direct-rendering layer to enable user space to turn on the content protection feature of the hardware; the application can also verify whether the graphics subsystem was able to establish an authenticated connection with the device at the other end of the cable. Said application is likely to use that information to refuse to play content in the absence of an HDCP-compliant device on the line.

This patch is not new; it was first posted in 2014. Paul noted that: "We [Google] have been using this in ChromeOS across exynos, mediatek, and rockchip over that time". So, in a sense, the kernel has had HDCP support for some time, it just hasn't found its way into the mainline.

Naturally, some developers might prefer that such a feature not get into the mainline now either. Pavel Machek, in particular, questioned the value of HDCP support, asking when the user of a machine would ever want to turn this feature on. Alex Deucher replied that it could be used to protect sensitive video streams in governmental offices (though Alan Cox questioned that idea). Paul said: "We have a lot of Chrome OS users who would really like to enjoy premium hd content on their tvs". There is truth in that latter claim. Just like many users didn't see a Linux system as being usable without the ability to play MP3 files regardless of that format's patent issues, others want to use their systems to play content that is only available through HDCP-protected streams.

The defenders of HDCP also made the point that the hardware has the content-protection capability already; the kernel patches are merely exposing that capability to user space. They bring the feature in from the cold and put it where it can be seen; as Paul put it: "Having all of the code in the open allows users to see what is happening with their hardware, how is this a bad thing?" The alternative, he noted, might be to hide the feature entirely in the firmware or in a user-space binary blob.

The real complaint, arguably, is not that the patch makes an undesirable feature available. User space can instruct current kernels to do no end of unpleasant things already. Instead, consider this reply from Daniel Vetter explaining that the HDCP feature is not a full content-protection implementation:

Machek complained that having the feature available would lead to the creation of more systems that are locked down in just this manner. "That is evil, and [a] direct threat to [the] free software movement", he said. No doubt, others will agree with that sentiment.

The problem with this argument, of course, is that those systems already exist, and the kernel patches that enable hardware DRM capabilities already exist. Hardware vendors have not proved to be even slightly reluctant to apply out-of-tree patches to their kernels, so keeping this feature out of the mainline is unlikely to have any measurable effect on the number of locked-down systems in the market. The technology exists, and content providers seem to be of the opinion that it will prevent their precious shows from being pirated, so it will be shipped in consumer devices regardless of the state of mainline kernel support.

What keeping this code out of the kernel would do is to make a statement that digital rights management technologies are unwelcome in general. That is an unlikely position for the kernel community to take, though. It is worthwhile to take a look back at Linus Torvalds's 2003 "DRM is perfectly OK with Linux!" posting for the policy that he applies to kernel code implementing this sort of feature. Beyond that, one should remember that the bulk of kernel development is supported by companies working in this area; such companies have proved remarkably reluctant to take this kind of philosophical position.

So the end result is almost certainly that this patch set will go in without a whole lot of fuss. In the distant future, when consumer-electronics device vendors upgrade their kernels, they'll have one less out-of-tree patch to apply in the process. Beyond that, it is unlikely that anybody will notice any difference.