Kernel-based checkpoint and restart

I work for Bull Worldwide Information Systems on the GCOS 8 virtual operating system. The virtual version was originally developed by Honeywell in the early 1980s. I wrote the original specification for the virtual program checkpoint - restart facility. We use a kernel based approach and wanted to include references to communication stacks and database buffer pools whose structures were maintained in secure, shared memory.

Early in the design phase I concluded that allowing a user to access the content of the checkpoint image would make security hopeless. Therefore, in support of our virtual checkpoint, we built a checkpoint database. Unprivileged users could ask the kernel to produce a checkpoint image to be created on the database. The user could refer to the last checkpoint image, by default. They could also refer to prior checkpoint images produced by their userid by date-time stamps.

When the kernel is requested to perform a restart, the primary checks are to assure that the userid matches, the requesting process is appropriate, and that the software installed at the time of the checkpoint matches the software currently installed. Since the user is NEVER allowed direct access to the checkpoint image content, there is no concern that the image has been manipulated. This prevents unnecessary errors and security breaches.

As an aside, we defined callbacks to the software maintaining data structures in shared memory areas. At checkpoint time, all data files were closed. They were reopened after the checkpoint or restart. This caused all pointers to shared memory areas to be reestablished. This also allowed dynamic entities, like dynamic shared buffer pools, to be rebuilt.