Re: Storage system

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Feb 7, 2014, at 9:36 AM, David Brown <david.brown@xxxxxxxxxxxx> wrote:

> On 07/02/14 17:25, Can Jeuleers wrote:
>> On 02/07/2014 05:11 PM, David Brown wrote:
>>> The only thing you can't erase are re-mapped sectors - but hopefully
>>> those will be rare!
>> 
>> I wonder if using the Secure Erase feature destroys all sectors
>> (including remapped-ones) or not.
>> 
> 
> I think secure erase can be done in different ways.  On disks that have
> full-disk encryption, it simply erases (or changes) the password.  For
> other drives, it has to write through all sectors on the disk - I would
> expect re-mapped sectors are included, but I don't know the details.

>From the September 2012 draft, rev 1 of NIST 800-80, they distinguish between the following ATA commands:

	• ATA sanitize command
	• ATA Secure Erase command
	• Cryptographic Erase

I don't have a clear understanding of what "sanitize" command is, although it's relatively new. None of my drives have it. hdparm reports my drives support SECURITY ERASE UNIT and ENHANCED SECURITY ERASE UNIT. For HDDs, these take the same time. The first one writes zeros. The 2nd one writes a manufacturer defined pattern (i.e. it's almost certainly not random). The Samsung 830 SSD also has these two commands, but the time difference between them was substantial: I *think* 3 minutes for one and 18 minutes for the other.

Cryptographic erase doesn't overwrite anything. It just makes sure the MEKs are changed, thereby making the drive unreadable, since SEDs are always encrypting using a MEK, even if there isn't a KEK set.


> 
> 
>> Also, what level of trust do people on this list have that the disk's
>> Secure Erase feature does what it says on the tin?\

Again NIST 800-80 says: "Verification must be performed for each technique within Clear and Purge, except degaussing." Strictly speaking the trust is zero without verification.

Chris Murphy--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux