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.1Memory

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.2Memory 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.3I/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.4I/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.5Supervisor 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

Page 216
Image 216
IBM 10 SP1 EAL4 manual Memory separation, 13.5.1.3 I/O controller and network, 13.5.1.4 I/O controller and disk