Security

Enabling DRM in the kernel?

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:

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:

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.

Comments (22 posted)

cyrus-sasl: buffer overflow

Comments (none posted)

drupal: cross-site scripting

Comments (none posted)

giflib: several vulnerabilities

Comments (2 posted)

gnutls: incorrect certificate validation

Comments (none posted)

ipsec-tools: denial of service

Comments (none posted)

ipsec-tools: denial of service

Comments (none posted)

kernel: privilege escalation

Comments (none posted)

kernel: SELinux check bypass

Comments (none posted)

nsd: buffer overflow

Comments (none posted)

ntp: buffer overflow

Comments (none posted)

phpmyadmin: multiple vulnerabilities

Comments (none posted)