28 February 2001: Add Adam Shotack message on globally unique identifiers (GUIDs).
28 February 2001: Link to PDF version of the T13 draft standard: http://cryptome.org/e01112r1.pdf (22KB)
27 February 2001
To: gnu@toad.com, jm@eff.org, jya@cryptome.org Subject: Smoke-screen CPRM "Generic Functionality" proposal Date: Mon, 26 Feb 2001 23:09:41 -0800 From: John Gilmore <gnu@toad.com> [This is the proposal almost passed by standards committee T13 on disk drive interfaces last week. It replaced the CPRM proposal that IBM withdrew after it caused so much controversy. As anyone can see, there is nothing controversial in this new proposal; there is nothing in it at all. Every action and every data bit depends on what some other (secret, non-standard) spec would say.] ANY function stuffed into a disk drive would be compatible with this spec, which means it doesn't define a standard at all. How exactly would this promote interoperability among manufacturers? Or as the committee chair asked, before voting against it, preventing it from immediately becoming part of the standard, "Why are we doing this?" It's just a scam to give the T13 committee "plausible deniability" so they can vote for CPRM. Well, now the secret is out and it doesn't look so plausible anymore. If they really wanted to support arbitrary "generic" functionality, they should design something that would handle more than a single custom function per disk drive. If a market-dominating group of disk drive makers; computer companies like IBM, Intel, Toshiba, and Hitachi; and movie and record companies all want to go off into a smoke-filled room and define their own set of exclusionary copy-protection specs, they need to pretend they're meeting to define a standard in an accredited standards organization like T13. This proposal is their smoke-screen. Because standards meetings include the public, and procedural safeguards to protect the public interest, such meetings are exempt from the antitrust laws. But the public needs to show up in order to make those safeguards work, or the only people at the table end up being the foxes we should be guarding against. EFF joined the committee and attended their meeting. If you care about whether your disk drives will conspire behind your back to murder fair use, you should too. See www.t13.org for how to join. Get a "voting" membership, you may need that vote. -- John Gilmore] T13/E01112r1.doc February 23, 2001 Page 1 of 3 Proposal to Support Generic Functionality Generic Functionality is a proposal that allows an ATA device manufacturer to provide generic functionality using a fixed set of command codes. The functionality of the command codes is determined by a GUID stored in Identify Device. 1 IDENTIFY DEVICE Assign IDENTIFY DEVICE words 104-111 to generic functionality Global Unique Identifier (GUID) 8.14.xx Words 104-111 Generic Functionality Global Unique Identifier This field contains a 128-bit value identifying the generic functionality supported by the device. The generic function vendor shall ensure that the GUID value is unique. If the device does NOT support Generic Functionality then this field is set to zero. 2 New Commands These commands all have the same documentation. They are taken from RETIRED command codes 71h-78h. The following section documents command code 71h. The same documentation applies to 72h, 73h, 74h, 75h, 76h, 77h, 78h 2.1.1 Generic Function 1 2.1.1.1 Command code 71h 2.1.1.2 Feature set None 2.1.1.3 Protocol This command shall follow one of the protocols defined in chapter 9, the specific protocol is determined by IDENTIFY DEVICE words 104-111 2.1.1.4 Inputs Register 7 6 5 4 3 2 1 0 Features Determined by IDENTIFY DEVICE words 104-111 Sector Count Determined by IDENTIFY DEVICE words 104-111 Sector Number Determined by IDENTIFY DEVICE words 104-111 Cylinder Low Determined by IDENTIFY DEVICE words 104-111 Cylinder High Determined by IDENTIFY DEVICE words 104-111 Device/Head obs spc obs DEV spc spc spc spc Command 71h Device/Head register - DEV shall indicate the selected device. Spc bits are determined by IDENTIFY DEVICE words 104-111 T13/E01112r1.doc February 23, 2001 Page 2 of 3 2.1.1.5 Normal outputs Register 7 6 5 4 3 2 1 0 Error Determined by IDENTIFY DEVICE words 104-111 Sector Count Determined by IDENTIFY DEVICE words 104-111 Sector Number Determined by IDENTIFY DEVICE words 104-111 Cylinder Low Determined by IDENTIFY DEVICE words 104-111 Cylinder High Determined by IDENTIFY DEVICE words 104-111 Device/Head obs spc obs DEV spc spc spc spc Status BSY DRDY DF spc DRQ spc spc ERR Device/Head register - DEV shall indicate the selected device. Status register - BSY shall be cleared to zero indicating command completion. DRDY shall be set to one. DF (Device Fault) shall be cleared to zero. DRQ shall be cleared to zero. ERR shall be cleared to zero. Spc bits are determined by IDENTIFY DEVICE words 104-111 2.1.1.6 Error outputs The device shall return command aborted if the command is not supported. Register 7 6 5 4 3 2 1 0 Error Spc Spc Spc Spc Spc ABRT Spc spc Sector Count Determined by IDENTIFY DEVICE words 104-111 Sector Number Determined by IDENTIFY DEVICE words 104-111 Cylinder Low Determined by IDENTIFY DEVICE words 104-111 Cylinder High Determined by IDENTIFY DEVICE words 104-111 Device/Head obs Spc obs DEV Spc Spc Spc Spc Status BSY DRDY DF Spc DRQ Spc Spc ERR Error register - ABRT shall be set to one if this command is not supported. ABRT may be set to one if the device is not able to complete the action requested by the command. Device/Head register - DEV shall indicate the selected device. Status register - BSY shall be cleared to zero indicating command completion. DRDY shall be set to one. DF (Device Fault) shall be set to one if a device fault has occurred. DRQ shall be cleared to zero. ERR shall be set to one if an Error register bit is set to one. Spc bits are determined by IDENTIFY DEVICE words 104-111 2.1.1.7 Prerequisites None T13/E01112r1.doc February 23, 2001 Page 3 of 3 2.1.1.8 Description The functionality of this command is determined by IDENTIFY DEVICE words 104-111. 3 New Set Features This SET FEATURES is used for disabling the Generic Function. Table 32 (Set Features Register definitions) Needs to be modified to add function 32h "Disable Generic Function Capability". 3.1 Disable Generic Function Capability When this command is issued, subsequent IDENTIFY DEVICE commands shall return zero in words 104-111, and Generic Functions 1-8 shall return command not supported errors. The disabled state does not persist over a power cycle but does persist over hardware or software reset. 4 Device Configuration Overlay Generic functionality can be disabled and restored via DEVICE CONFIGURATION OVERLAY (DCO) commands. The following changes are required for DCO. 4.1 DCO Identify Data Structure Modify word 7 bit 9 "1=Generic Functions Supported" Add to 8.7.3.8.5 "Word 7 bit 9 if set to 1 indicates that the device supports IDENTIFY DEVICE words 104-111 and a minimum of one of the GENERIC FUNCTIONS. 4.2 DCO Set Data Structure Modify word 7 bit 9 "1=Generic Functions Supported" Add to 8.7.4.8.5 "Word 7 bit 9 is cleared to 0 to disable support for Generic Functionality and has the effect of setting IDENTIFY DEVICE words 104-111 to zero. [That's all, folks! -- gnu]
Date: Wed, 28 Feb 2001 14:38:39 -0500 From: Adam Shostack <adam@homeport.org> To: gnu@toad.com, jm@eff.org, jya@cryptome.org Subject: Re: Smoke-Screen CPRM "Generic Functionality" proposal Hi John, I'm writing in response to your letter last Monday about the CPRM standard. And while I agree with you that the activities that T13 is engaged in are largely secret, I think that you missed an important and dangerous public bit, the inclusion of GUIDs in hard drives. The inclusion of globally unique identifiers where they are not needed is poor engineering which has cost companies like RealMedia and Intel quite a bit of time, money and energy to correct. As you'll recall, standards like ethernet include a GUID, the ethernet address. That address is needed because in bootstrapping network communication, its useful to have an address that no one else will ever use. However, even that GUID has created problems, when, for example, the IPv6 working groups of the IETF used in in internet addresses. In a hard drive, there is no need for a globally unique identifier. Its presence creates a large privacy risk for its abuse. So, while the secret parts of the proposal may be more dangerous, I must contest your claim that there "is nothing controversial in this new proposal." Adam (Speaking for myself only) > [This is the proposal almost passed by standards committee T13 on > disk drive interfaces last week. It replaced the CPRM proposal > that IBM withdrew after it caused so much controversy. As > anyone can see, there is nothing controversial in this new proposal; > there is nothing in it at all. Every action and every data bit > depends on what some other (secret, non-standard) spec would say.] -- "It is seldom that liberty of any kind is lost all at once." -Hume