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
Action: Rewrite using new gap template.
Priority: P1
Description: CGL specifies that carrier grade Linux shall provide support for forced unmounting of a file system. The un-mount shall work even if there are open files in the file system. Pending requests shall be ended with the return of an error value when the file system is unmounted.
AVL.3.3 Forced Un-mount Application Notification
Action: Rewrite using new gaps template.
Priority: P3
Description: CGL specifies that carrier grade Linux shall provide a notification mechanism when a forced un-mount of a file system occurs.
AVL.7.1.2 Multi-Path Access to Storage
Action: Move to implemented requirements document.
Notes: This requirement appears to be implemented today as part of any fibre channel driver.
Priority: P2
Description: CGL specifies that carrier grade Linux shall provide a mechanism to enable multiple access paths from a node to storage devices. The software shall determine if multiple paths exist to the same port of the I/O device, and, with configurable controls, balance I/O requests across multiple host bus adapters. If multiple paths exist to the same device over two separate device ports on the same host bus adapter, those I/Os will not be balanced.
AVL.18.0 iSCSI Error Handling Support
Action: Move to implemented requirements document.
Notes: This requirement appears to be implemented today in iSCSI.
Priority: P3
Description: CGL specifies that the iSCSI Initiators implemented by carrier grade Linux should support the following iSCSI options:
- Header and Data Digests
- Error recovery level 1 as specified by RFC 3720
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
CCON.1.2 Boot/Reboot nodes
Action: Move to implemented requirements.
Notes: This appears to be a request for standard IPMI/xTCA functionality already present in the linux kernel.
Priority: P3
Description: CGL specifies that carrier grade Linux shall provide the ability for the management console to remotely boot or reboot any node in the cluster. The ability to boot/reboot a cluster node must conform to the HPI standard. Links to Other Specifications CGL Standards Requirements Definition:
- STD.8.8 SA Forum HPI
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.12.0 Remote Boot Support (was PMT.2.0)
Action: Move to implemented requirements document.
Notes: This requirement appears to be met via NFS root and TFTP kernel support.
Priority: P3
Description: CGL specifies that carrier grade Linux shall provide support for remote booting across common LAN and WAN communication media to support diskless systems.
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.
SFA.8.0 Kernel Flat/Graph Execution Profiling
Action: Move to implemented requirements.
Notes: This requirement appears to be implemented via systemtap and microstate accounting, oprofile and LTTng.
Priority: P3
Description: CGL specifies that carrier grade Linux shall provide support for profiling of the running kernel using a prof or gprof style of recording trace information during system execution.
SFA.14.0 Per Thread CPU Time Limits and Signaling
Action: Move to implemented requirements document.
Notes: CPU time consumed by individual threads is already tracked and available to userspace (see the top application). The Completely Fair Scheduler (CFS) and the cgroups feature allow limiting of processes or threads on a configurable level.
Priority: P3
Description: CGL specifies that carrier grade Linux shall provide a method to accurately track CPU time consumed by an individual thread. It shall also provide a method to set CPU threshold time used by an individual thread. This method shall also include the ability to send a signal to an individual thread if its CPU threshold time is exceeded.
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
STD.11.2 Diameter Protocol Minor CGL Features
Action: Move to implemented requirements document.
Notes: The draft referenced here has been published as RFC4004 which appears to be implemented in OpenDiameter, the only current open source implementation of the Diameter protocol.
Priority: P3
Description: CGL specifies that carrier grade Linux shall provide the functionality defined in the following Internet drafts.
Action: Move to implemented requirements document.
Notes: This requirement appears to be implemented in current CA software. OpenSSL supports X.509 PKI.
Priority: P3
Description: CGL specifies that carrier grade Linux shall provide the functionality for private key infrastructure (PKI) support as defined in the standards:
- RFC 2527 - Internet X.509 Public Key Infrastructure
STD.20.2 PKI CA: RFC 2585 X.509 PKI Protocols FTP and HTTP
Action: Move to implemented requirements document.
Notes: This requirement appears to be implemented in current CA software. OpenSSL supports X.509 PKI.
Priority: P3
Description: CGL specifies that carrier grade Linux shall provide the functionality for private key infrastructure (PKI) support as defined in the standards:
- RFC 2585 - Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP
STD.20.3 PKI CA: RFC 3279 Algorithms for X.509 PKI
Action: Move to implemented requirements document.
Notes: This requirement appears to be implemented in current CA software. OpenSSL supports X.509 PKI.
Priority: P3
Description: CGL specifies that carrier grade Linux shall provide the functionality for private key infrastructure (PKI) support as defined in the standards:
- RFC 3279 - Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure
STD.20.4 PKI CA: RFC 3280 X.509 PKI Certificate Stuff
Action: Move to implemented requirements document.
Notes: This requirement appears to be implemented in current CA software. OpenSSL supports both X.509 PKI and publishing CRLs for expired or compromised certificates.
Priority: P3
Description: CGL specifies that carrier grade Linux shall provide the functionality for private key infrastructure (PKI) support as defined in the standards:
- RFC 3280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Security Gaps
SEC.3.5 Log Integrity and Origin Authentication
Action: Move to implemented requirements.
Notes: This requirement is implemented in a combination of software including AIDE and syslog-ng.
Priority: P3
Description: CGL specifies that carrier grade Linux shall provide a mechanism to check that log files have not been modified (integrity), even by most insiders. In addition, CGL specifies that carrier grade Linux shall provide a mechanism to verify the origin of a log message. CGL specifies that carrier grade Linux shall provide a mechanism to prevent replay attacks of a log message. Objectives Satisfied: O.DETECT-SOPHISTICATED, O.ACCOUNT-TOE, O.DETECT-TOE, O.OBSERVE-TOE, O.DETECT-SYSTEM
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
