HP OpenVMS Systems

ask the wizard
Content starts here

Secure Disk Media Erasure? (Data Remanence)

» close window

The Question is:

The company I worked for would like to erase the operating system on our vax
 6100 ver 5.5.
Can this be accomplished without booting from an external peripheral,such as a
 tape drive.
How about booting to the sys$boot>>> prompt to erase the system drive. And if
 so, How can it be done. Have a beautiful day.

The Answer is :

  Various intelligent storage controllers can potentially contain
  erasure capabilities, as can the diagnostics available on a few
  system consoles, and these may or may not meet local data security
  requirements -- some sites require pattern-based erasures, and will
  sometimes require rather more stringent procedures to avoid the
  unintended release of data.  (Integrated media self-destruct
  mechanisms are one obvious and specialized area of the storage
  media market.)
  For a simple host-based erasure, you will have to perform a bootstrap
  of diagnostic software, or a bootstrap of OpenVMS itself from a
  bootable device (other than from a disk targeted for erasure), or
  (if the particular system supports it) a console disk initialization
  diagnostic, or (if available) from a bootable media diagnostic tool.
  Your suggestion of incorporating at least some basic disk erasure
  capabilities into the SYSBOOT utility or into an alternate secondary
  bootstrap is an interesting one, but such support is not currently
  available.  And such host-based erasure support may or may not suffice
  for site-specific requirements, given particular features of modern
  storage media and controllers.
  As one complication to media erasure, both MSCP and SCSI disks support
  a process known as bad block revectoring.  This is a process by which
  the host or even the device can detect a bad block, and can replace it
  with a spare block -- devices with this support will contain a
  device-specific number of extra blocks that are effectively hidden
  from the host, and these blocks can be used to replace bad physical
  blocks found in the host-accessable portion of the media.  The host
  thus references all blocks using logical access, and never sees that
  its I/O references can be redirected away from any underlying bad
  physical blocks found on the media.  There is presently no standard
  way to access the entire range of blocks present on a physical SCSI
  disk, and no certain way to overwrite the contents of these bad blocks.
  (With MSCP disks, access to the replacement caching table (RCT) is
  Because of the bad block revectoring, secure media erasure usually
  involves degaussing (above the required magnetic coorcivity for the
  media; applying a magnetic field in excess of the media-specific
  Oersted rating) and then potentially grinding and "slagging" the media.
  This mechanical destruction to avoid releasing information stored in
  one of these revectored bad blocks -- these (bad) blocks are potentially
  still readable, given appropriate access to the media.  (Though RCT
  access is permitted on MSCP media, reliable write access to the
  revectored (bad) blocks is rather obviously an activity that is likely
  to be generally somewhat less than successful.)
  In addition to the potential to access the contents of blocks marked
  as bad, it is also potentially feasible to read the contents of an
  erased block by aligning more sensitive read heads slightly off the
  track location, and reading any magnetic "splatter" that was not
  completely overwritten by a pattern erasure -- this is one of the
  reasons that sites concerned about data remanence can require multiple
  media erasure passes, each often using a different bit pattern.
  And quite obviously, not all customers have the same level of concern
  over the release of the contents of the media -- something like the
  provided $ERAPAT erasure mechanism and the INITIALIZE/ERASE command
  can suffice for certain customers.
  Related discussions include (841), (3926), (4286), (4598), (7320).
  Topics specific to unintential initialization or the overwriting of
  disk and tape media include (1286) and (6990).
  For errors resulting from file structure, directory structure, or
  file structure corruptions, please see topics such as (1213), (4088),
  (4571), (5071), (5553), (5719), (6021), (6234).
  Disk bad block handling is discussed in topic (6926).

answer written or last revised on ( 24-JUN-2002 )

» close window