Wiring DRM into the system [LWN.net]

An interesting bit of corporate research was recently performed by the EFF's Seth Schoen, who attended the Microsoft Windows Hardware Engineering Conference and wrote up a four-part report on what he learned (part 1, part 2, part 3, and part 4). The resulting picture suggests that Microsoft is going out of its way to appease the entertainment industry with its future products. Upcoming Windows releases will be able to ensure that no "unauthorized" hardware or software exists on the system. Load an application which the "protected media path" code does not like, and much of the system's multimedia capability could be shut down. A Microsoft-controlled "revocation list" will allow drivers to be disabled by Microsoft in the future should those drivers be determined to not properly implement the DRM specifications. Overall, it is a vision of a world where "our" computers are, increasingly, not under our control and not operating in our interests.

The comments on the original LWN posting pointing to Seth's reports suggest that many readers believe that this sort of intrusive DRM technology will provoke a massive consumer backlash and, as a result, fail in the market. There are some signs that this hope could be realized; there is currently a fair amount of grumbling in the U.S. over the HDCP copy-protection mechanism, which can prevent the delivery of high-resolution video to large numbers of high-definition TV monitors which do not implement HDCP. As others have often said: Americans will put up with all sorts of misbehavior from both governments and corporations, but they will not tolerate anybody who messes with their TV.

All of this may be wishful thinking, however. It may well be that the industry will get its DRM technology working to the point that it no longer interferes greatly with the life of the average couch potato. If things "just work" for most people, they will be accepted by those people. Few of us have the time or knowledge to worry about the larger issues of fair use, control over our own systems, or long-term sustainability of the cultural commons. After all, there's a game on in a few minutes.

Consider also the reports that Apple is planning to make use of the trusted platform module (TPM) chip in its future kernels. The primary purpose here, most likely, is to keep people from running Mac OS on non-approved x86 systems. But it is hard to believe that Apple would not also use the TPM, for example, to help ensure that audio files do not escape from the one system where they are authorized to be.

Then consider that the latest Linux kernel includes basic TPM support, and work is underway to increase that support. As was discussed at the Ottawa Linux Symposium, the TPM can do a number of good things for Linux users. It can also, however, be used to deprive a Linux user of control over the system and implement all of the same DRM stuff which is being added elsewhere. A Linux-based set-top box could be just as user-hostile as one based on Windows. Availability of source would not be helpful in such a situation; the TPM can be used to ensure that the system will boot only kernels which have been signed with a specific key. Linus Torvalds has stated in the past that this sort of usage is fine with him.

Now, Linus is not the only copyright holder for the kernel, and others may yet decide that the GPL requires that the keys used to sign the kernel be distributed with the source. The GPL's source distribution requirements do include "the scripts used to control compilation and installation of the executable," after all. It may even be that a court will buy that argument. But any such finding will be at the far end of a long process of litigation; it is an uncertain and distant prospect. In the mean time, it is safe to assume that we will see more systems which, while running Linux, allow no more user control than their equivalents based on proprietary software.

At OLS, Jim Gettys compared the DRM situation to the American experiment with crypto export regulations. We'll win in the end, but there may be a decade or two of pain in the middle. Sadly, it appears that we are just beginning to enter the "pain" phase of this battle. This is a fight we can win; we will likely be helped by the fact that the entertainment industry will have a hard time stopping short of the point that makes consumers rebel. But there may indeed be some unpleasant times between here and there.

(Log in to post comments)

Wiring DRM into the system

Posted Aug 4, 2005 4:58 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]

Claims that the GPL could force people to give up the private keys they used to sign a GPLed binary with are nonsense, and this is fortunate. Otherwise Red Hat has to give up their private key (that they use to sign RPMs with).

Even if a legal argument of this kind could be found, there's the problem that the program that checks a Linux kernel's signature is likely to be the boot loader, and that program doesn't have to be GPLed. There doesn't appear to be much we can do to keep people from adding DRM to the kernel, and then trying to prevent the device from booting unsigned kernels. The only consolation is that they have to release the full source code, so that everyone can figure out just what the DRM is doing. Attempts to impose terms forbidding reverse engineering of a GPLed program would be a violation of the terms of the GPL.

