> Federico Lucifredi continues his quest to build a hardware-assisted > automagic hard-drive wiper, using perl in an embedded device.
Federico, You showed some slides explaining why drive erasure is important, and also mentioned that this task isn't a job responsibility, but you never quite explained your motivation for expending all the effort you've put into this project. Just a fun problem? Was that a dual-CPU motherboard you were using? I gather it was just a handy bit of hardware to repurpose. Regarding the problems you had hot swapping: http://www.tuxradar.com/answers/570 ...dependent on the hardware in two areas. The drive caddy system you use must be hot-swappable; most are... Secondly, your SATA controller must handle hot-swapping. It must be able to recognise when a drive has been disconnected or connected and communicate this information. Provided that happens, the OS should handle hot-swapped SATA drives much the same as it does USB or FireWire drives. More accurately, if the Linux kernel ATA driver supports the hot swapping functionality in your controller chip, then it'll work. The next step is to find your controller chip and look up whether the driver supports hot swapping with it. In older machines I've been using Silicon Image SIL-3114 based cards. That's a fairly old chip that doesn't support port multipliers, but does support hot swapping. The last card I bought with this chip was: http://www.amazon.com/Vantec-6-Port-SATA-Host-Card/dp/B002PX9BX2/ As I mentioned, using a 2-slot drive dock may also be adding a layer of complication, as such a dock with have a port multiplier chip. A single slot eSATA dock is essentially a passive mechanical connector from the SATA bus perspective. Also, "David Clayton reminds us that AHCI must be enabled for SATA hotplugging to function." (http://tinyapps.org/docs/wipe_drives_hdparm.html) You mentioned killing a drive due to removing it while spinning. Was that just a result in not waiting enough time for the drive to spin down? Hot swap doesn't mean you should be disconnecting the drive while powered, though electrically it should handle that fine. (I'm pretty sure, like USB, the SATA power connections are designed to withstand that.) A month or two ago I ran across some product announcement articles talking about new development boards using the Freescale i.MX ARM CPU, and interestingly they noted that despite there being a SATA port on the board, it was non-functional. http://www.cnx-software.com/2012/10/07/69-89-wandboard-freescale-i-mx6-solo-and-dual-development-boards/ There are not so many boards with native SATA support, so for those of you who need SATA this could be really be a good option. [Update: Although there's a SATA connector on the baseboard, this is not supported by the Solo and Dual modules, so it's just there for future modules. See forums] http://www.cnx-software.com/2013/02/21/wandboard-dual-unboxing-and-quick-start-guide/ A SATA connector is included but none of the Freescale SoM (Solo and Duallite) provided with the Wandboard can support it. Not clear whether this is true of all Freescale i.MX boards, or just the subset of CPUs that can be ordered on this particular development board. Seems rather strange that the vendor would include all the hardware for SATA on the board, and Freescale seems to claim to include SATA in its i.MX family, yet something is missing. Regarding your erasure verification: if you wanted to spot check that dd or the ATA secure erase was successful, you could start by writing predictable data to the drive, such as the sector number to every 1000th sector, or some such, and then confirm you only get zeros when reading back after the erasure. Regarding monitoring progress of dd: Why bother going through the extra steps to enable progress reporting with dd, if you have ddrescue available, which provides reporting via a simple command line switch, and I suspect has a better output format for parsing. If you did need to limit yourself to dd, another approach would be to sample and extrapolate. Have dd write 1000 sectors, time it, and calculate the expected run time. Chances are you'll be as accurate as the estimate the firmware reports for a secure erase. Your talk didn't mention DBAN (http://www.dban.org/). I don't think it would buy you anything over dd, but for completeness you might want to mention it and explain why you aren't using it. In addition to the suggestion to print a barcode of the drive's serial number on the label for post-erasure asset tracking, your erasure appliance should also include some UI to display the serial number (and as much other identification formation, like drive model, size, partition labels and types, and found file systems) for the user to confirm they are erasing the drive they intended to erase. Regarding the bricked drive, I see: https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase If you hit kernel or firmware bugs (which are plenty with not widely-tested features such as ATA Secure Erase) this procedure might render the drive unusable or crash the computer it's running on. When I tried [the SECURITY-ERASE command] on the...drive through a USB adapter, it let me password protect the drive, but would not accept the SECURITY-ERASE command. I shut down the system, reconnected the drive to the SATA controller, and found that the drive was bricked - BIOS couldn't recognize it. I will update this warning if I find a way to un-brick the drive. Also a discussion thread here: http://forums.partedmagic.com/viewtopic.php?f=5&t=4668 but it links to info on fixing a locked drive, and I don't think you ended up with a locked drive. But these two sources confirm that a failure secure erase can lead to a bricked drive. Probably your best option is to try and reflash the firmware, but if the drive doesn't respond enough to return its model number, that's unlikely to work either. Several of the pages note that older versions of hdparm will timeout if the erasure takes too long. You'd think that would be inconsequential (the drive would keep on going), but this page notes: http://tinyapps.org/docs/wipe_drives_hdparm.html Boot from...any distro which includes hdparm 9.31 or greater (prior versions would timeout after 2 hours, leaving the disk only partially erased) This suggests that when hdparm times out, it must reset the ATA bus or do something similar that the drive's firmware listens to and aborts the erasure. I'm sure the effect varies depending on the drive manufacturer. That page also explains the difference between security-erase and security-erase-enhanced: Secure erase overwrites all user data areas with binary zeroes. Enhanced secure erase writes predetermined data patterns (set by the manufacturer) to all user data areas, including sectors that are no longer in use due to reallocation. I thought overwriting reallocated sectors was the whole point to using secure erase. This definition makes the basic erase sound no better than a dd overwrite, which is inconsistent with what is documented elsewhere, including on this same page. Elsewhere it quotes Mark Lord, hdparm's author: The answer is manufacturer-specific, and only manufacturers know the exact details. However, the idea is that the SECURITY ERASE command (which is handled totally by the drive firmware itself, not Linux) is supposed to erase everything possible inside the drive. Including HPA [host protected area], DCO [device configuration overlay], spare sectors, all drive firmware settings, etc. Think of it as the modern-day "low-level format" command. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
