Filter
Top Products
This tool works from a premise that it is working on an abstract machine that is providing functionality to the
TSF. The test tool runs on all hardware architectures that are targets of evaluation and reports problems with
any underlying functionalities. For more detailed information on the Abstract Machine Test, refer to Emily
Ratliff, “Abstract Machine Testing: Requirements and Design.” The AMTU test tool performs detailed in the
subsections that follow.
5.13.5.1.1 Memory
AMTU allocates 10% of the physical memory of the system (not exceeding 1 GB on 32 bit machines), and
then writes a pattern of random bytes. The tool reads back the memory and ensures that what was read
matches what was written. If they do not match, the tool reports a memory failure.
5.13.5.1.2 Memory separation
To fulfill the memory separation requirement, AMTU performs the following: As a normal user, the tool
picks random areas of memory in ranges reported in /proc/ksyms to ensure that user-space programs
cannot read from, and write to, areas of memory utilized by such things as Video RAM and kernel code. The
tool reports a failure if any of the above attempts succeed.
5.13.5.1.3 I/O controller and network
Because portions of the TSF depend on the reliability of the network devices and the disk controllers, AMTU
also checks I/O devices. This section describes how the network devices are tested.
When the kernel detects an attempt to open a network connection to an address that is configured on the local
machine, the kernel short-circuits the packets rather than sending them to the physical device. To evade this
optimization without requiring a remote server, the tool specifies the PF_PACKET communication domain
(see packet (7)) when opening the socket. AMTU performs the following:
1. Using the PF_PACKET communication domain, opens another connection to the listening server and
2. Ensures that the random data transmitted is also the data received. Steps 1 and 2 are repeated for each
configured network device.
5.13.5.1.4 I/O controller and disk
In order to check the disk controllers (IDE and SCSI only), AMTU opens a file on each read-write mounted
file-system, writes a 10 MB random string, syncs the file and directory, closes the file, re-opens the file, and
reads it to validate that the string is unchanged. The 10 MB string size is chosen so that the file exceeds the
size of the device's buffer. AMTU prints a warning to the administrator if it has determined that a disk
controller (IDE only) was not tested, unless that disk controller is dedicated to floppy and cdrom devices.
This might happen if a disk controller only controls read-only file systems. More than one test is performed
on disk controllers that control more than one r/w file system.
5.13.5.1.5 Supervisor mode instructions
Certain instructions are only available in supervisor mode. The kernel has the ability to switch to supervisor
mode to use the instructions, but user space tools should not be able to use these instructions. A subset of
these privileged instructions are tested to confirm that is true.
The list of instructions that are available only in supervisor mode is architecture dependent. The subset of the
privileged instructions that are tested per platform is listed below. In addition, to generically test that
privileged instructions cannot be executed while not in supervisor mode, the test ensures that the CPU control
registers, task registers, and interrupt descriptor tables cannot be changed while not in supervisor mode.
Supervisor instructions available for each of the architecture are described in subsections below.
204