Verifying PROM'ed systems by checksums

Product Family: DACS
Target CPU: 80x86
Language: Ada
Host: Any

General:
The following outlines how use of checksums may be used to establish system consistency, and how DDC-I software can help in this respect.

The discussion applies to 32 bit variants of DACS-80x86, that is for i386, i486 and Pentium.

Checksums - why and how
In order to verify the correctness and validity of systems, it may be necessary to apply some forms of checks. This is true regardless of the medium that holds the binary code and constants, whether it is a disc, RAM, PROM or some other form of memory.

If e.g. the PROM is damaged there is a good chance that the program will not start up due to damaged system tables - you will know that something is wrong. However, there may be isolated bit errors at odd locations which still would allow the system to start-up, but then fail down the road.

Adding checksums allows you to include a positive verification. There is also the aspect of version control - does the system really consist of that particular build? Well, if you record the checksum information, there will be no doubt.

To this end the DACS-80x86 target linker includes a capability to generate individual checksums for each segment. DACS never relies on initialized memory, so only constant- and code-segments need consideration.

It is worth noting, that the target linker can be instructed to include a complete binary file as raw data with a segment name (the RAW directive), so that application dependent constant data may be not only added at link time, but also subjected to checksum control, similar to the constant- and code-segments The RAW directive creates a segment with a specified name, and with the contents from a specified host file on the host system.

The technique used by the target linker for handling checksums, is to create an additional (special) segment called LCI (load control information), which is placed last in the LDT (local descriptor table). The LCI contains checksums and other information for the segments. Since this special LCI segment is initialized by the linker, it is also itself being subjected to the checksum'ing. It can be thought of as a checksum on all the other checksums. The entries in the LCI segment refer to segments in either the GDT or the LDT tables, and some of these LCI entries denote a checksum value, which should match the value you would get, if you added all the DWORDs of the segment.

Checksums at Run-Time
If the target linker has been instructed to create the LCI segment, the application can verify the checksums at run-time. In order to do this the application needs a way to address the memory in question. The system tables GDT, IDT and LDT are readily readable, but others such as the TSS and LCI are not. However from LDT and GDT the base addresses of all other segments as well as their sizes can be obtained. In flat mode systems this is sufficient to read any segment's DWORDs, but in protected mode the user must provide an "all" segment that covers the memory from physical zero to top of physical memory to allow the checksum'ing. When run under debugger control, the debugger has created such a segment, which can be searched for and reused, but otherwise a target linker directive must be added to the build configuration file that adds such a segment to either the GDT or the LDT (a target linker DAT directive can be used, with the OVERLAP keyword). Please note that the debug monitors do not accept to load programs for debugging that have such (overlapping) all segments, and that such a DAT directive should only be used, when target linking for PROM.

Once such an all segment in protected mode has been established, or always in flat mode, the LCI segment entries may be scanned for checksum information and each checksum entry verified against the actual PROM'ed data. For most segments this does not pose any problems, but the system segments typically change, when code is executing. Again there are several models: the system tables may be residing in PROM, in which case they can not change, or they may be loaded from a floppy disk or solid state 'disks', in which case they are alterable. A GDT or LDT entry typically changes, when the segment it corresponds to is accessed. The target linker can be instructed to set this 'accessed' bit at link time to reduce the GDT/LDT changes (option PREACCESS), but this can not be extended to the TSS segment entry, so this will invariably be one bit off (though it can be accounted for). The contents of the TSS segment itself is also bound to change, because registers are recorded in the segment during start up - this may also be compensated to some extent. Finally, having breakpoints set in the code (when debugging) also changes the checksums for those code segments, where breakpoints have been set.

DDC-I package available
DDC-I has developed a package that allows for checksum'ing of segments in a program that is loaded using the DDCILOAD method (loading from floppy or solid state disk, as is common on PC bare systems). A simple interface allows the caller to verify that all segments are consistent, and that those that are not, are those expected to deviate. Please contact DDC-I for more information about this package.

Other applications typically start up by copying themselves from PROM to RAM, and setting up new GDT, LDT, IDT or TSS tables. In such a case checksum code should attempt to use the original versions of the tables, since these are exactly what the LCI describes. Accessing the original tables require just getting to the original GDT, and DDC-I can help provide a method to do this, once the used load method is known.

Verification of the physical destination RAM should be tested by power-up self tests, so this is not an issue when looking at the checksums, but of course the purpose could be to verify exactly the code and constant segments that are actually executed or read, so a 'hybrid' that checks the system segments from their original locations in PROM and the other segments from their RAM copies could be desirable. Again DDC-I can help setting up such a scheme.

Conclusion:
Including system checksum information increases the system reliability and aids in keeping track of versions; this all saves valuable time as problems are detected early. Please contact DDC-I if you are interested.