Table of Contents
Contents
Copyright
Copyright © 2005-2008 by The Linux Foundation, Inc. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is available athttp://www.opencontent.org/opl.shtml/).
Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder. Other company, product, or servic e names may be the trademarks of others.
Linux is a Registered Trademark of Linus Torvalds.
Introduction
Document Organization
Unsatisfied "Gap" Requirements
Availability Gaps
AVL.3.2 Forced Un-mount
Priority: P1
Description: CGL specifies that carrier grade Linux shall provide support for forced unmounting of a file system even if there are open file descriptors and/or applications actively using it. Pending read or write requests shall either be terminated immediately with an appropriate return value or, where necessary, will be invalidated and when possible return an appropriate error value. Requests issued after the unmount shall fail using the usual mechanisms for non-existent / unmounted filesystems. New requests issued against file descriptors held on the unmounted filesystem will be treated as any invalid file descriptor.
AVL.3.3 Forced Un-mount Application Notification
Priority: P3
Description: CGL specifies that carrier grade Linux shall provide a mechanism must be provided that will allow applications that are using the filesystem to be notified that it is being forcibly unmounted other than via normal filesystem operations failing.
AVL.28.0 Support of Mlocked Page Limits
Action: Rewrite using new gaps template.
Priority: P3
Description: CGL specifies that carrier grade Linux shall support system wide limits on mlocked pages. This shall be configurable and enforced when the mlock page count exceeds the maximum setting. Either explicitly through a system call or implicitly through a page fault. The behavior shall be identical to per process mlocked limit when this system wide limit is exceeded.
AVL.29.0 Coarse Resource Enforcement
Priority: P3
Description: The CGOS needs to provide mechanisms that allow resource consumption constraints to be applied to an individual thread, a process and all processes running with a particular user ID or group ID, when resource consumption limits are exceeded.
These resource consumption constraints should follow today’s mechanisms for resource exhaustion for individual processes and groups of processes. Constraints must have actions that can be selected when an application is first started. Such actions include “log”, “signal process” and “terminate process”.
This requirement applies to CPUs as well as memory.
Reference: CGOS-4.5: Coarse Resource Enforcement
Cluster Gaps
CAF.2.3 Deliberate TCP Session Takeover
Action: Rewrite using new gaps template.
Notes: Discussion around this topic happened, http://tcpcp2.sf.net was created but the project appears to have been abandoned since then with no prospects for getting it mainlined.
Priority: P2
Description: CGL specifies a mechanism to synchronize TCP sockets, buffer structures, and sequence numbers so that redundant nodes may take over TCP sessions originated on other nodes. A deliberate TCP session takeover assumes that TCP session(s) are transferred deliberately and not as the result of unexpected node failure(s).
CAF.2.4 TCP Session Takeover on Node Failure
Action: Rewrite using new gaps template.
Notes: Discussion around this topic happened, http://tcpcp2.sf.net was created but the project appears to have been abandoned since then with no prospects for getting it mainlined.
Priority: P2
Description: CGL specifies a mechanism to synchronize TCP sockets, buffer structures, and sequence numbers so that when a critical resource fails, such as a CPU, memory, or kernel, a redundant node may take over TCP sessions originated on the failed node. Note that when the TCP session(s) are assumed by a redundant node, the sessions will resume from the last checkpoint. TCP traffic should continue even if there is a conflict between the last TCP state of the failed node and the checkpointed TCP state on the redundant node.
Serviceability Gaps
SMM.7.8 Support for User Locked Page Reporting
Action: Rewrite using new gaps template.
Notes: Kernel-space implementation for this is showing up on lkml now. Needs rewriting, but it will probably be able to implement this as a rough estimate, it'll never be completely accurate and should be written to be an estimate of mlocked pages.
Priority: P3
Description: CGL specifies that in addition to current memory usage reporting, the OS shall report the count of mlocked pages to accurately determine how much memory may be reclaimed by the page frame reclaim algorithm. Based on mlocked page count and current memory usage reporting, a more accurate amount of free physical memory may be determined. In addition current overcommit policies shall take mlocked pages into account to accurately enforce memory overcommit policies for which the count of mlocked pages is applicable.
SMM.15.0 Discovery of Platform CPU Architecture
Priority: P3
Description: To allow the discovery of the topology and other details of a platform CPU architecture, such as the number and the sizes of the caches, to facilitate and optimize SMP programming.
The CGOS needs to allow an application to discover platform CPU architecture topology and details, such as the number of caches and the sizes of the caches, to facilitate the optimization of the use of multiple CPUs, the memory hierarchy and the interconnect fabric. The CGOS needs to provide such architectural information in a format that is uniform across platforms.
Many forms of SMP are available today in CG environments ranging from SMT to NUMA and combinations in-between. The CPU configurations have a profound effect on performance and stability. The scheduler in most operating systems (Linux 2.6, for example) dynamically builds a view of the system based on the CPU topology, including caches and threads. This view must be exported to application programmers (to a certain degree some of that information is already available in /sys/devices/system/cpu directory).
The understanding of shared vs. private caches and threads is key to writing high performance software. This architectural topology information must be available on demand (system call or from /proc) to facilitate the necessary application partitioning early in the design stage. This approach can be taken a step further, so that an application can determine the topology dynamically and optimize its operations for the specific topology.
Performance Gaps
PRF.11.1 Application (Pre)loading Non-Root
Action: Rewrite using new gaps template.
Priority: P3
Description: CGL specifies that carrier grade Linux shall provide support for the preloading of an application even when the application is not executing as root. A configuration capability must exist to allow the system loader to determine an application's eligible for preloading. The action of preloading an application must not overload the system memory. The configuration capability must provide a control that allows the application to specify what is to be done if it can't be pre-loaded. Options are:
- Load anyway as a normal (pageable) application. Fail and don't load the application.
- Regardless of the option used, any failure to pre-load the application must be logged.
PRF.11.2 Application (Pre)loading Limits
Action: Rewrite using new gaps template.
Priority: P3
Description: CGL specifies that carrier grade Linux shall provide mechanisms to avoid overloading a system when preloading applications. Specifically, it shall be possible to specify the total amount of memory reserved (pinned) by preloading applications.
Standards Gaps
Security Gaps
SEC.9.0 Unified Cryptographic Framework
Priority: P3
Description: To provide a cryptographic framework that supports encryption and message hashing for both kernel and user applications, secure tamper-proof storage for security-relevant data such as keys, and registration of cryptographic capabilities.
The CGOS needs to provide a unified framework for optimized implementations of common cryptographic (encryption and message hashing) algorithms.
Carrier grade solutions rely on communication protocols that have stringent security requirements. Typically, these protocols are based on standard security application providers such as SSL, SSH, IKE and JCE.
Data integrity is accomplished through mechanisms (message hashing) that check that data transmitted across the network or stored on/retrieved from disk without encryption are not modified. Data confidentiality is accomplished through mechanisms (encryption) that convert the data to a form not easily reversible, before being transmitted or stored. The use of both encryption and message hashing for data that are transmitted or stored demands a cryptographic framework that is available to both the kernel and user applications and that transparently makes use of whatever hardware encryption capabilities are available.
A prerequisite to the security capabilities described above is the ability to store in a secure, tamper-proof way security-relevant data, such as keys used to verify the integrity of downloaded data. Keys can be loaded during system assembly, and additional keys can be provided using a secure mechanism after the system is started. Such a mechanism is almost always a combination of hardware, operating system and firmware. See also Trust Mechanisms (CGOS-3.1).
A unified cryptographic framework must expose to security providers a common interface to algorithms not only for various encryption algorithms (at the very minimum 3DES and AES) but also for message hashing (MD5, SHA1), message signing (RSA, DSA, DH) and random number generation. See the RSA cryptographic token interface standard PKCS #11 [19].
Hardware acceleration is also desirable for carrier grade components that use encryption. The cryptographic framework must offer mechanisms whereby device drivers can register the cryptographic hardware. A device with a cryptographic capability (key store, encryption algorithm) must be able to register the capability with the cryptographic framework. Registration includes, for example, the type of cryptographic capability, available algorithms, and number of contexts. When a driver initializes, it must register any cryptographic capabilities possessed by the device(s) it controls.
When a kernel thread or user process requests that a particular algorithm be used, the cryptographic framework must try to use the most efficient implementation based on the availability of resources in a transparent manner.
Algorithms must be easy to export/import. Cryptographic keys must be easily reduced to 56 bits, or cryptography must be easy to switch off.
Reference: CGOS-3.3: Unified Cryptographic Framework
Hardware Gaps
Appendix A:
To be supplied
