US20100192159A1 - Separation kernel with memory allocation, remote procedure call and exception handling mechanisms - Google Patents
Separation kernel with memory allocation, remote procedure call and exception handling mechanisms Download PDFInfo
- Publication number
- US20100192159A1 US20100192159A1 US12/702,817 US70281710A US2010192159A1 US 20100192159 A1 US20100192159 A1 US 20100192159A1 US 70281710 A US70281710 A US 70281710A US 2010192159 A1 US2010192159 A1 US 2010192159A1
- Authority
- US
- United States
- Prior art keywords
- strand
- cell
- task
- segments
- target
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/468—Specific access rights for resources, e.g. using capability register
Definitions
- the present invention relates generally to using the separation principle to design a kernel of an operating system, and more particularly, the present invention relates to a kernel that applies the separation principle to memory allocation, remote procedure call and exception handling mechanisms.
- Separation is an extremely important property in the construction and analysis of secure systems. If two logical entities A and B (for example, two pieces of software) are separate, then separation means that there is no way for A to influence the operation of B, and vice versa. If the operation of A is important to the security of a system, the separation of A and B means that the operation of B can be ignored when evaluating how A supports the security of the system. If A and B are not separate, so that B could influence the operation of A, then both A and B must be considered in evaluating how A supports the security of the system. The necessity of evaluating A and B increases the difficulty and cost of the security evaluation, and usually yields a lower assurance of security. Thus lack of separation yields the combination of higher cost and lower assurance.
- Separation is a principal that has been investigated for the construction of secure systems for some time. The idea behind separation can be described with the assistance of FIG. 1 .
- a system is sometimes implemented as a set of separate physical devices, with the devices interconnected by physical wires.
- FIG. 1 if it is important to the security of the system that box 1 does not directly intercommunicate with box 4 , then one need only look at the arrangement of the physical boxes and wires to determine the truth of this property.
- FIG. 2 This new implementation of the same system is depicted in FIG. 2 .
- the tasks are performing the same functions and are interconnected in the same way as the boxes of FIG. 1 . If it was important before that box 1 does not directly intercommunicate with box 4 , then it is still important that task 1 does not directly intercommunicate with task 4 . Analyzing the system of FIG. 2 may not be as easy as it was in FIG. 1 . The reason for the increasing difficulty of analysis is shown in FIG. 3 .
- FIG. 3 shows task 3 influencing task 1 by means of operating system mechanisms.
- a standard example of this is memory allocation. If all of the tasks allocate memory from a shared pool of resources, then task 3 could allocate all of the memory. When task 1 runs and attempts to allocate memory, it will receive a failing return from the operating system. This failing return could encode a “1” transmitted from task 3 to task 1 . If task 3 then releases some memory, when task 1 runs, it will try to allocate some memory again, this time receiving a successful return from the operating system.
- the present invention applies the separation principle to the design a kernel of an operating system. More specifically, the kernel incorporates memory allocation, remote procedure call and exception handling mechanisms in such a way that supports the separation concept.
- FIG. 1 is a diagram depicting a box and wire model for a typical system architecture
- FIG. 2 is a diagram depicting a task model that may reside on a physical device in a typical system architecture
- FIG. 3 is a diagram depicting the task model that is supported by an operating system in a typical multi-tasking architecture
- FIG. 4 is a diagram illustrating the different types of memory segments supported by the framework of the present invention.
- FIG. 5 is a diagram illustrating the cell abstraction concept of the present invention.
- FIG. 6 is a diagram illustrating the interaction between cells in accordance with the present invention.
- FIG. 7 is a diagram depicting a single cell and two cell operations in accordance with the separation principle of the present invention.
- FIG. 8 is a diagram depicting a multiple cell abstraction system
- FIGS. 9-11 illustrate the fundamental relationships and equations that define the separation specification of the present invention.
- FIGS. 12 and 13 illustrate the first and second separation axioms, respectively, in accordance with the separation specification of the present invention
- FIG. 14 depicts a separation kernel that supports a high degree of separation between processing elements in a computer-implemented system in accordance with the present invention
- FIGS. 15-17 illustrate various operations of a strand in a cell in accordance with the present invention
- FIG. 18 illustrates a method for allocating memory in accordance with the present invention.
- FIG. 19 illustrates a method for performing remote procedure calls in accordance with the present invention.
- the present invention generally relates to designing a kernel of an operating system in accordance with the separation principle.
- a framework for designing the separation kernel is set forth below. It is to be understood that this framework, the subsequent description of the separation principle and its application to the design of the kernel are merely exemplary and are intended to provide an understanding of the nature and character of the invention as it is claimed.
- a cell is defined as a domain of execution and a collection of strands, where each strand is a stream of programmable machine instructions executable by the kernel of the operating system.
- a domain of execution is also referred to as the context of the cell and a strand is also referred to as a task.
- the context of a cell is comprised of one or more memory segments. Each segment is a range of physical memory addresses, which are defined by a starting address and a length.
- the framework of the present invention supports different types of memory segments as shown in FIG. 4 .
- Permanent segments are allocated to a cell and therefore are accessible to any of the strands associated with the cell. Permanent segments may be used for storing data, code (i.e., a strand's machine instructions) or memory mapped hardware interfaces. Permanent segments cannot be sent in messages, but are retained when the currently executing strand of the cell suspends.
- transient segment is accessible to the strand, which is running in the cell, and to the cell.
- each strand has predefined memory requirements for its transient segments.
- the transient segments are allocated for the strand.
- the transient segments are accessible to the strand.
- the framework supports different types of transient segments, such as an input message segment, a scratch segment, an assigned segment, and a register segment.
- Each cell can execute only one strand at a time.
- Strand 3 22 is currently running in Cell A 20 . It is processing an input message 24 , which is made up of one or more transient segments. Strand 3 22 may use one or more scratch segments 26 to process the input message 24 .
- a scratch segment is a temporary memory space of sufficient size to be used by the strand when processing the input message.
- Strand 3 may also access an assigned segment 28 .
- An assigned segment is a specified transient segment used to gain access to available resources, such as device registers.
- Strand 3 may access one or more permanent segments. For instance, the encapsulated data segment 30 contains static data used by the strand.
- Cell B 32 is currently not executing a strand. However, it may begin execution of a strand some time after it is granted access to an input message received from Strand 3 22 of Cell A 20 .
- Strand 4 34 is shown being launched in Cell B .
- the cell receives access to the message segment(s) that make up the input message. Again, the strand may require scratch segments to process the input message.
- an interrupt strand may be run immediately upon receipt of an interrupt. Thus, the execution of a strand may be interleaved with the execution of interrupt strands.
- a cell interfaces to its external world (e.g., to other cells or the underlying hardware) only through the substrate.
- the substrate is defined as the operating system, the device drivers, and the underlying hardware of the system. Exemplary cell interfaces are illustrated in FIG. 6 .
- the kernel of the operating system launches Strand 3 22 of CellA 20 .
- the strand is given access by the kernel to its input message segment(s) and scratch segment(s).
- Strand 3 22 uses a Send interface 36 to send some of its transient segments to Strand 4 34 of Cell B 32 .
- Cell A loses access to the segments transmitted by the strand.
- Strand 3 of Cell A addresses an exception condition through the use of a Throw interface 38 .
- the interface terminates execution of the strand and initiates execution of a Handler function.
- the kernel removes access to all of the transient segments remaining in Cell A . If Strand 3 of Cell A had not terminated via the exception condition, it would have reached the end of its strand.
- the TerminateStrand interface 39 terminates the execution of the strand and removes access to any transient segments still accessible to the cell.
- the separation kernel of the present invention will be designed and implemented within the above-described framework. Data structures that define and describe the strands and cells in the above-described framework are further discussed in the Appendix.
- FIG. 7 shows a cell 40 and two of its operations, Fiberinit 42 and FiberNext 44 . Again, the cell represents an execution domain. Moreover, the cells are the components of the system to be separated.
- FIG. 8 several cells have been combined into a system 50 that is referred to as the Multiple Cell Abstraction, where each individual cell is referred to as a Single Cell Abstraction (SCA).
- SCA Single Cell Abstraction
- Each cell has its own Fiberinit and FiberNext operations, whereas the system as a whole has an Init 52 and Next 54 operation. Since the cells serve as the Fibers of the system, the names for the cell level operations are Fiberinit and FiberNext. The names Init and Next are reserved for the system level operations.
- the Next operation (advancing the system state) could correspond to a FiberNext operation (advancing a cell state) on every cell at once, thereby implying multiprocessing of the cells.
- the Next operation could correspond to a FiberNext operation on only one cell or on some subset of the cells.
- the separation specification of the present invention defines the Next operation to advance a cell state only one cell at a time and the Init operation to initialize the cell state of all the cells at once. Therefore, the system state advances one cell at a time, but the initialization of the system is not complete until all of the cells are ready to run.
- FIG. 9 depicts this design choice for the separation specification of the present invention.
- the Next B operation 62 is being performed on the system, where the Next B operation is the Next operation performed on Cell B .
- the state of the system before the Next operation is shown as MCA State 1 64 .
- MCA State 1 64 includes Cell A in state SCA A1 66 , Cell B in state SCA B1 68 and Cell C in state SCA C1 70 .
- the state of the system after the Next operation is shown as MCA State 2 72 , where Cell A is in state SCA A2 74 , Cell B is in state SCA B2 76 and Cell C is in state SCA C2 78 .
- the Next B operation at the system level corresponds to selecting a cell and advancing the state of that one cell.
- FIG. 9 further illustrates that performing Next B on MCA 1 achieves the same result as taking Fiber B 80 of MCA 1 to yield SCA B1 82 , and then performing FiberNext 84 on SCA B1 .
- Cell B is selected by the Fiber B operation.
- Performing the FiberNext operation upon CellB advances the state of Cell B . In equation form, this is:
- Fiber B (Next B (m)) FiberNext(Fiber B (m))
- FIG. 10 is a commuting diagram, which is a diagrammatic form of the above equation.
- the internal cells of MCA have been hidden from the external world and can be observed only through the Fiber operation. This equation can be further shortened to:
- variable m has been dropped.
- equation is between two functions, rather than the value of the functions at an arbitrary input.
- ⁇ symbol denotes function composition.
- FIG. 11 The final form of this relationship is shown in FIG. 11 .
- the functions Next B and Fiber B have been uncurried into Next and Fiber.
- the equations corresponding to FIG. 11 are given as follows:
- the operators Init and Next are specified to be the constructors of the MCA. This means that all possible MCA states are the result of system initialization and the advancement of the system state one step at a time by the Next operation. This specifies that the system cannot land in any “unspecified” states that might not satisfy the security constraints of the system. There is a similar constraint upon the SCA that states that any SCA must be the result of a Fiber operation on an MCA. Since the MCA is constrained to be in valid states, as constructed by Init and Next, this constrains the SCAs to be in valid states resulting from taking a Fiber of a valid MCA.
- MCA Multiple Cell Abstraction
- SCA Single Cell Abstraction
- FIG. 12 depicts a First Separation Axiom, which sets forth the communication policy between cells. Since the communication policy references the concept of a cell, it is logical that the statement of the communication policy should reference the definitions of the Next and Fiber functions. Indeed, one of the purpose for separating the system into cells is to restrict communication within the system. Accordingly, FIG. 12 describes an equation stating that cell SCA x can influence cell SCA y only if cell SCA x is permitted to communicate with cell SCA y by the communication policy enforced by the kernel.
- the communication policy is alternatively recited by the following equations:
- the second equation (i.e., the contrapositive form of the first equation) states that if the fiber of cell y changes as the result of advancing the state of cell x, it must be the case the x is permitted to communicate with y.
- the equation states that if cell x cannot communicate with cell y, then whenever the state of cell x is advanced, there is no change in the state of y.
- a particular consequence of this communication policy is that cell x can send messages to y only if cell x has permission to communicate with y.
- the Second Separation Axiom is depicted in FIG. 13 . It should be noted that this diagram is not a commuting diagram. This diagram depicts the following equations:
- SCA 1x Fiber x ( MCA 1 )
- SCA 2x Fiber x ( MCA 2 )
- SCA 1y Fiber y ( MCA 1 )
- SCA 2y Fiber y ( MCA 2 )
- SCA′ 1x Fiber x ( MCA′ 1 )
- SCA′ 2x Fiber x ( MCA′ 2 )
- SCA′ 1y Fiber y ( MCA′ 1 )
- SCA′ 2y Fiber y (MCA′ 2 )
- the first equation states that if x has the same fiber in two different system states MCA 1 and MCA 2 , and y has the same fiber in MCA 1 and MCA 2 , then y has the same fiber after advancing the state x in both MCA 1 and MCA 2 .
- the contrapositive form of this equation i.e., the second equation
- the second equation may be more revealing. It says that if advancing x causes a change in the state of y, then the change must have resulted from either a change in the state of x or a change in the state of y.
- FIG. 14 a computer-implemented system 90 that supports a high degree of separation between processing elements is shown in FIG. 14 .
- the computer-implemented system 90 comprises a plurality of cells 92 , where each cell includes a domain of execution 94 and at least one processing element 96 .
- a kernel 98 facilitates execution of the processing elements and administers the communication between the processing elements in accordance with a separation specification 99 .
- the separation specification 99 governs communication between the processing elements, such that one processing element can influence the operation of another processing element only as set forth by the separation specification.
- a preferred implementation of the kernel and its separation specification has selected several features that are required by the applications of the kernel and can be made to fit the separation principle.
- memory allocation is a selected feature because the intended applications are required to process many kinds of data which often require added memory resources to efficiently process the data. Since the applications require time-shared access to hardware resources, the hardware resources are allocated as memory mapped segments to the cells in a way that preserves the separation property.
- remote procedure call procedure is a selected feature because many intended applications require a communications mechanism beyond a simple send-message.
- the remote procedure call is a communication mechanism in which information is provided to a server, the server processes the information and returns a result, and the processing continues in the same context that existed before the service was invoked.
- exception handling is a selected feature because the intended applications are required to be robust with respect to exceptions. Since exceptions can be handled locally with assurance that the direct cause of the exception is local, exception handling is also improved by the separation principle.
- Each of these selected features i.e., memory allocation, remote procedure calls and exception handling is further described below.
- a memory allocation mechanism in the separation kernel of the present invention is understood in relation to the operation of a strand as shown in FIG. 15 .
- a strand is allocated the memory it requires according to its predefined memory requirements.
- the strand memory requirements are constant for that strand, in that they are the same each time the strand is launched.
- the strand receives two kinds of transient segments upon strand launch: message segments and non-message segments.
- message segments are segments, which have been sent by some other strand to the strand being launched. It is the existence of this message that causes the strand launch.
- Non-message segments are the other transient segments, which are described by the predefined memory requirements for the strand.
- the strand executes, it undergoes interactions with the kernel. If the strand elects to send some of its transient segments as part of an input message to another strand, then access to the transient segments is lost at this point. Thus, the strand can lose access to transient segments as it executes, but it cannot gain access to any more transient segments as it executes.
- the allocation of transient segments for a strand obeys the following properties: (1) before strand launch, the strand has access only to the permanent segments of the cell; (2) transient memory requirements for a strand are a function of the strand, and thus are known at compile time; (3) the kernel does not launch the strand until there is sufficient memory to satisfy all of the memory requirements for the strand; (4) transient segments that are non-message segments are initialized before allocation; (5) as the strand executes, it can lose memory segments (e.g., by sending a message), but it cannot allocate any more segments; and (6) strand termination causes all transient segments to be released by the kernel.
- FIG. 18 illustrates a method for allocating memory by a separation kernel in accordance with the above-described principles.
- the separation kernel of the present invention also implements a remote procedure call mechanism.
- the Strand 3 may makes a remote procedure call 92 to Strand 5 in the target cell (i.e., Cell B ).
- the target cell i.e., Cell B
- some of the transient segments of the source strand are sent to the target strand.
- these transmitted segments become inaccessible to the source strand and accessible to the target strand.
- These transmitted segments constitute the parameters of the remote procedure call.
- the target strand When the target strand is launched, the target strand only gets access to the input transient segments and the permanent segments of the target cell. Since there are no additional memory segments to allocate, it can be concluded that there are sufficient resources to execute the remote procedure call. In other words, the remote procedure call cannot fail on account of insufficient resources.
- the kernel is designed to ensure that internal kernel resources will be sufficient to process the remote procedure calls, so that no resource exhaustion covert channel is provided by the kernel itself Therefore, it is not possible for the remote procedure call to fail on account of insufficient resources within the kernel.
- the target strand terminates using the normal strand termination mechanism.
- the target strand returns a value 94 to the calling strand.
- the transmitted segments are made inaccessible to the target strand and made once again made accessible to the source strand. This means that before and after the remote procedure calls the same set of segments are accessible to the source strand. If the target strand is terminated for any other reason, the remote procedure call mechanism causes a return to the source strand, and thus guarantees a return from the remote procedure call.
- the target strand During its execution, the target strand is prohibited from sending the transmitted segments as part of a send message. Thus, the segments remain available to be returned to the source strand. Furthermore, the target strand can make a remote procedure call of its own. To do so, the target strand retransmits one or more of the transmitted segments to another target strand. When this additional remote procedure call is completed, the re-transmitted segments are returned to the target strand.
- the remote procedure call mechanism does not allow recursive calls, i.e. calls to strands in a cell that is already part of the remote procedure call stack.
- the remote procedure call mechanism also does not permit a call to a cell that already has an executing strand, thereby preserving the property that only one strand of a cell can run at any one time. This is an important property to prevent re-entrant code. Re-entrant code can cause various runtime errors.
- FIG. 19 illustrates a method for performing remote procedure calls in accordance with the above-described principles.
- the exception handler has the option of attempting to resume processing of the strand that incurred the exception or terminating the execution of the strand. In FIG. 17 , it is assumed that the exception handler resumes processing of the strand that incurred the exception. Thus, the strand completes execution and then terminates.
- Each strand has a maximum exception count.
- the strand incurs a number of exceptions equal to the maximum exception count, the strand is terminated by the kernel.
- the kernel there is no way to get stuck in a loop of exceptions, which in turn causes, more exceptions.
- the strand will be terminated when the maximum exception count is reached.
- exception handling mechanism enhances the separation property by providing exception handling that is separate between cells.
- the cell state is dynamic information about the cell. It is maintained as a map from CellID to CellState, where CellState is one of Idle, Running, or Waiting. This mapping is called the CellStateMap.
- strand descriptor All of the information in the strand descriptor is static information about the strand. There are seven items in the strand descriptor:
- InitialStrand used by the kernel. This is static strand information. When the kernel has completed initialization, it launches the strand indicated by the InitialStrand configuration parameter.
- Execution of a strand may require allocation of resources.
- the resources that may be allocated are scratch and assigned segments.
- Resource availability for a strand means:
- a related concept to resource availability for a strand is the runnability of a strand.
- a strand is runnable when:
- a strand When a strand begins, it has several standard arguments, which are passed to it by the kernel. The parameters are passed utilizing the registers/stack. The strand must have sufficient stack space for the stacked parameters along with any space necessary for local data.
- the variables that are initialized with their values and available for a strand to use when it starts are as follows:
- Exception processing allows a strand to transfer control to the exception handler specified in the cell descriptor for the cell. This feature is similar to a jump and should be used to handle cases where abnormal conditions arise.
- the exception code is the only parameter passed to the exception handler by the currently running strand.
- the exception code should contain the error code that resulted in the exception.
- the system reserves the first 32 exception codes (0 ⁇ 31) for current and future growth. Each cell is free to use the other exception codes as needed.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Storage Device Security (AREA)
- Semiconductor Memories (AREA)
- Techniques For Improving Reliability Of Storages (AREA)
- Hardware Redundancy (AREA)
Abstract
A computer-implemented system (90) is provided that supports a high degree of separation between processing elements. The computer-implemented system (90) comprises a plurality of cells (92) residing on the computer-implemented system, where each cell (92) includes a domain of execution (94) and at least one processing element (96); a separation specification (99) that governs communication between the processing elements (96); and a kernel (98) of an operating system that facilitates execution of the processing elements (96) and administers the communication between the processing elements (96) in accordance with the separation specification (99), such that one processing element (96) can influence the operation of another processing element (96) only as set forth by the separation specification (99). In particular, the separation specification provides memory allocation, remote procedure calls and exception handling mechanisms.
Description
- This application is a continuation of U.S. application Ser. No. 10/866,564 filed Jun. 10, 2004 which is a continuation of U.S. application Ser. No. 09/443,597 filed Nov. 19, 1999 now issued as U.S. Pat. No. 6,772,416 on Aug. 3, 2004.
- 1. Technical Field
- The present invention relates generally to using the separation principle to design a kernel of an operating system, and more particularly, the present invention relates to a kernel that applies the separation principle to memory allocation, remote procedure call and exception handling mechanisms.
- 2. Discussion
- Separation is an extremely important property in the construction and analysis of secure systems. If two logical entities A and B (for example, two pieces of software) are separate, then separation means that there is no way for A to influence the operation of B, and vice versa. If the operation of A is important to the security of a system, the separation of A and B means that the operation of B can be ignored when evaluating how A supports the security of the system. If A and B are not separate, so that B could influence the operation of A, then both A and B must be considered in evaluating how A supports the security of the system. The necessity of evaluating A and B increases the difficulty and cost of the security evaluation, and usually yields a lower assurance of security. Thus lack of separation yields the combination of higher cost and lower assurance.
- Complete separation (no influence between A and B) yields a conceptually clean system. Incomplete separation can still be very good if there are a small (e.g. one, two, or three) number of known influence paths between A and B, and these paths have low bandwidth and/or are difficult to use. Incomplete separation is unacceptable in a high assurance system when it results from the inherent complexity of the system, and the resulting inability to analyze the possible influences between A and B. Therefore, it is desirable to construct a high assurance system applying strong separation principles.
- Separation is a principal that has been investigated for the construction of secure systems for some time. The idea behind separation can be described with the assistance of
FIG. 1 . A system is sometimes implemented as a set of separate physical devices, with the devices interconnected by physical wires. InFIG. 1 , if it is important to the security of the system that box1 does not directly intercommunicate with box4, then one need only look at the arrangement of the physical boxes and wires to determine the truth of this property. - It is often the case that the same system will be implemented in one physical box, but with logical entities (e.g. software processes) performing the same functions as the physical boxes of
FIG. 1 . This new implementation may result from increasing miniaturization of components, or the increasing memory and processing power available within on processor platform. This new implementation of the same system is depicted inFIG. 2 . The tasks are performing the same functions and are interconnected in the same way as the boxes ofFIG. 1 . If it was important before that box1 does not directly intercommunicate with box4, then it is still important that task1 does not directly intercommunicate with task4. Analyzing the system ofFIG. 2 may not be as easy as it was inFIG. 1 . The reason for the increasing difficulty of analysis is shown inFIG. 3 . - The problem is that all of the tasks communicate with the operating system, thus the operating system becomes a means whereby information can be transmitted between tasks, and tasks can influence each other even when not permitted by the communication policy of the operating system.
FIG. 3 shows task3 influencing task1 by means of operating system mechanisms. A standard example of this is memory allocation. If all of the tasks allocate memory from a shared pool of resources, then task3 could allocate all of the memory. When task1 runs and attempts to allocate memory, it will receive a failing return from the operating system. This failing return could encode a “1” transmitted from task3 to task1. If task3 then releases some memory, when task1 runs, it will try to allocate some memory again, this time receiving a successful return from the operating system. This successful/failure return from the operating system was never intended to be used as a communication channel, nevertheless a good hacker can make use of it in this way. In other words, the problem is that the other software (e.g., other tasks and the operating system) can now influence the operation of the task under analysis, and thus the task under analysis cannot be analyzed in isolation. - Therefore, it is desirable to provide a high-grade separation between processing elements in a system. This high-grade separation permits the system designer to establish high assurance secure systems by allowing each processing element to be analyzed in isolation. To achieve high-grade separation, the present invention applies the separation principle to the design a kernel of an operating system. More specifically, the kernel incorporates memory allocation, remote procedure call and exception handling mechanisms in such a way that supports the separation concept.
- The present invention will hereinafter be described in conjunction with the appended drawing figure(s), wherein like numerals denote like elements, and:
-
FIG. 1 is a diagram depicting a box and wire model for a typical system architecture; -
FIG. 2 is a diagram depicting a task model that may reside on a physical device in a typical system architecture; -
FIG. 3 is a diagram depicting the task model that is supported by an operating system in a typical multi-tasking architecture; -
FIG. 4 is a diagram illustrating the different types of memory segments supported by the framework of the present invention; -
FIG. 5 is a diagram illustrating the cell abstraction concept of the present invention; -
FIG. 6 is a diagram illustrating the interaction between cells in accordance with the present invention; -
FIG. 7 is a diagram depicting a single cell and two cell operations in accordance with the separation principle of the present invention; -
FIG. 8 is a diagram depicting a multiple cell abstraction system; -
FIGS. 9-11 illustrate the fundamental relationships and equations that define the separation specification of the present invention; -
FIGS. 12 and 13 illustrate the first and second separation axioms, respectively, in accordance with the separation specification of the present invention; -
FIG. 14 depicts a separation kernel that supports a high degree of separation between processing elements in a computer-implemented system in accordance with the present invention; -
FIGS. 15-17 illustrate various operations of a strand in a cell in accordance with the present invention; -
FIG. 18 illustrates a method for allocating memory in accordance with the present invention; and -
FIG. 19 illustrates a method for performing remote procedure calls in accordance with the present invention. - The present invention generally relates to designing a kernel of an operating system in accordance with the separation principle. A framework for designing the separation kernel is set forth below. It is to be understood that this framework, the subsequent description of the separation principle and its application to the design of the kernel are merely exemplary and are intended to provide an understanding of the nature and character of the invention as it is claimed.
- In accordance with the present invention, the principle abstraction for the framework is the cell. A cell is defined as a domain of execution and a collection of strands, where each strand is a stream of programmable machine instructions executable by the kernel of the operating system. For purposes of the following description, a domain of execution is also referred to as the context of the cell and a strand is also referred to as a task.
- The context of a cell is comprised of one or more memory segments. Each segment is a range of physical memory addresses, which are defined by a starting address and a length. The framework of the present invention supports different types of memory segments as shown in
FIG. 4 . - Permanent segments are allocated to a cell and therefore are accessible to any of the strands associated with the cell. Permanent segments may be used for storing data, code (i.e., a strand's machine instructions) or memory mapped hardware interfaces. Permanent segments cannot be sent in messages, but are retained when the currently executing strand of the cell suspends.
- In contrast, a transient segment is accessible to the strand, which is running in the cell, and to the cell. In other words, each strand has predefined memory requirements for its transient segments. When the strand is launched, the transient segments are allocated for the strand. Thus, the transient segments are accessible to the strand. As will be more fully explained below, the framework supports different types of transient segments, such as an input message segment, a scratch segment, an assigned segment, and a register segment.
- An overview of the framework, including the cell abstraction concept and its interrelationships, are further discussed in relation to
FIG. 5 . Each cell can execute only one strand at a time.Strand 3 22 is currently running inCell A 20. It is processing aninput message 24, which is made up of one or more transient segments.Strand 3 22 may use one ormore scratch segments 26 to process theinput message 24. A scratch segment is a temporary memory space of sufficient size to be used by the strand when processing the input message. Strand3 may also access an assignedsegment 28. An assigned segment is a specified transient segment used to gain access to available resources, such as device registers. Lastly, Strand3 may access one or more permanent segments. For instance, the encapsulateddata segment 30 contains static data used by the strand. -
Cell B 32 is currently not executing a strand. However, it may begin execution of a strand some time after it is granted access to an input message received fromStrand 3 22 ofCell A 20. InFIG. 5 ,Strand 4 34 is shown being launched in CellB. When a strand in the cell is launched, the cell receives access to the message segment(s) that make up the input message. Again, the strand may require scratch segments to process the input message. In addition, an interrupt strand may be run immediately upon receipt of an interrupt. Thus, the execution of a strand may be interleaved with the execution of interrupt strands. - A cell interfaces to its external world (e.g., to other cells or the underlying hardware) only through the substrate. For purposes of this discussion, the substrate is defined as the operating system, the device drivers, and the underlying hardware of the system. Exemplary cell interfaces are illustrated in
FIG. 6 . First, the kernel of the operating system launchesStrand3 22 ofCellA 20. At this time, the strand is given access by the kernel to its input message segment(s) and scratch segment(s). Next,Strand 3 22 uses aSend interface 36 to send some of its transient segments to Strand4 34 ofCell B 32. As a result, CellA loses access to the segments transmitted by the strand. - After further execution of the strand, Strand3 of CellA addresses an exception condition through the use of a
Throw interface 38. The interface terminates execution of the strand and initiates execution of a Handler function. When execution of Strand3 of CellA terminates, the kernel removes access to all of the transient segments remaining in CellA. If Strand3 of CellA had not terminated via the exception condition, it would have reached the end of its strand. In this case, theTerminateStrand interface 39 terminates the execution of the strand and removes access to any transient segments still accessible to the cell. One skilled in the art will readily recognize that the separation kernel of the present invention will be designed and implemented within the above-described framework. Data structures that define and describe the strands and cells in the above-described framework are further discussed in the Appendix. - An introduction to the separation principle is provided in relation to
FIGS. 7-11 .FIG. 7 shows acell 40 and two of its operations,Fiberinit 42 andFiberNext 44. Again, the cell represents an execution domain. Moreover, the cells are the components of the system to be separated. - In
FIG. 8 , several cells have been combined into asystem 50 that is referred to as the Multiple Cell Abstraction, where each individual cell is referred to as a Single Cell Abstraction (SCA). Each cell has its own Fiberinit and FiberNext operations, whereas the system as a whole has anInit 52 andNext 54 operation. Since the cells serve as the Fibers of the system, the names for the cell level operations are Fiberinit and FiberNext. The names Init and Next are reserved for the system level operations. - There are several choices for defining the relationship between these cell operations. For instance, the Next operation (advancing the system state) could correspond to a FiberNext operation (advancing a cell state) on every cell at once, thereby implying multiprocessing of the cells. On the other hand, the Next operation could correspond to a FiberNext operation on only one cell or on some subset of the cells. There are similar design choices for the Init and Fiberinit operations. The separation specification of the present invention defines the Next operation to advance a cell state only one cell at a time and the Init operation to initialize the cell state of all the cells at once. Therefore, the system state advances one cell at a time, but the initialization of the system is not complete until all of the cells are ready to run.
-
FIG. 9 depicts this design choice for the separation specification of the present invention. In this figure, the NextB operation 62 is being performed on the system, where the NextB operation is the Next operation performed on CellB. The state of the system before the Next operation is shown asMCA State 1 64.MCA State 1 64 includes CellA instate SCA A1 66, CellB instate SCA B1 68 and CellC instate SCA C1 70. The state of the system after the Next operation is shown asMCA State2 72, where CellA is instate SCA A2 74, CellB is instate SCA B2 76 and CellC is instate SCA C2 78. The NextB operation at the system level corresponds to selecting a cell and advancing the state of that one cell. -
FIG. 9 further illustrates that performing NextB on MCA1 achieves the same result as takingFiber B 80 of MCA1 to yieldSCA B1 82, and then performingFiberNext 84 on SCAB1. In this case, CellB is selected by the FiberB operation. Performing the FiberNext operation upon CellB advances the state of CellB. In equation form, this is: -
FiberB(NextB(m))=FiberNext(FiberB(m)) -
FIG. 10 is a commuting diagram, which is a diagrammatic form of the above equation. The internal cells of MCA have been hidden from the external world and can be observed only through the Fiber operation. This equation can be further shortened to: -
FiberB·NextB=FiberNext·FiberB - In this short form, the variable m has been dropped. In addition, the equation is between two functions, rather than the value of the functions at an arbitrary input. The · symbol denotes function composition.
- The final form of this relationship is shown in
FIG. 11 . In this figure, the functions NextB and FiberB have been uncurried into Next and Fiber. This means that the function NextB is related to Next by the equation NextB(m)=Next(m, B) for CellB. In general, NextX is related to Next by the equation NextX(m)=Next(m, x) for any cell X. Since NextB was changed to Next, and FiberB was changed to Fiber, the CellID parameter is no longer contained in the subscript of the operator, so this must be made explicit in the domain of the Next and Fiber functions. This is why MCA is combined with CellID in the product MCA X CellID. The equations corresponding toFIG. 11 are given as follows: -
Fiber(Next(m, c))=FiberNext(Fiber(m, c)) -
Fiber·Next=FiberNext·Fiber - In simple terms, what these fundamental equations are saying is that when the system state is advanced by one step, the change in the system state corresponds to a change in the state of one of its cells, as identified by the Fiber function. If you look at the system state before advancing it one step and again after advancing it one step, then there will be a unique cell c, which accounts for this advance in the state of the system. This cell c accounts for the advance in the state of the system by advancing its own single cell state by one step.
- The operators Init and Next are specified to be the constructors of the MCA. This means that all possible MCA states are the result of system initialization and the advancement of the system state one step at a time by the Next operation. This specifies that the system cannot land in any “unspecified” states that might not satisfy the security constraints of the system. There is a similar constraint upon the SCA that states that any SCA must be the result of a Fiber operation on an MCA. Since the MCA is constrained to be in valid states, as constructed by Init and Next, this constrains the SCAs to be in valid states resulting from taking a Fiber of a valid MCA.
- In sum, the system under consideration is the Multiple Cell Abstraction (MCA). The elements of the system to be separated are the cells as represented by the Single Cell Abstraction (SCA). The relationship between the system and its cells is given in several forms by the above-described fundamental equations. These fundamental equations in turn serve as the basis for the separation specification of the present invention.
- The separation specification is further defined by two separation axioms.
FIG. 12 depicts a First Separation Axiom, which sets forth the communication policy between cells. Since the communication policy references the concept of a cell, it is logical that the statement of the communication policy should reference the definitions of the Next and Fiber functions. Indeed, one of the purpose for separating the system into cells is to restrict communication within the system. Accordingly,FIG. 12 describes an equation stating that cell SCAx can influence cell SCAy only if cell SCAx is permitted to communicate with cell SCAy by the communication policy enforced by the kernel. The communication policy is alternatively recited by the following equations: - In this case, the second equation (i.e., the contrapositive form of the first equation) states that if the fiber of cell y changes as the result of advancing the state of cell x, it must be the case the x is permitted to communicate with y. In its positive form, the equation states that if cell x cannot communicate with cell y, then whenever the state of cell x is advanced, there is no change in the state of y. A particular consequence of this communication policy is that cell x can send messages to y only if cell x has permission to communicate with y.
- The Second Separation Axiom is depicted in
FIG. 13 . It should be noted that this diagram is not a commuting diagram. This diagram depicts the following equations: -
SCA 1x=Fiberx(MCA 1) SCA 2x=Fiberx(MCA 2) -
SCA 1y=Fibery(MCA 1) SCA 2y=Fibery(MCA 2) -
SCA′ 1x=Fiberx(MCA′ 1) SCA′ 2x=Fiberx(MCA′ 2) -
SCA′ 1y=Fibery(MCA′ 1) SCA′ 2y=Fibery(MCA′2) -
(Fiberx(MCA 1)=Fiberx(MCA 2))=>[((Fibery(MCA 1)=Fibery(MCA 2))=>(Fibery(Nextx(MCA 1)=Fibery(Nextx(MCA 2))))] -
Fibery(Nextx(MCA 1))≠Fibery(Nextx(MCA 2))=>(Fiberx(MCA 1)≠(Fiberx(MCA 2))v(Fibery(MCA 1)≠Fibery(MCA 2)) - In accordance with these equations, if an action by cell x (e.g., advancing the state of the SCA for cell x) is going to change the state of cell y, then the change in the state of y depends only on the states of x and y. Without this axiom, an unknown cell could affect the state of y. For instance, if x changes y, it could do so by copying everything from a third cell z into the SCA of y. The purpose of this axiom is to prevent “undesirable” connections between cells such as z and y.
- Accordingly, the first equation states that if x has the same fiber in two different system states MCA1 and MCA2, and y has the same fiber in MCA1 and MCA2, then y has the same fiber after advancing the state x in both MCA1 and MCA2. The contrapositive form of this equation (i.e., the second equation) may be more revealing. It says that if advancing x causes a change in the state of y, then the change must have resulted from either a change in the state of x or a change in the state of y.
- To implement a separation kernel, the designer must choose features that support the intended applications and implement those features in a way that conforms to the above-described separation property. In accordance with the present invention, a computer-implemented
system 90 that supports a high degree of separation between processing elements is shown inFIG. 14 . The computer-implementedsystem 90 comprises a plurality ofcells 92, where each cell includes a domain ofexecution 94 and at least oneprocessing element 96. Akernel 98 facilitates execution of the processing elements and administers the communication between the processing elements in accordance with aseparation specification 99. Theseparation specification 99 governs communication between the processing elements, such that one processing element can influence the operation of another processing element only as set forth by the separation specification. - A preferred implementation of the kernel and its separation specification has selected several features that are required by the applications of the kernel and can be made to fit the separation principle. First, memory allocation is a selected feature because the intended applications are required to process many kinds of data which often require added memory resources to efficiently process the data. Since the applications require time-shared access to hardware resources, the hardware resources are allocated as memory mapped segments to the cells in a way that preserves the separation property. Second, remote procedure call procedure is a selected feature because many intended applications require a communications mechanism beyond a simple send-message. The remote procedure call is a communication mechanism in which information is provided to a server, the server processes the information and returns a result, and the processing continues in the same context that existed before the service was invoked. Third, exception handling is a selected feature because the intended applications are required to be robust with respect to exceptions. Since exceptions can be handled locally with assurance that the direct cause of the exception is local, exception handling is also improved by the separation principle. Each of these selected features (i.e., memory allocation, remote procedure calls and exception handling) is further described below.
- A memory allocation mechanism in the separation kernel of the present invention is understood in relation to the operation of a strand as shown in
FIG. 15 . At strand launch time, a strand is allocated the memory it requires according to its predefined memory requirements. The strand memory requirements are constant for that strand, in that they are the same each time the strand is launched. The strand receives two kinds of transient segments upon strand launch: message segments and non-message segments. Message segments are segments, which have been sent by some other strand to the strand being launched. It is the existence of this message that causes the strand launch. Non-message segments are the other transient segments, which are described by the predefined memory requirements for the strand. - As the strand executes, it undergoes interactions with the kernel. If the strand elects to send some of its transient segments as part of an input message to another strand, then access to the transient segments is lost at this point. Thus, the strand can lose access to transient segments as it executes, but it cannot gain access to any more transient segments as it executes.
- In order to achieve separation within the kernel, the allocation of transient segments for a strand obeys the following properties: (1) before strand launch, the strand has access only to the permanent segments of the cell; (2) transient memory requirements for a strand are a function of the strand, and thus are known at compile time; (3) the kernel does not launch the strand until there is sufficient memory to satisfy all of the memory requirements for the strand; (4) transient segments that are non-message segments are initialized before allocation; (5) as the strand executes, it can lose memory segments (e.g., by sending a message), but it cannot allocate any more segments; and (6) strand termination causes all transient segments to be released by the kernel. From these properties, it may be concluded that after strand termination, the strand has access only to the permanent segments of the cell and each time a strand runs, the amount of memory available is the same, as specified by the predefined memory requirements for the strand.
FIG. 18 illustrates a method for allocating memory by a separation kernel in accordance with the above-described principles. - As a result, a strand sees exactly the same amount of allocated memory each time it runs. Thus, there is no covert channel stemming from the amount of allocated memory. This eliminates the typical memory allocation covert channel that results from the ability of one process to cause resource exhaustion.
- However, there may be still one covert channel if the memory addresses of the allocated transient segments are visible to the strand as it executes. In this case, it may be possible to manipulate the addresses of the available memory segments to communicate information to a strand to be launched. This channel can be eliminated if the underlying hardware supports address translation. In this case, the strand would see the allocated segments at the same logical address each time it runs. Thus, the strand would have the same amount of allocated transient memory, at the same address, every time it runs.
- Referring to
FIG. 16 , the separation kernel of the present invention also implements a remote procedure call mechanism. During the execution of the strand, the Strand3 may makes aremote procedure call 92 to Strand5 in the target cell (i.e., CellB). As part of the remote procedure call, some of the transient segments of the source strand are sent to the target strand. At this point, these transmitted segments become inaccessible to the source strand and accessible to the target strand. These transmitted segments constitute the parameters of the remote procedure call. - When the target strand is launched, the target strand only gets access to the input transient segments and the permanent segments of the target cell. Since there are no additional memory segments to allocate, it can be concluded that there are sufficient resources to execute the remote procedure call. In other words, the remote procedure call cannot fail on account of insufficient resources. The kernel is designed to ensure that internal kernel resources will be sufficient to process the remote procedure calls, so that no resource exhaustion covert channel is provided by the kernel itself Therefore, it is not possible for the remote procedure call to fail on account of insufficient resources within the kernel.
- In
FIG. 16 , the target strand terminates using the normal strand termination mechanism. The target strand returns avalue 94 to the calling strand. In addition, the transmitted segments are made inaccessible to the target strand and made once again made accessible to the source strand. This means that before and after the remote procedure calls the same set of segments are accessible to the source strand. If the target strand is terminated for any other reason, the remote procedure call mechanism causes a return to the source strand, and thus guarantees a return from the remote procedure call. - During its execution, the target strand is prohibited from sending the transmitted segments as part of a send message. Thus, the segments remain available to be returned to the source strand. Furthermore, the target strand can make a remote procedure call of its own. To do so, the target strand retransmits one or more of the transmitted segments to another target strand. When this additional remote procedure call is completed, the re-transmitted segments are returned to the target strand.
- It should also be noted that the remote procedure call mechanism does not allow recursive calls, i.e. calls to strands in a cell that is already part of the remote procedure call stack. In addition, the remote procedure call mechanism also does not permit a call to a cell that already has an executing strand, thereby preserving the property that only one strand of a cell can run at any one time. This is an important property to prevent re-entrant code. Re-entrant code can cause various runtime errors.
FIG. 19 illustrates a method for performing remote procedure calls in accordance with the above-described principles. - Lastly, the separation kernel of the present invention implements an exception handling mechanism. During the execution of a strand, the strand may generate an exception. As will be apparent to one skilled in the art, the exception may be caused by a variety of conditions, including a divide by zero or an invalid address condition (i.e., an address that is not within one of the segments accessible to the strand). The strand can raise an exception intentionally by calling the Throw( ) interface as shown in
FIG. 17 . - The kernel in turn processes the Throw( )interface by transferring control to the exception handler of the cell. The kernel also passes the cause of the exception in a register to the exception handler. The exception handler runs in the same context as the strand that incurred the exception. Therefore, the exception handler has access to the same permanent and transient segments as the strand that incurred the exception.
- The exception handler has the option of attempting to resume processing of the strand that incurred the exception or terminating the execution of the strand. In
FIG. 17 , it is assumed that the exception handler resumes processing of the strand that incurred the exception. Thus, the strand completes execution and then terminates. - Each strand has a maximum exception count. When the strand incurs a number of exceptions equal to the maximum exception count, the strand is terminated by the kernel. Thus, there is no way to get stuck in a loop of exceptions, which in turn causes, more exceptions. On the contrary, the strand will be terminated when the maximum exception count is reached.
- As a result of the above-described exception handling mechanisms, exceptions are confined to the cell that contains the strand that incurred the exception. Accordingly, the exception handling mechanism enhances the separation property by providing exception handling that is separate between cells.
- The foregoing discloses and describes merely exemplary embodiments of the present invention. One skilled in the art will readily recognize from such discussion, and from accompanying drawings and claims, that various changes, modifications, and variations can be made therein without departing from the spirit and scope of the present invention.
- The data structures that define and describe the strands and cells in the previously described framework are central to the cell abstraction concept, the separation specification, and the implementation of a separation kernel. Therefore, these data structures are defined to permit a better understanding of how the separation kernel may be implemented in accordance with the present invention.
- All of the information in the cell descriptor is static information about the cell. There are four items in the cell descriptor:
-
- PermanentSegmentList: The segments that are permanently allocated to the cell. All the strands of the cell get access to these segments when they run. These segments would typically contain the code and cell state information for the application represented by the cell. Permanent segments can be restricted to a single cell or can be shared between more than one cell. The permanent segment list described the access mode to the segment (some combination of read, write, and execute) desired by the cell.
- Handler: The address of the exception handler for the cell.
- SendMap: The set of cells to which this cell can send messages. This regulates the operation of the kernel Send( )and Wait( )interfaces.
- ShareMap: The set of cells with which this cell can share permanent segments.
- The cell state is dynamic information about the cell. It is maintained as a map from CellID to CellState, where CellState is one of Idle, Running, or Waiting. This mapping is called the CellStateMap.
- All of the information in the strand descriptor is static information about the strand. There are seven items in the strand descriptor:
-
- CellID: The identifier of the cell that contains the strand. This can be used to look up the cell descriptor of the cell containing the strand.
- ProcessorMode: Either foreground or background. If the mode is foreground, the cell is run with interrupts enabled. If the mode is background, the cell is run with interrupts disabled. A background cell can be used to implement a device driver strand, which requires access to hardware resources without fear of interrupt from the hardware.
- EntryPoint: The address of the StrandEntryPoint function.
- StackPointer: Where to begin the stack when the StrandEntryPoint is run. The stack pointer must point at an address within a permanent segment of the cell of the strand, or to an assigned segment required by the strand in the SDAssignedSegmentList. The kernel table builder, not the kernel itself, enforces this restriction.
- Priority: The priority of the strand.
- ScratchSizeMap: The scratch memory requirements of the strand. There are four sizes of scratch segments: Tiny, Small, Medium and Large. The scratch size map defines how many of each of these scratch segments sizes are required by the strand.
- SDAssignedSegmentList: The assigned segments required by the strand. Assigned segments are used to share scarce resources between strands.
The strand descriptors are kept in the StrandDescriptorTable, which is a total mapping from StrandID to StrandDescriptor.
- There is a configuration parameter called InitialStrand used by the kernel. This is static strand information. When the kernel has completed initialization, it launches the strand indicated by the InitialStrand configuration parameter.
- A concept that comes up repeatedly in the description of the kernel is resource availability, so it is discussed separately here to aid understanding of the description of the kernel.
- Execution of a strand may require allocation of resources. The resources that may be allocated are scratch and assigned segments. Resource availability for a strand means:
-
- There are enough available scratch segments of the sizes specified in the ScratchSizeMap of the StrandDescriptor.
- The assigned segments required by the strand are all available. This can mean one of the following:
- The assigned segments are completely free.
- The assigned segments are part of the message to launch the strand.
- The assigned segments have been kept by the strand on the prior execution of the strand.
- A related concept to resource availability for a strand is the runnability of a strand. A strand is runnable when:
-
- The resources required by the strand are available.
- The strand is not marked blocked.
- When a strand begins, it has several standard arguments, which are passed to it by the kernel. The parameters are passed utilizing the registers/stack. The strand must have sufficient stack space for the stacked parameters along with any space necessary for local data. The variables that are initialized with their values and available for a strand to use when it starts are as follows:
-
- SourceStrandID is the ID of the strand, which sent the message.
- Command is a 32-bit message from the sending cell.
- ScratchSegmentList is a structure consisting of the number of scratch segments along with each segment's address and size.
- Message is a structure consisting of the number of message segments along with each segment's address and size.
- Depth represents the level of nested Remote Procedure Calls (RPC) that this strand is being started within. A length of zero means that the strand is being started by a Message_Send call. A length which is greater than zero, represents the number of nested RPCs.
- Exception processing allows a strand to transfer control to the exception handler specified in the cell descriptor for the cell. This feature is similar to a jump and should be used to handle cases where abnormal conditions arise.
- The exception code is the only parameter passed to the exception handler by the currently running strand. The exception code should contain the error code that resulted in the exception. Preferably, the system reserves the first 32 exception codes (0→31) for current and future growth. Each cell is free to use the other exception codes as needed.
Claims (6)
1. A method for performing a remote procedure call from a source task residing in a source cell to a target task residing in a target cell, the source task having a memory space accessible during execution of the source task, comprising the steps of:
sending an input message from the source task to the target task, where the input message is a portion of the memory space associated with the source task and the portion of the memory space is inaccessible to the source task during the execution of the target task;
initiating execution of the target task in the target cell in response to receiving the input message from the source task;
providing access to the portion of the memory space during execution of the target task;
releasing the portion of the memory space such that the portion of the memory space is accessible to the source task; and
providing a return message from the target task to the source task upon completing execution of the target task.
2. The method of claim 1 , further comprising the step of prohibiting the target strand from sending a second input message, where the second input message corresponds to the portion of the memory space received from the source task.
3. The method of claim 1 , further comprising the steps of:
limiting access of the target task to a plurality of input transient segments and a plurality of permanent segments of the target cell; and
providing a sufficient resource to execute the remote procedure call based at least in part on the limiting access of the target task to a plurality of input transient segments and a plurality of permanent segments of the target cell.
4. The method of claim 3 , further comprising the step of prohibiting a resource exhaustion covert channel based at least in part on the providing the sufficient resource to execute the remote procedure call.
5. The method of claim 1 , further comprising the step of prohibiting a call to a task in a cell that is already a part of a stack of the remote procedure call.
6. The method of claim 1 , further comprising the step of prohibiting a call to a target cell having an executing task.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/702,817 US20100192159A1 (en) | 1999-11-19 | 2010-02-09 | Separation kernel with memory allocation, remote procedure call and exception handling mechanisms |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/443,597 US6772416B1 (en) | 1999-11-19 | 1999-11-19 | Separation kernel with memory allocation, remote procedure call and exception handling mechanisms |
US10/866,564 US7689997B2 (en) | 1999-11-19 | 2004-06-10 | Method for allocating memory to tasks without exceeding predefined memory requirements |
US12/702,817 US20100192159A1 (en) | 1999-11-19 | 2010-02-09 | Separation kernel with memory allocation, remote procedure call and exception handling mechanisms |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/866,564 Continuation US7689997B2 (en) | 1999-11-19 | 2004-06-10 | Method for allocating memory to tasks without exceeding predefined memory requirements |
Publications (1)
Publication Number | Publication Date |
---|---|
US20100192159A1 true US20100192159A1 (en) | 2010-07-29 |
Family
ID=23761442
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/443,597 Expired - Lifetime US6772416B1 (en) | 1999-11-19 | 1999-11-19 | Separation kernel with memory allocation, remote procedure call and exception handling mechanisms |
US10/866,564 Expired - Fee Related US7689997B2 (en) | 1999-11-19 | 2004-06-10 | Method for allocating memory to tasks without exceeding predefined memory requirements |
US12/702,817 Abandoned US20100192159A1 (en) | 1999-11-19 | 2010-02-09 | Separation kernel with memory allocation, remote procedure call and exception handling mechanisms |
US12/702,828 Abandoned US20100192154A1 (en) | 1999-11-19 | 2010-02-09 | Separation kernel with memory allocation, remote procedure call and exception handling mechanisms |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/443,597 Expired - Lifetime US6772416B1 (en) | 1999-11-19 | 1999-11-19 | Separation kernel with memory allocation, remote procedure call and exception handling mechanisms |
US10/866,564 Expired - Fee Related US7689997B2 (en) | 1999-11-19 | 2004-06-10 | Method for allocating memory to tasks without exceeding predefined memory requirements |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/702,828 Abandoned US20100192154A1 (en) | 1999-11-19 | 2010-02-09 | Separation kernel with memory allocation, remote procedure call and exception handling mechanisms |
Country Status (6)
Country | Link |
---|---|
US (4) | US6772416B1 (en) |
EP (1) | EP1232436B1 (en) |
JP (1) | JP2003524829A (en) |
AU (1) | AU773730B2 (en) |
GB (1) | GB2372358B (en) |
WO (1) | WO2001037086A2 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2014116339A1 (en) * | 2013-01-24 | 2014-07-31 | Raytheon Company | Synchronizing parallel applications in an asymmetric multi-processing system |
Families Citing this family (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7047370B1 (en) * | 2003-01-14 | 2006-05-16 | Cisco Technology, Inc. | Full access to memory interfaces via remote request |
US7711952B2 (en) * | 2004-09-13 | 2010-05-04 | Coretrace Corporation | Method and system for license management |
US20060075236A1 (en) * | 2004-09-30 | 2006-04-06 | Marek James A | Method and apparatus for high assurance processing |
US20080162877A1 (en) * | 2005-02-24 | 2008-07-03 | Erik Richter Altman | Non-Homogeneous Multi-Processor System With Shared Memory |
US7474618B2 (en) * | 2005-03-02 | 2009-01-06 | Objective Interface Systems, Inc. | Partitioning communication system |
US20070150685A1 (en) * | 2005-12-28 | 2007-06-28 | Gbs Laboratories Llc | Computer architecture for providing physical separation of computing processes |
DE102006020093A1 (en) * | 2006-04-26 | 2007-10-31 | IHP GmbH - Innovations for High Performance Microelectronics/Institut für innovative Mikroelektronik | Protecting a data processing application of a service provider for a user by a trusted execution environment |
US20080046724A1 (en) * | 2006-07-25 | 2008-02-21 | General Dynamics C4 System, Inc. | Method for governing interaction between code within a code base |
US8443191B2 (en) | 2007-04-09 | 2013-05-14 | Objective Interface Systems, Inc. | System and method for accessing information resources using cryptographic authorization permits |
CN104756078B (en) | 2012-08-20 | 2018-07-13 | 唐纳德·凯文·卡梅伦 | The device and method of processing resource allocation |
Citations (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5305455A (en) * | 1990-12-21 | 1994-04-19 | International Business Machines Corp. | Per thread exception management for multitasking multithreaded operating system |
US5446901A (en) * | 1993-06-30 | 1995-08-29 | Digital Equipment Corporation | Fault tolerant distributed garbage collection system and method for collecting network objects |
US5504814A (en) * | 1991-07-10 | 1996-04-02 | Hughes Aircraft Company | Efficient security kernel for the 80960 extended architecture |
US5559980A (en) * | 1993-03-18 | 1996-09-24 | Lucent Technologies Inc. | Method and apparatus for detecting references to deallocated memory in a dynamic memory allocation system |
US5574914A (en) * | 1993-01-04 | 1996-11-12 | Unisys Corporation | Method and apparatus for performing system resource partitioning |
US5574912A (en) * | 1990-05-04 | 1996-11-12 | Digital Equipment Corporation | Lattice scheduler method for reducing the impact of covert-channel countermeasures |
US5699517A (en) * | 1992-09-28 | 1997-12-16 | Hitachi, Ltd. | Information processing equipment for selecting as information data of a message to be sent one program having a score greater than a threshold value |
US5724564A (en) * | 1991-09-06 | 1998-03-03 | International Business Machines Corporation | Computer program product and program storage device for representing and signaling run-time program conditions |
US5729710A (en) * | 1994-06-22 | 1998-03-17 | International Business Machines Corporation | Method and apparatus for management of mapped and unmapped regions of memory in a microkernel data processing system |
US5774729A (en) * | 1991-12-19 | 1998-06-30 | International Business Machines Corporation | Event handling in a high level programming language environment |
US5841869A (en) * | 1996-08-23 | 1998-11-24 | Cheyenne Property Trust | Method and apparatus for trusted processing |
US5890189A (en) * | 1991-11-29 | 1999-03-30 | Kabushiki Kaisha Toshiba | Memory management and protection system for virtual memory in computer system |
US5893159A (en) * | 1997-10-22 | 1999-04-06 | International Business Machines Corporation | Methods and apparatus for managing scratchpad memory in a multiprocessor data processing system |
US5930827A (en) * | 1996-12-02 | 1999-07-27 | Intel Corporation | Method and apparatus for dynamic memory management by association of free memory blocks using a binary tree organized in an address and size dependent manner |
US6047388A (en) * | 1997-04-09 | 2000-04-04 | International Business Machines Corporation | Method and apparatus for processing an invalid address request |
US6064815A (en) * | 1996-06-03 | 2000-05-16 | Sun Microsystems, Inc. | System and method for generating fix-up code facilitating avoidance of an exception of a predetermined type in a digital computer system |
US6199181B1 (en) * | 1997-09-09 | 2001-03-06 | Perfecto Technologies Ltd. | Method and system for maintaining restricted operating environments for application programs or operating systems |
US6292874B1 (en) * | 1999-10-19 | 2001-09-18 | Advanced Technology Materials, Inc. | Memory management method and apparatus for partitioning homogeneous memory and restricting access of installed applications to predetermined memory ranges |
US6314501B1 (en) * | 1998-07-23 | 2001-11-06 | Unisys Corporation | Computer system and method for operating multiple operating systems in different partitions of the computer system and for allowing the different partitions to communicate with one another through shared memory |
US6327606B1 (en) * | 1998-06-24 | 2001-12-04 | Oracle Corp. | Memory management of complex objects returned from procedure calls |
US6477586B1 (en) * | 1998-06-29 | 2002-11-05 | International Business Machines Corporation | Remote procedure calls in distributed systems |
US6691298B1 (en) * | 1999-09-20 | 2004-02-10 | Texas Instruments Incorporated | Memory management in embedded system with design time object instantiation |
US6938257B1 (en) * | 1997-07-17 | 2005-08-30 | International Business Machines Corporation | Apparatus and method to provide persistence for application interfaces |
-
1999
- 1999-11-19 US US09/443,597 patent/US6772416B1/en not_active Expired - Lifetime
-
2000
- 2000-10-31 EP EP00979136A patent/EP1232436B1/en not_active Expired - Lifetime
- 2000-10-31 GB GB0211783A patent/GB2372358B/en not_active Expired - Fee Related
- 2000-10-31 AU AU16549/01A patent/AU773730B2/en not_active Ceased
- 2000-10-31 JP JP2001539112A patent/JP2003524829A/en active Pending
- 2000-10-31 WO PCT/US2000/030014 patent/WO2001037086A2/en active IP Right Grant
-
2004
- 2004-06-10 US US10/866,564 patent/US7689997B2/en not_active Expired - Fee Related
-
2010
- 2010-02-09 US US12/702,817 patent/US20100192159A1/en not_active Abandoned
- 2010-02-09 US US12/702,828 patent/US20100192154A1/en not_active Abandoned
Patent Citations (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5574912A (en) * | 1990-05-04 | 1996-11-12 | Digital Equipment Corporation | Lattice scheduler method for reducing the impact of covert-channel countermeasures |
US5305455A (en) * | 1990-12-21 | 1994-04-19 | International Business Machines Corp. | Per thread exception management for multitasking multithreaded operating system |
US5504814A (en) * | 1991-07-10 | 1996-04-02 | Hughes Aircraft Company | Efficient security kernel for the 80960 extended architecture |
US5724564A (en) * | 1991-09-06 | 1998-03-03 | International Business Machines Corporation | Computer program product and program storage device for representing and signaling run-time program conditions |
US5890189A (en) * | 1991-11-29 | 1999-03-30 | Kabushiki Kaisha Toshiba | Memory management and protection system for virtual memory in computer system |
US5774729A (en) * | 1991-12-19 | 1998-06-30 | International Business Machines Corporation | Event handling in a high level programming language environment |
US5699517A (en) * | 1992-09-28 | 1997-12-16 | Hitachi, Ltd. | Information processing equipment for selecting as information data of a message to be sent one program having a score greater than a threshold value |
US5574914A (en) * | 1993-01-04 | 1996-11-12 | Unisys Corporation | Method and apparatus for performing system resource partitioning |
US5559980A (en) * | 1993-03-18 | 1996-09-24 | Lucent Technologies Inc. | Method and apparatus for detecting references to deallocated memory in a dynamic memory allocation system |
US5446901A (en) * | 1993-06-30 | 1995-08-29 | Digital Equipment Corporation | Fault tolerant distributed garbage collection system and method for collecting network objects |
US5729710A (en) * | 1994-06-22 | 1998-03-17 | International Business Machines Corporation | Method and apparatus for management of mapped and unmapped regions of memory in a microkernel data processing system |
US6064815A (en) * | 1996-06-03 | 2000-05-16 | Sun Microsystems, Inc. | System and method for generating fix-up code facilitating avoidance of an exception of a predetermined type in a digital computer system |
US5841869A (en) * | 1996-08-23 | 1998-11-24 | Cheyenne Property Trust | Method and apparatus for trusted processing |
US5930827A (en) * | 1996-12-02 | 1999-07-27 | Intel Corporation | Method and apparatus for dynamic memory management by association of free memory blocks using a binary tree organized in an address and size dependent manner |
US6047388A (en) * | 1997-04-09 | 2000-04-04 | International Business Machines Corporation | Method and apparatus for processing an invalid address request |
US6938257B1 (en) * | 1997-07-17 | 2005-08-30 | International Business Machines Corporation | Apparatus and method to provide persistence for application interfaces |
US6199181B1 (en) * | 1997-09-09 | 2001-03-06 | Perfecto Technologies Ltd. | Method and system for maintaining restricted operating environments for application programs or operating systems |
US5893159A (en) * | 1997-10-22 | 1999-04-06 | International Business Machines Corporation | Methods and apparatus for managing scratchpad memory in a multiprocessor data processing system |
US6327606B1 (en) * | 1998-06-24 | 2001-12-04 | Oracle Corp. | Memory management of complex objects returned from procedure calls |
US6477586B1 (en) * | 1998-06-29 | 2002-11-05 | International Business Machines Corporation | Remote procedure calls in distributed systems |
US6314501B1 (en) * | 1998-07-23 | 2001-11-06 | Unisys Corporation | Computer system and method for operating multiple operating systems in different partitions of the computer system and for allowing the different partitions to communicate with one another through shared memory |
US6691298B1 (en) * | 1999-09-20 | 2004-02-10 | Texas Instruments Incorporated | Memory management in embedded system with design time object instantiation |
US6292874B1 (en) * | 1999-10-19 | 2001-09-18 | Advanced Technology Materials, Inc. | Memory management method and apparatus for partitioning homogeneous memory and restricting access of installed applications to predetermined memory ranges |
Non-Patent Citations (1)
Title |
---|
Kiam S. Yap "Fault Tolerant Remote Procedure Call"' 1988 IEEE pages 48-54. * |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2014116339A1 (en) * | 2013-01-24 | 2014-07-31 | Raytheon Company | Synchronizing parallel applications in an asymmetric multi-processing system |
EP2948853A1 (en) * | 2013-01-24 | 2015-12-02 | Raytheon Company | Synchronizing parallel applications in an asymmetric multi-processing system |
US9304945B2 (en) | 2013-01-24 | 2016-04-05 | Raytheon Company | Synchronizing parallel applications in an asymmetric multi-processing system |
EP2948853A4 (en) * | 2013-01-24 | 2016-09-21 | Raytheon Co | Synchronizing parallel applications in an asymmetric multi-processing system |
Also Published As
Publication number | Publication date |
---|---|
WO2001037086A3 (en) | 2002-05-16 |
WO2001037086A2 (en) | 2001-05-25 |
AU1654901A (en) | 2001-05-30 |
US20040268356A1 (en) | 2004-12-30 |
GB0211783D0 (en) | 2002-07-03 |
US7689997B2 (en) | 2010-03-30 |
GB2372358B (en) | 2004-08-25 |
JP2003524829A (en) | 2003-08-19 |
GB2372358A (en) | 2002-08-21 |
EP1232436B1 (en) | 2005-03-23 |
AU773730B2 (en) | 2004-06-03 |
US20100192154A1 (en) | 2010-07-29 |
EP1232436A2 (en) | 2002-08-21 |
US6772416B1 (en) | 2004-08-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20100192159A1 (en) | Separation kernel with memory allocation, remote procedure call and exception handling mechanisms | |
EP1155366B1 (en) | Techniques for permitting access across a context barrier on a small footprint device using an entry point object | |
KR100687668B1 (en) | Techniques for permitting access across a context barrier in a small footprint device using global data structures | |
US20070124365A1 (en) | Method, apparatus and program storage device that provides a user mode device interface | |
EP1434121B1 (en) | Techniques for implementing security on a small footprint device using a context barrier | |
KR100716699B1 (en) | Techniques for permitting access across a context barrier on a small footprint device using run time environment privileges | |
EP1151378B1 (en) | Techniques for permitting access across a context barrier in a small footprint device using shared object interfaces | |
GB2399919A (en) | Using a remote procedure call to assign memory to a task | |
AU2004202666B2 (en) | A method of allocating memory and performing a remote procedure call | |
Feske et al. | Design of the Bastei OS architecture | |
AU2004200637A1 (en) | Techniques for permitting access across a context barrier on a small footprint device using run time environment privileges |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |