dav@genisco.uucp (David L. Markowitz) (10/28/89)
I have a strange problem: for reasons too horrible to repeat here, I have been requested to implement a panic button on a Sun system which, when pushed, will caused the (embedded SCSI) disk to be reformatted completely (note: not overwritten, it MUST be reformatted). It would be nice to erase RAM, too, but let's not get greedy. I have a wide variety of choices on how to implement such a beast. The ones I have considered include: 1. The button triggers a bit on a VME board which is either periodically polled, or causes an interrupt, to a daemon which then reformats the disk. (I already have this board - that part is easy). This will be harder on non-VME Suns, but that's another problem. a. This daemon must be static and locked in RAM, to avoid it dieing when its swap or image are erased. I don't know to keep the OS from dying, though. Or, b. The daemon does an ioctl() to the board's driver, which (as a piece of kernel) raises spl all the way up and shoves the format commands down to the disk. (I don't think the SCSI command set includes one to "format the whole thing and ignore me until done", does it?) 2. The button triggers a piece of hardware attached to the SCSI bus which sends the appropriate SCSI commands down the bus. I guess it should never "Disconnect", or something like that (I'm no SCSI expert). Solutions based on #1 (primarily software) are cheaper, but less reliable (OS down, CPU overheated, fragged, etc). Solutions based on #2 (hardware) are more expensive, take more room and power, and generate more heat. Of course this box could fail, too. Have I missed any solutions? Does anyone have something like this in place? Please mail ideas. I will summarize if there is any interest. David L. Markowitz Genisco Technology Corporation dav@genisco -- David L. Markowitz Genisco Technology Corporation dav@genisco
rayan@cs.toronto.edu (Rayan Zachariassen) (10/29/89)
It sounds like the best (and most appropriate) solution in this case is to get some explosive (or gun, mortar, 1-ton weight, etc.), isolate the disk appropriately (so the human next to it won't get harmed), and have the panic button trigger the destruction of the disk. Assuming this is not a gotta-hide-the-game-playing-from-the-boss application, destroying the disk is probably an acceptable price to pay for 100% data security, not to mention the instant feedback (gratification). The only drawback is the cost of stress-testing this hack. rayan, Creative Solutions Department ps: remember that formatting a disk takes a non-trivial amount of time, on the order of minutes, which will allow "the enemy" to turn off power to the disk, thus salvaging all the data on it that hadn't already been destroyed by the formatting operation. Hence my suggestion is the only method guaranteed to work if you have to guard against a hostile hacker force breaking down the door. pps: Hmm, who needs nroff...
bzs@world.std.com (Barry Shein) (10/30/89)
>Have I missed any solutions? Does anyone have something like this >in place? Please mail ideas. I will summarize if there is any >interest. > > David L. Markowitz Such things do exist in high-security applications. Why not degauss the sucker? A suitable degausser could probably be put right into the shoebox/rack. It wouldn't be immediately reusable I don't think but it should be completely recoverable, probably after a brief trip back to the manufacturer. Maybe it can be reformatted later, I'm just not certain. At least this would work in a fraction of a second and can be made complete and certain. The downside is it would also erase any magnetic media within a certain (calculable) distance of the degausser and possible other side effects tho all pretty predictable and probably not hard to prepare for (keep magnetic media out of the area that you don't want degaussed or set up shielding.) -- -Barry Shein Software Tool & Die, Purveyors to the Trade | bzs@world.std.com 1330 Beacon St, Brookline, MA 02146, (617) 739-0202 | {xylogics,uunet}world!bzs
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/30/89)
Given that the only uses I can think of for this might not wait for the hours that a low level format might take, I suggest a suitable enclosure and erasure via a large magnet for a few seconds followed by a touch of thermite. End of serious suggestion. Begin humor. If you want to be sure, an EMP is the fastest way to scramble the bits. A small (2-3 kiloton) device would provide the EMP and mechanical reformatting as well. Be sure the enclosure is sturdy. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
brian@ucsd.Edu (Brian Kantor) (10/31/89)
Degaussing works, but on most larger drives will mean a trip back to the repair depot unless you have tools to rewrite the servo tracks, which is NOT the same as reformatting the drive. How about thermite? After all, if they're coming to get you, you'll have a much more enjoyable time watching their faces as the data they so eagerly wanted slumps into a puddle right in front of them.... ` - Brian
berry@lll-crg.llnl.gov (Berry Kercheval) (10/31/89)
In article <1989Oct29.232707.4810@world.std.com> bzs@world.std.com (Barry Shein) writes: >>Have I missed any solutions? Does anyone have something like this >>in place? Please mail ideas. I will summarize if there is any >>interest. >Why not degauss the sucker? A suitable degausser could probably be put >right into the shoebox/rack. It wouldn't be immediately reusable I >don't think but it should be completely recoverable, probably after a >brief trip back to the manufacturer. Maybe it can be reformatted >later, I'm just not certain. Well, here at LLNL, degaussing magnetic media is NOT considered adequate to declassify magnetic media. Degaussed media can be reused in other classified projects, but to be discarded must be physically destroyed. You'd be amazed at what the sooks can get out of an allegedly blank disk... -- bERRY Kercheval :: berry@lll-crg.llnl.gov