The T13 committee is considering a proposal to embed a copy control system called CPRM in ATA hard drives. The proposed modifications to the ATA specification are available online.

Since the CPRM specification is available only on paper, can you describe CPRM briefly for us?

My understanding and best guess is the Motion Picture Association wants to create a "pay-per-view" infrastructure for digital content on the Internet.

We currently have :
        theaters                pay per view
        video-rental/purchase   not pay per view
        cable                   not pay per view
        dish-networks           not pay per view
They appear to want :
        Internet downloads      pay per view
        w/ counter              more pay per view

Basically they may want to charge you for every usage of content, regardless of whether you purchased it already.

What is meant by a "CPRM application" and "CPRM content?"

CPRM content: a file which paranoid people do not want you to have the ablity to view/use how you wish.

CPRM application: a program/tool/driver that you pay a license fee to obtain or create, regardless. It is the barrier used to write or read encrypted content to prevent general use of that which is yours.

CPRM layer on ATA device <-> driver(host/os) <-> CPRM application

The application will generally have the decoder.

How will CPRM affect an ordinary desktop or server Linux user?

If it is never allowed to be executed, no effect. If it is executed, hope you backed up your stuff first.

Will I be able to install and run Linux normally on a CPRM drive if I choose not to use any CPRM applications?

Yes, in principle. On a PC, there are 31 seconds that pass when you push the power button on, during which the BIOS is in control. Without very special tricks that I have not created yet, but have an idea how to, you can not control what happens during that window before Linux takes over.

Will you need to modify the Linux IDE subsystem to handle CPRM drives?

Initially Linux may have to filter the return content of the IDENTIFY page from the device to prevent checking of the feature. An application that tries to use CPRM will abort.

The CPRM command-set is most likely to be in the "RAW-IO" class of device access. Only the contiguous nature of the content to be placed on the media only makes this method of access practical. Linux does not support RAW-IO video streaming to date.

Would you need to modify the Linux IDE subsystem if CPRM applications for Linux became available?

CPRM might require changes to:
       ./linux/fs/* &&
       ./linux/block/??*.x &&
       ./linux/ide/ide-*.x &&
       ./linux/cdrom/cdrom.x &&
       ./linux/scsi/??*.x &&

I just do not know the depth of the mess that would be needed to support it.

Why will CPRM force some embedded Linux vendors to rewrite their software?

They will be required to write an entire ATA driver replacement and any other filesystem layer needed to handle the calls. These can only be implemented as loadable modules, if the terms of GPL are followed.

Will dd if=/dev/hda of=/dev/hdb still work?

Yes, but the data may transfer in its encrypted form, so you can not read it or recover it to a different drive.

A dd-cprm program to copy the data unencrypted would have to exist and this is what CPRM proponents do not want to happen.

Is there anything about CPRM that keeps you from making a copy of CD audio on your hard drive, using existing software?

Not that I know of yet, but remember that this is embedded in the device. If the device is CPRM enabled, it may only allow you to access the content with a CPRM tool. Now the game begins...the content is yours, but you can not use it.

Will you be able to completely disable CPRM at the driver level, so that a CPRM drive acts like a non-CPRM drive, even if CPRM applications try to send it CRPM commands?

In principle I can stop it in the driver if it goes throught the normal IO layers. All of this is dependent on making an exemption to the "Unix Policy of No Policies", to filter or block this command.

Are you the only voice of reason and freedom on the T13 committee, or are other members against CPRM too?

No, there was one other company that was against it, and they are Linux friendly. The majority were on the sidelines to get more advice on the issue. I can not name them yet because I need to get their permission.

What is the one thing that bothers you the most about the CPRM proposal?

The very nature of the feature set enable. There is a concatenation of the first five taskfile registers to create a 39-bit and not a 40-bit enable passcode. The last bit is defined as always 0. Thus this leads one to question if there is a back door when the last bit is set to 1 and the other 39 bits are set to a certain value. Is it possible for the LC4 gang to enable certain undocumented features?