[PLUG-TALK] Hostile Hard Drives

[Larry Brigman]

On Fri, Feb 18, 2011 at 9:08 AM, Keith Lofstrom <keithl at kl-ic.com> wrote:
> I am posting this to plug talk, but many of the issues involved
> are Linux issues.  If some of this spills over into Linux
> implementation, please address those issues on the main list,
> so we can engage more technical minds.
>
>
> Wednesday night I attended an IEEE Management Society Chapter
> meeting, where Noah Murphy of ClearAccess talked about nasties
> on the net.  He mentioned ClearAccess equipment, manufactured
> in China, getting reflashed in the US as the last manufacturing
> step, to prevent malware insertion in China.
>
> It got me thinking - and sometimes that leads to nightmares.
>
> My laptop runs open source software.  And closed source hardware.
> And closed source firmware.  The biggest chunk of closed source
> firmware is not the wireless, and not the BIOS, but the hard disk.
>
> The hard disk does some rather heavy error detection and
> correction, at many levels, from correcting read errors on the
> fly (using Vitterbi coding, the "errors" are much of the disk
> signal) to repairing and replacing bad sectors, to remapping
> platter information from physical location to C/H/S, to
> calibrating head movement, to who knows what else.
>
> The "what else" was the nightmare that woke me up this morning.
> (oh, why can't I have normal nightmares about flesh-eating zombies?)
>
> I assume most of the firmware for the hard drive itself is stored
> on the platter,  with some kind of boot loader in ROM.  American
> engineers working at Western Digital or Seagate no doubt have a
> way to ask the hard drive to spill its guts, emitting "the ROM
> firmware" and "the disk firmware" (probably multiple copies).
>
> But unless the engineer is actually looking at the raw read signals
> from the head (difficult to do, much of the signal handling is done
> by a chip on the head itself) then how the hell does the engineer
> know that the response to the "dump your guts" commands is the
> actual firmware currently executing, as opposed to non-executing
> code that the real firmware wants the engineer, and the rest of
> us, to see?
>

There was something similar a while back that replaced the firmware on
Intel E100 cards.  It used pci bus master to transfer packets between two cards
without the OS being involved.

The engineers of drives now have probe cards that can actually get at
the signals out of the read channel
and also read the digital stream direct from the DSP.

You can be paranoid but the disk drive is probably not the place that
you should be protecting your self except
when you are getting rid of the device.  There are plenty of other
(easier) ways.