Enabling DRM in the kernel?

Please consider subscribing to LWN Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.

Back in April, we looked at the Linux kernel patches for Intel's Trusted Execution Technology (TXT), a mechanism to verify the integrity of the kernel before booting it. Since that time, another version of the patchset has surfaced. The relatively few comments on the feature were largely concerned that there might be opposition to its inclusion—not because of technical considerations, but instead because of ethical concerns about what TXT could enable.

Ted Ts'o had the most to say about what TXT (also known as LaGrande) enables, not necessarily in opposition to adding the feature, but outlining the concerns of those who might. He warned: "So we should expect a certain amount of controversy and people lobbying to resist the acceptance of this patch." The basic problem is that TXT can enable Digital Rights Management (DRM) systems that are largely uncrackable.

Pointing to a "Trusted Computing" FAQ from 2003, Ts'o noted that five years ago, FAQ author Ross Anderson "was able to predict the emergence of the LaGrande Technology (see question 15 in the above FAQ)." But, Joseph Cihula, author of the TXT patch noted that some of the FAQ (and other Trusted Computing complaints) had been rebutted [PDF] in an IBM whitepaper by David Safford. But, as Ts'o pointed out, much of Safford's response was specific to the Trusted Computing Platform Alliance (TCPA) technology, which is essentially broken as a DRM lockdown solution:

However, it seems to me that TXT/LaGrande's main purpose for existence was to repair the defects in TCPA that made it essentially [unusable] for DRM purposes. With TCPA, any time you changed *anything* in the boot path --- installed a new BIOS, upgraded to a new kernel to fix a security vulnerability, updated to a new Nvidia proprietary video driver slightly less likely to crash your [system] --- it would change the trusted boot measurements, and would require an exchange to "[Circuit] City DIVX hotline" (as a generic stand-in for whoever is Hollywood's current monkey paw towards trying to implement DRM) to approve a transfer of the TCPA trusted keys, which would be essentially be a consumer support nightmare, and there would be no way for "Circuit City" to know whether the kernel you are claiming was the latest update from Fedora or Novell or Canonical was really an authorized upgrade, or whether it was a custom kernel with patches to tap into video and audio paths to steal Hollywood's precious bodily fluids. With TXT, however, all of these problems go away. What you end up booting is completely under "[Circuit] City's DIVX's" control, and may include a miniature Windows environment running in the trusted environment; it could then take over a portion of the screen for the video output, and the hardware would have special features set up to prevent the host OS from having any access to the video output of the movie player running in the TXT environment.

Ts'o's message is worth reading in its entirety, but the basic point is that TXT enables Hollywood (or another DRM-happy entity) to take away some of the basic functionality of the hardware in order to preserve their "rights". Essentially, this takes away users' rights to protect companies' perceived or actual rights. The truly nightmarish scenario is one where one cannot do anything on a computer that isn't contained in a signed (presumably proprietary and closed source) application, running on a signed operating system. TXT could enable just that kind of functionality.

But, there are some scenarios (Ts'o mentions medical record access) under which TXT could be beneficial to the user. Other devices (voting machines and ATMs are the standard example) could benefit from TXT as well. Should kernel hackers stand in the way of adding this code to the kernel simply because it can be used for ill? The consensus, from the extremely limited subset of the kernel development community participating in the discussion, seems to be "no".

James Morris notes Linus Torvalds's famous "Flame Linus to a crisp!" message wherein he says: "I want to make it clear that DRM is perfectly ok with Linux!". Morris more-or-less agrees with that view:

I'm fairly neutral on the technology itself and feel that "market pressure" from users as well as local regulatory policy (e.g. anti-trust laws) should determine how the technology is used, rather than the views of a few kernel hackers.

That sentiment is also shared by Ts'o: "That being said, it's not clear to me that stopping the technology from going into Linux really isn't going to help matters; realistically, the Linux desktop is miniscule[1], and whether or not we add support for TXT in the mainline Linux kernel isn't going to stop Hollywood's plans." His footnote refers to the potential risk of TXT being used in Moblin to lock down those devices, but "realistically, even if we don't let it into mainline kernel, it won't stop Moblin hardware vendors from shipping it".

This is a social, not a technical problem, as Ts'o says. There are powerful interests that certainly want to have that kind of power over the actions of their customers. It will be up to those who value their hardware and software freedoms (and, very likely, the courts) to ensure that those freedoms are still available. Avoiding DRM is not something that has gotten onto the radar of most consumers, but the content providers are doing their best to raise its visibility. One wonders how many revoked features for Kindle books or how much music that expires because it is crippled with DRM it will take before consumers start to rebel.

In the meantime, though, it seems likely that Linux will end up with TXT support somewhere down the road. The objections have been few—technical or ethical—at least so far, and the code obviously exists. There is no barrier to a hardware manufacturer (or distribution) incorporating it and enforcing whatever restrictions it wishes. Given that there are benign uses as well, the code is likely to improve from its inclusion in the mainline. When (almost certainly not "if") those uses turn towards total lockdown, it will be a social battle, on multiple fronts, to preserve the hardware and software freedoms we enjoy today.

