Re: Write-protect sctors?

Florian Specker wrote:
> did you consider the possibility that the bad sector was not caused by
> the rootkit? It's not uncommon that a disc contains bad sectors, which
> you only remark when you actually read such a sector (or the whole disc,
> e.g. dd it to another disc).

Bad blocks are detected on reads, but only remapped on write (and only 
then if the write initially fails).

If a write failure is passed through to the OS, then the disc has run 
out of 'spare' reserved blocks for remapping, and the drive should be 
retired immediately (the S.M.A.R.T. metrics should reflect this fact).

If, however, the drive passes through a _read_ error to the OS, it's 
possible (highly likely, even) to put things right by writing to that 
block (e.g. running badblocks in write-test mode, using a sector editor, 
dd'ing the entire drive or partition, or deleting the file that occupies 
the block in question, then immediately filling the filesystem with a 
dummy file). If the block is able to be remapped, then it *is* safe to 
use. If anyone's throwing away drives on the first read error, then I'll 
be happy to receive them, test them and use them for a few more years. I 
have personally forced drives to remap failed blocks using the 
techniques described above, and the discs are still reliable years 
later. :-)

As an aside, I run badblocks in write-test mode before partitioning and 
formatting in order to a) give the discs a soak test and b) attempt to 
force marginal blocks to be remapped /before/ they're storing real data.

> Try to low-level format the disc after investigating the incident.

Modern discs should not, and indeed, cannot be low-level formatted. The 
best you can do is 'dd if=/dev/zero ...' them, or issue an ATA/SCSI 
FORMAT_UNIT command.

> Another possibility is some SMART-related function, but that is pure
> speculation, as I don't know too much about these features.

Some of the S.M.A.R.T. metrics may only be valid if you regularly run 
the S.M.A.R.T. self-tests.

Finally, once Linux is running, the BIOS cannot write-protect blocks.

> Cheers & good luck cleaning up,
> Florian

Best Regards,
Alex.
-- 
Alex Butcher: Security & Integrity, Personal Computer Systems Group
Information Systems and Computing             GPG Key ID: F9B27DC9
GPG Fingerprint: D62A DD83 A0B8 D174 49C4 2849 832D 6C72 F9B2 7DC9