Below, I outline a potential "solution" on how to secure a CF card. This is all theory, none of it has been tested (yet). I'd like the theory to be sound before I go any further. It's a strawman, go nuts. Please pay particular attention to the ISSUES section.
Thanks, John Request For Comment ------------------- PREAMBLE. The CompactFlash specification includes a mode where a CF card may emulate an IDE device. With an appropriate adapter, a CF card may be attached to an IDE channel. As a solid-state device with no moving parts, if the host is careful about limiting writes to the card, they should last for quite a long time. The LEAF project distributions use pesistant storage for initialization only. They load their various components from the media into a ram disk and then dismount the media. The only writes that occur is when an administrator needs to change the configuration or add a new package. (mount-write- dismount) Today, floppy disks are the preferable media to CF cards for 'secured' LEAF boxes because 'hardware' write protection is generally available via the floppy's write protect tab. Floppy disks have a few drawbacks: slow, prone to dust, and space limited. The surface will deteriorate over time and the transport can fall out of alignment. Some CF manufacturers have been approached to add a "write protect" feature. There was a little interest from one (two?) but no product is yet available. Even if produced, as a specialty item, they may not be cost-effective. An IDE interface has a WE (Write Enable) line. This line controls all data flowing to the device including read commands. Setting this line to a disabled state makes the attached device inaccessible to the host. This can be a very secure state. Unfortunately, it is so secure that on an unexpected reboot (eg: power-failure) the box cannot get to its media to reinitialize or even boot! PROPOSAL. A circuit designed to disable the WE line via a logic level from the host but pass thru the host signal after a power-on or a reboot. Requirements. - WE states: disabled, pass-thru - simple state machine (one JK or RS flip-flop) - power-on-reset (RC timing ckt) - manual reset (pushbutton, [opt]watchdog, [opt]secured console, etc.) PRELIMINARY DESIGN. [assumption: WE is active high, which sounds wrong...] Insert an AND gate on the WE line between the host and the device with the host output entering one of the two AND inputs and AND's output entering the device's WE input. The control signal is the other AND's input. When low, the output of the AND is always low regardless of the host's signal level. When high, the AND's output follows the host's signal. If the above assumption is wrong, replace the AND with an OR gate and invert the behavior of the control signal (high disables, low follows). Driving the gate's control signal is a two input non-clocked flip-flop. Flip-flops are basically single bit static RAM. Typical flip-flops have both the current state and its inverse available as output. The two inputs are set and reset, so no debounce should be necessary on the pushbutton. Multiple resets can be N-way gated together (AND/OR, depends on the signal needs of the input). Any reset signal will change the state of the flip-flop to put the control gate into the WE pass-thru state. An output logic signal from the host will change the state of the flip-flop to put the control gate into the WE disabled state. Potential signal source: parallel port data or control or serial port control (with level shifter). FEATURES. - Host cannot reenable the media without at least a hard reset (see notes about sleep states). - The device can be reenabled remotely via an external logic level. - Possible single IC implementation :) OPTIONS. - Manual drop request. (Safe drop, wait until device is synced) - Manual drop immediate. (Un-safe drop, chances are buffers are dirty) ISSUES. - Reboot detection may be HARD. May need access to the RESET* signal. - Sleep states may remove power from some interfaces! Most boards' Wake-on-Lan connectors have an active power line thru all states. - Care must be taken that the host signal NOT disable the ckt on powerup. (BIOS hardware checking, stray signal, etc.) - Can the WE line withstand an extra one gate delay? (10ns?) - Corruption has been reported on a manually toggled WE line. (URL) The test configuration is unclear. Was the line toggled on a still mounted device? If so, there's a very real chance that there were still some write buffers to be flushed. - Beyond corruption, would 'hiding' the device confuse the kernel? The 2.6 kernel should be much improved w.r.t 'removeable' IDE devices, but that's a long way off. Some support exists for rescaning the IDE bus. (URL) - For more elabroate control, a uC (eg. PIC) could be used instead of the flip-flop. - ??? ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf _______________________________________________ Leaf-hardware mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-hardware
