The READ LONG command returns vendor-specific data containing: a) user data or transformed user data b) protection information or transformed protection information c) additional information (e.g. ECC bytes)
"Transformed" means the bytes might not contain the literal user data or p.i. - e.g. it could be encoded different than 8 bits per byte. The ECC could be scattered throughout; it's not always appended to the end. It is not possible to reliably retrive the user data or protection information from READ LONG data (vendor-specific instructions would be needed). If you READ LONG from one LBA on a particular drive and WRITE LONG to: different LBA: might work different drive, same vendor/model: might work different drive, same vendor, different model: might work different vendor's drive: probably won't work You can issue a READ command with the RDPROTECT field in the CDB set to 011b to return the user data + protection information, but disable checking of all the fields along the way. WRITE with WRPROTECT = 011b does the same for writes. That disables one of the main benefits - letting the disk drive check the fields before writing bad data to the medium. -- Rob Elliott, [EMAIL PROTECTED] Hewlett-Packard Industry Standard Server Storage Advanced Technology https://ecardfile.com/id/RobElliott > -----Original Message----- > From: james hughes [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 20, 2005 12:19 PM > To: Elliott, Robert (Server Storage) > Cc: james hughes; SISWG > Subject: Re: the extra 8 bytes.... > > > On Dec 20, 2005, at 12:49 PM, Elliott, Robert (Server Storage) wrote: > > Encrypting the CRC, on the other hand, preserves some value for > > storage purposes. However, if you decrypt with the wrong key, > > the CRC will be wrong. This would complicate reading data from > > a disk if you don't know the key - you'd have to disable CRC > > checking in the read command. Does the WG expect to be able to > > make a copy or an image backup of a disk without knowledge of > > the key? > > Can they do the special read extended command and get the extra 8 > bytes and copy them also? > > > > -- > > Rob Elliott, [EMAIL PROTECTED] > > Hewlett-Packard Industry Standard Server Storage Advanced Technology > > https://ecardfile.com/id/RobElliott > > > > > > > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > >> Behalf Of [EMAIL PROTECTED] > >> Sent: Tuesday, December 20, 2005 11:19 AM > >> To: SISWG > >> Subject: RE: the extra 8 bytes.... > >> > >>>> ... the drive needs to encrypt the 512 bytes of user data, > >> calculate the CRC of the encrypted data, and store that value > >> rather than the plaintext CRC. > >> > >> As I said several times, there is no need for a CRC over the > >> encrypted > >> data. The disk drive has internal error correction, so > more powerful > >> measures are taken in the background, anyway. Also, this CRC is > >> meaningless for the decrypted data, which is provided by the > >> drive, so > >> it is useless. Furthermore, the firmware is not fast > enough for a CRC > >> so computing this useless information would necessitate further HW > >> changes. > >> > >> Laszlo > >> > >>> -------- Original Message -------- > >>> Subject: RE: the extra 8 bytes.... > >>> From: "Elliott, Robert (Server Storage)" <[EMAIL PROTECTED]> > >>> Date: Tue, December 20, 2005 10:35 am > >>> To: "SISWG" <[EMAIL PROTECTED]> > >>> > >>>> -----Original Message----- > >>>> From: David McGrew [mailto:[EMAIL PROTECTED] > >>>> Sent: Tuesday, December 20, 2005 8:18 AM > >>>> To: Elliott, Robert (Server Storage) > >>>> Cc: SISWG > >>>> Subject: Re: the extra 8 bytes.... > >>>> > >>>> Robert, > >>>> > >>>> On Dec 15, 2005, at 8:44 PM, Elliott, Robert (Server > >> Storage) wrote: > >>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > >>>>>> Behalf Of [EMAIL PROTECTED] > >>>>>> Sent: Thursday, December 15, 2005 9:49 PM > >>>>>> To: SISWG > >>>>>> Subject: RE: the extra 8 bytes.... > >>>>>> > >>>>>> Rob, what is your point? > >>>>> > >>>>> Since the 520 topic is under discussion, I want to > >> ensure everyone > >>>>> understands the difference between 520 byte formatted disks and > >>>>> 512+protection information formatted disks. > >>>>> > >>>>>> Should the standard differentiate between SW > >>>>>> and HW implementations? The drive does not know if part of > >>>> a block is > >>>>>> protection information or data, therefore it must encrypt > >>>> everything. > >>>>> > >>>>> For drives formatted with 520 byte logical blocks, that's true. > >>>>> > >>>>> For drives formatted with 512 byte + protection > >> information logical > >>>>> blocks, that's not true. The drive understands the > >> contents of the > >>>>> protection information. > >>>>> > >>>>> It might encrypt the extra 8 (losing compatibility with SW > >>>> encryption) > >>>>> or it might not (maintaining compatiblity). I'm not sure > >>>>> compatiblity is > >>>>> crucial, but understanding the difference seems important. > >>>> > >>>> If the extra 8 bytes is left unencrypted, would that mean > >> that there > >>>> is a CRC of the plaintext that is left in the clear? > >>>> > >>>> thanks, > >>>> > >>>> David > >>>> > >>> > >>> Correct - and that leaks information. That's why (as mentioned > >>> earlier in the thread) the drive needs to encrypt the 512 bytes > >>> of user data, calculate the CRC of the encrypted data, and store > >>> that value rather than the plaintext CRC. > >>> > >>> From several messages earlier: > >>>>>>> A drive with protection information needs to avoid storing > >>>>>>> the plaintext CRC; it can store the CRC of the encrypted > >>>>>>> user data instead. If it does not encrypt the Tag fields, > >>>>>>> it is compatible with an application performing encryption. > >>> > >>> -- > >>> Rob Elliott, [EMAIL PROTECTED] > >>> Hewlett-Packard Industry Standard Server Storage Advanced > Technology > >>> https://ecardfile.com/id/RobElliott > >> > >
