[cap-talk] KeyKOS kernel safety

[Charles Landau]

This question is directed at the KeyKOS folks who have a better memory than I.

In KeyKOS there was a page range designated as the kernel range. The 
boot code loaded the range without consulting checkpoint data. To 
update the kernel, you could write data to these pages, wait for it 
to be migrated from the checkpoint area to the home range, and reboot 
the system.

KeyKOS was designed to maintain a safe working state if the system 
crashed and rebooted at any instant. My question is, what if the 
system crashed during the write or migration of the kernel range?

My recollection is that the design, if not the implementation, called 
for two kernel ranges, a primary and a backup. If the primary failed 
to boot, the secondary was booted. You would update and test one 
before updating the other.

(To be safe, you would have to first write the first page of the 
primary kernel with code that reliably fails. At the instant that 
page is migrated, any reboot will reliably go to the secondary 
kernel. Then write the other pages of the new primary kernel, and 
wait for them to be migrated. Then write a good first page; at the 
instant that page is migrated, the new kernel is bootable.)

Is this recollection correct, or was there another design? In CapROS 
this issue applies both to the kernel and to the user-mode disk 
driver, because at boot time they are both loaded without regard to 
checkpoint data.