DOD Erase pattern on Alpha VMS

[Ian Miller.]

On VAX VMS in SYS$EXAMPES:DOD_ERAPAT.MAR is example code to modify the erase pattern used by INIT/ERASE and DEL/ERASE to the DOD one. Has anyone got this to work on VMS Alpha (V7.3-1 ideally)?

[John Gillings]

Ian,

I haven't got the VAX example to work, but I could send you the source for the Alpha version of the loadable system service. Interesting example - the LINK options file contains more lines than the MACRO32 code!

Send me mail if you're interested.

(on the other hand, some judicious PATCHing of the exec image, or run time memory might be quicker and simpler)

[Cass Witkowski · Accepted solution]

Try looking at analyze/media/exercise

[Ian Miller.]

John, I will be in touch. I know what you mean about the link options file having recently done a loadable execlet myself.

Cass - ANALYZE/MEDIA/EXERCISE=FULL
looks to me like it does the correct thing i.e. writes all 0, all 1 and a worse case pattern (whatever that is) - this sounds similar to the three passes of the DOD_ERAPAT code (based on a quick review of the code anyway).

For future reference see
http://h71000.www7.hp.com/doc/73final/documentation/pdf/OVMS_BAD_BLK_UTIL.pdf

[Cass Witkowski]

You can also specify a pattern and if need be run this multiple times to meet higher security requirements.

Does anyone know if this exercise existing bad blocks or all areas on the disks that data could be written to?

[John Gillings]

Cass,

>Does anyone know if this exercise
>existing bad blocks or all areas
>on the disks that data could be
>written to?

That depends on "who" deals with the bad blocks. Some controllers handle so the quarrantined blocks are inaccessible from the operating system. In those cases ANALYZE/MEDIA can't touch them.

If the bad blocks are dealt with by the operating system, when detected they are allocated to the system file BADBLK.SYS. Since they're allocated, they can't be used by other files, but they're still accessible. ANALYZE/MEDIA could exercise them (that's assuming it doesn't have special case code to skip that file).

[Richard W Hunt]

Please be aware that DOD-class erasure is an interesting problem in not only what you write BUT also the level to which you have to certify the erasure. I'm at a Navy site so I have run afoul of this exact problem.

If you are merely erasing a disk that will stay in the machine and your site security policy allows it, you are actually not required to erase anything. Just set the volume to high-watermarking. (You DO need to control who has LOG_IO and PHY_IO.)

If you are erasing a disk that is to be removed from the machine, if it is UNCLASS, you still don't need to do anything except a simple erasure. Only if your machine is classified SBU / FOUO or higher do you need to worry about true erasure.

In THAT case, unless you have submitted the erasure program to one of the certification agencies, it is not a "legal" erasure anyway. Unless you have a certified program, the ONLY legal methods of erasing a removed disk are to destroy it. We have a stockroom full of disks waiting for the arrival of a degausser that works through metal disk shells. If that doesn't show up soon, our eventual alternative will be a 16-pound sledgehammer and we'll probably give everyone three hits for a dollar.

Of course, if you are replacing a disk 'cause it failed, your ONLY recourses are degaussers and sledgehammers. We had to get a special clause in our service contract to allow for destruction of disks because our nearest parts depot won't certify that they degaussed the disk. If you were working on DOD machines, you know you ain't finished 'til the paper work is done, and if you can't get it certified as erased, it ain't erased.

Now, as to what it actually takes.... The old method of writing all 1, all 0, alternating 1/0 and then 0/1 ... all fail if you have a disk that uses RLL2 encoding schemes. (RLL = run length limited, a form of compression.) These days, RLL or RLL2 is pretty common. Higher versions are also possible. Writing a pattern of all 1 or all 0 just sets or clears about 1 byte. Someone could then run a diagnostic read to see the remaining data anyway. If you are using RLL2 encoded disks, you need to write buffers full of patterns such as

0x924964 or 0x6DB6DB

which are non-repeating bit streams just long enough to thwart the encoding and compression scheme. You could also try to generate a buffer of random bytes using a random number generator, which will also defeat RLL encoders.

But like I said, this all depends on whether you need the erasure certified. If you do, you need to get the erase program certified. Otherwise it will not count.