Filter
Top Products
5.5.5.3 Spin locks
Spin locks provide an additional synchronization primitive for applications running on SMP systems. A spin
lock is just a simple flag. When a kernel control path tries to claim a spin lock, it first checks whether or not
the flag is already set. If not, then the flag is set, and the operation succeeds immediately. If it is not possible
to claim a spin lock, then the current thread spins in a tight loop, repeatedly checking the flag until it is clear.
The spinning prevents more than one thread of execution from entering the critical region at any one time.
5.5.5.4 Kernel semaphores
A kernel semaphore is also a simple flag. If a kernel control path can acquire the semaphore, because the flag
is not set, it proceeds with its normal operation. Otherwise, the corresponding process is suspended. It
becomes runnable again once the semaphore is available. Semaphores are used to protect critical regions of
code or data structures that allow just one process at a time to access critical regions of code and data; all
other processes wishing to access this resource will be made to wait until it becomes free. The Linux kernel
from version 2.6 provides mutex abstraction layer. For additional information on kernel mutexes, please see
“Mutex Conundrum in the Linux Kernel,” http://developer.osdl.org/dev/mutexes/docs/MutexSIG.pdf.
5.6 Audit subsystem
An auditing facility records information about actions that may affect the security of a computer system. In
particular, an auditing facility records any action by any user that may represent a breach of system security.
For each action, the auditing facility records enough information about those actions to verify the following:
• the user who performed the action
• the kernel object on which the action was performed
• the exact date and time it was performed
• the success or failure of the action
• the identity of the object involved
The TOE includes a comprehensive audit framework called Linux Audit Framework (LAF), which is
composed of user-space and kernel-space components. The framework records security events in the form of
an audit trail and provides tools to an administrative user to configure the subsystem and search for particular
audit records, providing the administrator with the ability to identify attempted and realized violations of the
system’s security policy.
This section describes the design and operation at a high level.
5.6.1 Audit components
Figure 5-69 illustrates the various components that make up the audit framework and how they interact with
each other. In general, there are user-space components and kernel-space components that use a netlink
socket for communication. Whenever a security event of interest occurs, the kernel queues a record
describing the event and its result to the netlink socket. If listening to the netlink, the audit daemon, auditd,
reads the record and writes it to the audit log.
This section describes the various components of the audit subsystem, starting with the kernel components
and then followed by the user-level components.
131