Many Linux-based products already attempt to detect modification and refuse to boot (Tivo does this), but so far the protection has been easily crackable. It doesn't seem to me that the new Intel features are really necessary to make a device that is much harder to modify, though.

Wiring DRM into the system

Posted Aug 4, 2005 8:53 UTC (Thu) by MathFox (subscriber, #6104) [Link]

Claims that the GPL could force people to give up the private keys they used to sign a GPLed binary with are nonsense, and this is fortunate. Otherwise Red Hat has to give up their private key (that they use to sign RPMs with).

You are correct for RPMs because it is possible to install unsigned packages. The moment that a kernel only runs signed binaries (the signature is essential for a program to run) it can be argued that creating a signature is an essential step in the process of building a program and a developer can invoke section 3 of the GPL:

For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.

I feel that there's a fair chance that a distributor of signed GPL binaries can be forced to hand over his keys (or stop distribution.) We won't know until the dust has settled.

Giving up your keys

Posted Aug 4, 2005 10:35 UTC (Thu) by man_ls (subscriber, #15091) [Link]

IANAL, but it is easy to argue this one out. The keys are not essential to the build process; Red Hat uses their own keys, just as you could use yours. You might build a Red Hat clone with your own keys (some people do that already) and it would work just as well.

And, given that a "key" in this case is a prime number chosen at random (or similar mathematical artifact) there is no shortage of them that you might require Red Hat's; you might as well ask for the developer's password.

Giving up your keys

Posted Aug 4, 2005 11:12 UTC (Thu) by MathFox (subscriber, #6104) [Link]

IANAL either, but I see that I was not clear in my previous comment.
If the key is not essential to the ability to run a binary, I see no reason to force someone to provide the key (like the RedHat signature on some RPMs).

When someone provides an "trusted" platform that requires signed executables signing the executable is an essential step in the building and installation process. Under those circumstances the distributor of an GPL application running on the trusted platform might be forced to provide a key that allows signing of modified binaries, so that they can run on the platform.
I am only saying that in that case a convincing argument can be made in front of a judge, not what the final decision will be.

Giving up your keys

Posted Aug 4, 2005 18:01 UTC (Thu) by man_ls (subscriber, #15091) [Link]

My point, apart from being a bit bogus itself, was not clear either. It may be integral to the process that you sign the executable; but the particular key that you use is not. You can choose a prime number (or a couple of them) at random, and you can use that to sign the package / executable / kernel / whatever. If you need a signed certificate, go to whomever signs them.

And then you complain that you cannot run it on your machine, because your hardware vendor is an evil company and has locked it up. The software vendor will say: "Well, that is not my problem; find another machine which accepts your signature (credentials) or build it yourself or forget about it. You have the source code, so suit yourself." You are in the jury; what would you say?

You can build a case for a judge, but IMHO you might as well complain that you need the root password to build and install a program, and Red Hat did not provide it.

Giving up your keys

Posted Aug 6, 2005 22:30 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

I believe the argument that GPL requires the distributor to supply his signing key is this:

GPL says that if I give you a binary, I must also give you all the source material needed to build that binary. Not just a similar binary; the one I actually gave you. I have to give you the scripts that contain the linker options I used, for one thing. Giving you the signing key isn't much of a stretch from that.

You can argue technically either way, but the spirit of the GPL is that the recipient of a binary is supposed to be able to make useful modifications. Shipping a binary that works only because it's signed with a key the recipient doesn't know clearly does an end run around that goal and produces the same result as shipping object code without source.

Wiring DRM into the system

Posted Aug 4, 2005 19:02 UTC (Thu) by jonabbey (subscriber, #2736) [Link]

A more interesting question is the relationship between private and public keys. To wit, is a private key considered in some way necessary source for a matching public key embedded in a Linux kernel?

I don't see any other reason why a Linux kernel could not be legally made to run only signed binaries. The public key used to verify the signatures would have to be made available under the GPL, obviously, but possession of that public key wouldn't make it possible to produce binaries that such an (unmodified) kernel would load and run.

So, if the hardware were to contain a public key to verify signed kernel binaries, and the kernels that were so signed contained a public key to validate software to be loaded on that kernel, then you've got a fairly decent lock down of the software that can be run.

Wiring DRM into the system

Posted Aug 4, 2005 8:52 UTC (Thu) by kleptog (subscriber, #1183) [Link]

Two points:

It may well be that the industry will get its DRM technology working to the point that it no longer interferes greatly with the life of the average couch potato. If things "just work" for most people, they will be accepted by those people.

But it seems to me that if the DRM isn't getting in the way of most people it has either failed to reach its stated goals (people expect to be able to share songs with friends, back them up, copy them to cd to play in the car, etc) or it's basically gotten to a level where it matches people's expectations. Would that be success? From who's point of view?

This would mean you're OK as long as you conform to the majority (ie enough people are with you to matter). Hmm.

But it is hard to believe that Apple would not also use the TPM, for example, to help ensure that audio files do not escape from the one system where they are authorized to be.

But iTunes right now allows you to copy it a few times without problems and most people are fine with that. If iTunes went back on that I think they'd have a serious problem.

Anyway, if you buy a computer from a major supplier pre-installed with windows and the TPM won't let me wipe the disk and install Linux, well, I'm fairly sure that wouldn't be legal in many juridictions. Only time will tell. The more popular we can make non-mainstream OS's (Linux, BSD, etc) the better our defence.

Wiring DRM into the system

Posted Aug 4, 2005 13:17 UTC (Thu) by kh (subscriber, #19413) [Link]

I wonder how much DRM is in our current systems and we just are not aware of it. I had a friend complain to me about his new notebook, he can not show a DVD on his LCD and the external screen simultaneously. I looked into it, and eventually found documentation from the manufacturer of the video card that stated that it was not possible to do so due to hardware limitations. I checked a few other notebooks as posible replacements, but they were also similarly limited. I decided this was simply the case, and reported my research to the notebook's owner, and then he showed me his old notebook (from ~1998 or 1999 running Windows 98) that had no problem displaying video as he wanted. I went back and did some more googling and found some mentions of DRM plans from the video card company, but nothing definitive other than it works on a really old notebook, but not on the newer ones. I called the company and the person I spoke to basically called me a liar when I told him about the old notebook. (I understand the disconnect between the support desk and the engineers of these companies, which is another source of frustration when forced to purchase such proprietary hardware - I really hope something comes from that opensource video card effort. It's really sad to me that we still have to feel RMS's Xerox pain.)

Wiring DRM into the system

Posted Aug 4, 2005 13:38 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

The hardware manufacturer is right, here's what's going on and there's no DRM or secret handshakes or anything...

The modern hardware has effectively two DACs to drive two separate devices, this allows it to run at say 800x600 for a cheap VGA projector while also offering 1024x768 on the main LCD screen. Now the YUV overlay used to accelerate video playback performance is normally connected to the DAC and so it cannot overlay onto two different surfaces at once. Another part would have to be added (more expense, more heat) to "fix" this. Hence if you want the acceleration (and most DVD software does) you can only see DVDs on one of the two output devices.

As to why the older laptop can do it, well first note that the newer laptop CAN display a DVD to both outputs, you just need to use software which doesn't require the accelerated YUV overlay. You may be able to switch this off in the existing software (it's easy in mplayer for example). This will probably run the CPU very hard if you make the DVD fullscreen, but there you are, that's why they added the accelerated overlay hardware... Anyway, the older laptop either happens to have two copies of the overlay hardware (unlikely) or it doesn't have such hardware at all, always relying on CPU power. Does it get pretty hot and maybe "chug" a little bit when playing DVD fullscreen on both outputs?

Wiring DRM into the system

Posted Aug 4, 2005 14:56 UTC (Thu) by dmantione (guest, #4640) [Link]

Here is a confirmation and further explanation from ATI hardware (I have
the driver DDK's):

Both old Mach64 based hardware (Rage LT pro, Rage Mobility) and modern
Radeon based hardware (Radeon) do have two CRT controllers. Both the LCD
panel and the external CRT display connector can be assigned to one of
them, you can both assign to the first, both to the second, or one on
each CRT controller.

On Mach64 hardware, only the first CRTC has access to the hardware
overlay. On Radeon hardware, both CRT controllers can use the overlay.
Unfortunately, on Mach64 hardware, only the first CRTC can do display
strecthing, necessary to run the laptop panel into something other than
its native resolution.

So, it makes sense to assign the first CRTC to the laptop panel. Now, you
can assign your external monitor to the first monitor, but then it needs
to run the same resolution and refresh rate as your LCD panel. You can
assign it to the second CRTC, so you can change the resolution, but then
you loose access to the overlay.

The newer versions of the Mach64 Windows drivers give you the choice if
you want to use one or two CRTC's. On the Radeon this choice is still
there, but both CRTC's can use the overlay.

Wiring DRM into the system

Posted Aug 6, 2005 6:22 UTC (Sat) by zblaxell (subscriber, #26385) [Link]

Never ascribe to conspiracy what is adequately explained by routine incompetence.

I had a laptop (Thinkpad A30P) for some years with an ATI Rage Mobility chipset. One day, the laptop broke. It was sent to an authorized IBM repair facility, which was paid a flat rate of $85 to fix the machine. Of course, CDN$85 doesn't buy a lot of highly skilled labor, so instead of doing proper diagnostics and fixing the real problem, they replaced the motherboard, display, case screws, and one or two other parts that broke in the shop. New BIOS firmware came along for the ride.

Before that day, I could play video through Xv overlay on both LCD and external CRT (indeed, I was actually watching a video this way when the failure occurred that caused me to return the laptop). When the laptop came back, I could no longer do this.

No changes to the software on the system occurred during that time (no such change could occur, since I kept the hard disk when I returned the laptop, and reinstalled it into the laptop when it came back--something I always do with laptop repairs since many vendors insist on running Windows software to run self-tests).

There were a number of changes on the motherboard (I had to upgrade the kernel's IDE driver to be able to use APM suspend and resume again), and several other quirky Xv behaviors changed (e.g. if the external CRT is used, its resolution didn't match the LCD, and you try to use Xv, there were different bugs after the repair than before).

The machine also had a rather annoying habit of putting the CRT in what looks like the VGA equivalent of Macrovision mode--random horizontal displacements between the start of video signal and the hsync pulse, which could only be cured by a suspend/resume cycle. This problem was present on the laptop from day one, and is still present now--it could be a genuine bug.

All of this could just be due to unintentional changes in the BIOS--since the driver is ATI and the power management is APM, a _lot_ of what the video subsystem does is specified by the BIOS, and there's a really good reason why IBM doesn't recommend users upgrade the BIOS unless they have specific problems--namely, that BIOS upgrades from IBM are more risky in terms of introducing new show-stopping problems than Linux 2.6.X-rcY kernels. There was a BIOS upgrade which broke 80x60 text mode (black screen on LCD), for example. Another BIOS upgrade intentionally changed the programming of the video chips to make less audible noise from the power supply (I'm not making this up--it's in the release notes from IBM), and a third BIOS upgrade started making noises from the Ethernet controller.

Wiring DRM into the system

Posted Aug 6, 2005 11:16 UTC (Sat) by dmantione (guest, #4640) [Link]

It is possible that the new video card, with new BIOS puts the chip into
two CRTC mode. That should be solvable by using the atyfb framebuffer
driver. You need a kernel version that includes my LCD support patches,
recent 2.4 and 2.6 ones do.

It will put the chip into single CRTC mode (because the framebuffer layer
hardly can handle multiple CRTC's) and should thus allow display Xv on
both displays.

If there's still trouble with that driver loaded (even if you are running
X), I'd like to hear, allthough I'm no longer capable to debug myself as
my Mach64 based laptop has died some time ago.