A restricted execution environment for monolithic kernels

Abstract

[0006] Embodiments of the present systems and methods can provide additional security mechanisms within the operating system kernel itself by isolating portions of the operating system kernel to protect them from attack. For example, in one embodiment, a computer-implemented method implemented in a computer having a processor, memory accessible by the processor, and computer program instructions stored in the memory and executable by the processor may include creating a namespace in an operating system kernel space in the computer's memory, creating an address space for the namespace that maps only kernel objects owned by the namespace, and using combined page tables to provide access to the kernel objects owned by the namespace to a minimum of only one user process.

Description

[Technical Field]

[0001] The present invention relates to techniques that provide additional security mechanisms within the operating system kernel itself by isolating portions of the operating system kernel to protect them from attack. [Background technology]

[0002] The Linux operating system kernel is monolithic, meaning that all of its code and data are linked together, with no enforced separation between different pieces of code or data. This means that an exploitable bug in an interface could allow an attacker to gain unlimited access to kernel resources. Because such bugs appear frequently, the need for mechanisms to limit the potential damage from such exploits arises. For example, suppose an exploitable bug exists in the file system. If an attacker exploits this bug, they can gain access to other subsystems (such as the memory allocator, network stack, or scheduler) even if those subsystems do not contain exploitable bugs. This is due to the lack of security mechanisms within the kernel itself, since the kernel is constructed as a single block of code.

[0003] Therefore, a need arises for techniques that provide additional security mechanisms within the operating system kernel itself. Summary of the Invention

[0004] Embodiments of the present systems and methods can provide additional security mechanisms within the operating system kernel itself by isolating portions of the operating system kernel to protect them from attack.

[0005] For example, in one embodiment, a computer-implemented method is implemented in a computer having a processor, memory accessible by the processor, and computer program instructions stored in the memory and executable by the processor, the method comprising: creating a namespace in an operating system kernel space in the memory of the computer; creating an address space for the namespace that maps only kernel objects owned by the namespace; Kernel Space and providing only at least one user process with access to kernel objects owned by the namespace using page tables.

[0006] In an embodiment, creating an address space for the namespace includes generating a namespace page table containing a mapping of kernel space for kernel objects owned by the namespace and a namespace page table accessible to at least one user process. Kernel Space building a page table; Kernel Space The page tables may include a user space page table and a namespace page table for a user process. The operating system is a Linux operating system. The namespace is a namespace type selected from a mount namespace, a process ID namespace, a network namespace, an interprocess communication namespace, a UTS namespace, a user ID namespace, and a control group namespace. The method Kernel Space The method may further include destroying the namespace by destroying the page tables, the namespace page tables, and kernel objects owned by the namespace.

[0007] In one embodiment, a system includes a processor, memory accessible by the processor, and computer program instructions stored in the memory and executable by the processor, and includes: creating a namespace in an operating system kernel space in the computer's memory; and creating an address space for the namespace that maps only kernel objects owned by the namespace; Kernel Space The page tables may be used to provide access to kernel objects owned by the namespace to at least one user process only.

[0008] In one embodiment, a computer program product may comprise a non-transitory computer-readable storage medium having program instructions embodied thereon, the program instructions being executable by a computer to cause the computer to perform a method, the method comprising: creating a namespace in an operating system kernel space in a memory of the computer; and creating an address space for the namespace that maps only kernel objects owned by the namespace; Kernel Space and providing only to at least one user process access to kernel objects owned by the namespace using page tables.

[0009] The details of the present invention, both as to its structure and operation, can best be understood by referring to the accompanying drawings, in which like reference numbers and designations refer to like elements, and in which: [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 is an illustrative block diagram of the major objects within an operating system kernel, such as the Linux kernel. [Figure 2] FIG. 2 is an exemplary block diagram of a kernel structure described in embodiments of the present systems and methods. [Figure 3] 1 is an exemplary block diagram of a page table implementation that may be used by embodiments of the present systems and methods. [Figure 4] FIG. 1 is an exemplary block diagram of a test implementation of an embodiment of the present system and method. [Figure 5] FIG. 1 is an exemplary block diagram of a computer system on which processes associated with embodiments described herein may be implemented. DETAILED DESCRIPTION OF THE INVENTION

[0011] Embodiments of the present systems and methods can provide additional security mechanisms within the operating system kernel itself by isolating portions of the operating system kernel to protect them from attack.

[0012] A namespace is a region of kernel objects logically grouped together to serve a set of processes. The primary purpose of namespaces is to allow the same object name to be reused across multiple namespaces while addressing different kernel objects. Namespaces are an internal kernel construct that can be used to prevent name collisions within user spaces. For example, within a particular "user" namespace, usernames must be unique. However, the same username can be reused across different user namespaces. This concept is the same for PID namespaces (separated by process ID), network namespaces (separated by network device name), and so on. Regardless of the current namespace in use, all data objects belonging to all namespaces are currently mapped in memory. This could allow access to unauthorized objects by exploiting bugs in the interface.

[0013] Embodiments of the present system and method can provide a security mechanism that can isolate specific portions of the kernel and protect against attacks that attempt to access objects from different namespaces. Embodiments can provide multiple address spaces within the kernel and isolate kernel objects at the namespace level. Each namespace can have its own address space and map only kernel objects owned by that namespace.

[0014] In embodiments, if an object that exists outside the current namespace is required (e.g., when performing memory allocation inside a network stack), an IPC (Inter-Process Communication) mechanism may be used.

[0015] An exemplary block diagram of major objects within an operating system kernel 100, such as the Linux kernel, is shown in FIG. 1. In this example, kernel 100 may include a process ID 102, a task structure 104, NSPROXY 106, a network namespace 108, a SOCK layer 110, a network device 112, and a socket layer 114. Process ID 102 may be a numeric value represented by the data type PID_T, and may uniquely identify each process in the system. Task structure 104 may include a<LINUX / SCHED.H> A task structure 104 may be a process descriptor of type TASK_STRUCT (defined in [RFC1044]) and may be an element in a task list. Each task structure 104 may contain information about a particular running process or thread, such as a process identified by process ID 102. A task structure 104 points to an associated network namespace, such as network namespace 108.

[0016] Socket 114 is a file descriptor that points to a network connection for inter-process communication, which may be any type of communication, such as within the kernel, between user processes, or between different machines. There are several different types of sockets, and different types of sockets may use different communication protocols. In this example, socket 114 is a generic representation of various types of sockets, which can communicate directly with user space through a system interface. Socket 114 may point to a type of intermediate interface, socket 110, which in turn points to an instance of network namespace 108. Network namespace 108 may separate other kernel objects, such as task structure 104, socket layer 114, SOCK layer 110, and network device 112, into logical groups. Whenever kernel code interacts with a particular socket, such as socket 114, the kernel code must reside within the associated network namespace, such as network namespace 108, or within the default namespace.

[0017] Network device 112 represents any particular network hardware or interface. For example, code in user space may access network device 112 using a device name such as "ETH0." Within kernel space, ETH0 refers to a network device 112 that also belongs to a particular network namespace 108. This mechanism provides the ability to identify which user processes have access to which devices. Similarly, any code executing on behalf of a process associated with task structure 104 points to the associated network namespace, such as network namespace 108, and the code then executes on behalf of that network namespace.

[0018] In embodiments, if any code associated with task structure 104 and executing on behalf of a process associated with network namespace 108 attempts to access an object, the embodiments can ensure that the object also belongs to the same network namespace 108. This provides isolation of the object from user processes because of the separate address space of network namespace 108. It should be noted that embodiments of the present system and method are described with reference to network namespaces. However, this is merely one example. Operating system kernels, such as the Linux kernel, can utilize several different types of namespaces, and embodiments of the present system and method are applicable to those other types of namespaces as well. Examples of types of namespaces to which the present systems and methods may be applicable include mount (MNT) namespaces (mount namespaces control mount points), process ID (PID) namespaces (PID namespaces provide processes with a set of process IDs (PIDs) that are independent of other namespaces), network (NET) namespaces (network namespaces virtualize the network stack), inter-process communication (IPC) namespaces (IPC namespaces isolate processes from SYSV-style inter-process communication), UTS namespaces (UTS namespaces allow a single system to appear to have different hostnames and domain names to different processes), user ID (USER) namespaces (user namespaces provide both privilege separation and user identity separation across multiple sets of processes), and control group (CGROUP) namespaces (the CGROUP namespace type hides the identities of control groups that contain processes that are members).

[0019] In accordance with an embodiment of the present system and method, an exemplary block diagram of a kernel structure 200 is shown in Figure 2. In this example, kernelThe architecture 200 may include a kernel space 202 and a user space 204. The kernel space 202 may contain code and data that exist in a high system state and may include protected memory space and full access privileges to the hardware. The user space 204 may contain user applications that can run with reduced privileges; within the user space 204, the user applications can access only a subset of the available resources of the hardware and software. between An application in 204 cannot directly perform certain system functions, directly access hardware, access memory other than that allocated by the kernel, etc. In order for an application in user space 204 to access other system resources, the application may make a system call 206 requesting the kernel to perform a certain function on the application's behalf.

[0020] As shown in FIG. 2, kernel space 202 may include a generic address space 208 and a restricted address space 210. Generic address space 208 may include generic kernel resources such as page tables 216 and files 214. Restricted address space 210 may include multiple namespaces 212A-N. Each namespace 212A-N is an address space linked to a specific namespace and protects multiple sub-kernel objects (SUB-KERNEL OBJECTS) within it, such as devices, network sockets, and associated buffers. In an embodiment, the memory for each namespace within the kernel may be reorganized to provide address space for each namespace 212A-N so that objects owned by different namespaces can be mapped within separate memory pages / regions. When a namespace, such as namespace 212A, is created, an address space (memory page directory) belonging to that particular namespace may also be created. All kernel data objects mapped within the address space of namespace 212A belong to namespace 212A. Whenever a system call 206 that affects a data object is invoked from a particular namespace, such as namespace 212A, the address space for that namespace must be activated. When the namespace is destroyed, the address space is destroyed along with all of the kernel objects mapped to it.

[0021] All kernel code that operates on data objects that belong to a namespace, such as namespace 212A, must be mapped within the address space of namespace 212A. Other kernel code, such as functions that cannot be called from within a namespace, should not be mapped because they cannot access data objects that are not mapped.

[0022] An example of a page table implementation that may be used by embodiments of the present systems and methods is shown in Figure 3. For example, current versions of the Linux kernel include a feature called kernel page-table isolation (PTI) to mitigate certain security vulnerabilities and improve kernel security. PTI separates the user-space page tables from the kernel-space page tables. and For example, the user space page table 304 A~ N contains a minimal set of user space address mappings and kernel space mappings to service system calls, interrupts, and exceptions. Kernel Space Page Table 302 A~ N is the kernel space 202 Address mapping and user space 204 of Address Mapping Both Including, The kernel space page tables 302A-N are: Used only when the system is running in kernel mode. User space page table 304N and kernel space page table 302N combine to form PTI pair 308N. As shown in this example, user space page tables 304A-N may be established for each user process in user space 204, and kernel space page tables 302A-N may be established for each user process in kernel space 202.

[0023] In embodiments, page tables may be separated by mapping page tables based on namespace using an additional page table per namespace. For example, as shown in FIG. 3, network namespace 310 (Hereinafter referred to as "Namespace 310") may be associated with a namespace kernel page table 312 that is separate for that namespace. The kernel's mapping for that namespace is NamespaceFor example, if a task runs in namespace 310 and attempts to access an object, the task may bypass the traditional kernel page tables 304A / 302A for the process. This conventional User portion 304A from kernel page table 304A / 302A and Kernel portion from namespace kernel page table 312 and The new page table constructed from may be used to form the kernel space page table 316 isolated to the namespace 310. The formed The kernel space page table 316 may provide that particular task with access to all objects belonging to its namespace and all generic objects, as well as access to user objects and user code.

[0024] In an embodiment, when namespace 310 is first created, an address space, such as memory page table 312, may be created in namespace 310. When a user space process or task, such as user process / task 304A, requests to perform an action on kernel objects, the address space (page table 312) of the namespace 310 that owns those objects may be activated, and only the kernel objects owned by namespace 310 may be accessed. However, in the page table 316 available to the user space process / task 304A When the namespace 310 is destroyed, the page table 316 may be destroyed along with all mapped kernel objects.

[0025] An exemplary test implementation of an embodiment of the present system and method is shown in FIG. 4. In this example, SVR 402 (a TCP / IP server program) may listen on a specific TCP / IP port (VETH0 404) that belongs to a default namespace. User-space programs (PROG1 406 and PROG2 408) may be TCP clients connected to port VETH1 410. User-space programs PROG1 406 and PROG2 408 may run within a specific network namespace 412; that is, PROG1 406 and PROG2 408 are associated with a task structure that points to namespace 412. Port VETH1 410 may be an instance of a network device that also belongs to namespace 412. Therefore, only PROG1 406 and PROG2 408 can use port VETH1 410. Port VETH1 410 may be connected via a bridge (BR0 414) to VETH0 404, which belongs to the default namespace and is outside namespace 412. Thus, PROG1 406 may open a TCP socket to connect to a server (SVR 402) that is outside namespace 412. Because this TCP socket is inside namespace 412, it may be passed to PROG2 408, which may further use this TCP socket to connect to SVR 402. However, if the TCP socket were passed to, for example, PROG3 416, which is outside namespace 412, PROG3 416 would not be able to use this socket or VETH1 410 to connect to SVR 402 because it does not have access to both this socket and VETH1 410.

[0026] An exemplary block diagram of a computer system 500 on which processes related to embodiments described herein may be implemented is shown in FIG. 5. The computer system 500 may be implemented using one or more programmed general-purpose computer systems, such as embedded processors, systems on a chip, personal computers, workstations, server systems, and small or mainframe computers, or within a distributed network computing environment. The computer system 500 may include one or more processors (CPUs) 502A-502N, input / output circuitry 504, a network adapter 506, and memory 508. The CPUs 502A-502N execute program instructions to perform the functions of the present communication systems and methods. Typically, the CPUs 502A-502N are one or more microprocessors, such as Intel Core® processors. 5 illustrates an embodiment in which computer system 500 is implemented as a single multiprocessor computer system, with multiple processors 502A-502N sharing system resources such as memory 508, input / output circuitry 504, and network adapter 506. However, the present communication systems and methods also include embodiments in which computer system 500 is implemented as multiple networked computer systems, which may be single-processor computer systems, multiprocessor computer systems, or a mixture thereof.

[0027] The input / output circuitry 504 provides the ability to input data into or output data from the computer system 500. For example, the input / output circuitry may include input devices such as a keyboard, mouse, touchpad, trackball, scanner, analog-to-digital converter, etc., output devices such as a video adapter, monitor, printer, and modem. The network adapter 506 interfaces the device 500 to a network 510. The network 510 may be any public or private LAN or WAN, including, but not limited to, the Internet.

[0028] Memory 508 stores program instructions that are executed by CPU 502, and data that is used and processed by CPU 502, to perform the functions of computer system 500. The memory 508 may include, for example, electronic memory devices such as random-access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), electrically erasable programmable read-only memory (EEPROM), flash memory, and electromechanical memory such as magnetic disk drives, tape drives, optical disk drives, which may be implemented using an integrated drive electronic (IDE) interface or variations or extensions thereof such as enhanced IDE (EIDE) or ultra-direct memory access (UDMA), or small computer system interface (SCSI). An interface based on the SCSI (SCSI Interface), or a variant or extension thereof such as Fast SCSI, Wide SCSI, or Fast and Wide SCSI, or a Serial Advanced Technology Attachment (SATA) or a variant or extension thereof, or a Fibre Channel Arbitrated Loop (FC-AL) interface may be used.

[0029] The contents of memory 508 may vary depending on the functions for which computer system 500 is programmed to perform. In the example shown in FIG. 5, exemplary memory contents representing routines and data for embodiments of the processes described above are shown. However, those skilled in the art will recognize that these routines, along with the memory contents associated with these routines, need not be contained in one system or device, but may be distributed among multiple systems or devices based on well-known engineering considerations. The present communication systems and methods may include any and all such configurations.

[0030] In the example shown in FIG. 5, memory 508 may include kernel space 512, user space 514, and other operating system routines 522. Kernel space 202 may contain code and data that exist in an elevated system state and may include protected memory space and full access privileges to hardware. Kernel space 202 may include a generic address space 516 and a restricted address space 518. Generic address space 516 may include generic kernel resources such as page tables and files. Restricted address space 518 may include multiple namespaces 520A-N. Each namespace 520A-N is an address space linked to a specific namespace, each protecting multiple sub-kernel objects within it, such as devices, network sockets, and associated buffers. User space 514 may include user applications that can run with reduced privileges; within user space 514, user applications can access only a subset of available hardware and software resources. Other operating system routines 522 may provide additional system functionality.

[0031] As shown in Figure 5, the communication system and method may be implemented on one or more systems that provide multiprocessor computing, multitasking computing, multiprocess computing, or multithreaded computing, or a combination thereof, as well as on systems that provide only single-processor computing or single-threaded computing. Multiprocessor computing involves performing computing using two or more processors. Multitasking computing involves performing computing using two or more operating system tasks. A task is an operating system concept and refers to the combination of an executing program and the management information used by the operating system. Each time a program is executed, the operating system creates a new task for the program. A task is similar to a program's outer shell in that it identifies the program with a task number and attaches other management information to the task. Many operating systems, including Linux®, UNIX®, OS / 2®, and Windows®, can execute many tasks simultaneously and are called multitasking operating systems. Multitasking is the operating system's ability to run two or more executable files simultaneously. Each executable runs in its own address space; that is, executables do not need to share any memory. This is advantageous because it prevents any program from impairing the execution of other programs running on the system. However, programs do not need to exchange information except through the operating system (or by reading files stored in the file system). Multiprocess computing is similar to multitasking computing, as the terms task and process are often used interchangeably, although some operating systems distinguish between the two.

[0032] The present invention may be a system, method, or computer program product, or a combination thereof, at any possible level of technical detail of integration. The computer program product may include a computer-readable storage medium containing computer-readable program instructions for causing a processor to perform aspects of the present invention. The computer-readable storage medium may be a tangible device capable of holding and storing instructions for use by an instruction-execution device.

[0033] The computer readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes portable floppy disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves in which instructions are recorded, and any suitable combination thereof. As used herein, a computer-readable storage medium should not itself be construed as a transitory signal such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted over a wire.

[0034] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or storage device over a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). This network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage on a computer-readable storage medium within each computing / processing device.

[0035] Computer-readable program instructions for carrying out the operations of the present invention may be source or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object-oriented programming languages ​​such as Smalltalk®, C++, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, to carry out aspects of the present invention, electronic circuitry including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer-readable program instructions to customize the electronic circuitry by utilizing state information of the computer-readable program instructions.

[0036] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0037] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to create a machine, where the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for performing the functions / acts specified in the blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may be stored on a computer-readable storage medium and capable of directing a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner, such that the computer-readable storage medium on which the instructions are stored comprises an article of manufacture containing instructions that implement aspects of the functions / acts specified in the blocks of the flowcharts and / or block diagrams.

[0038] Computer-readable program instructions may be loaded into a computer, other programmable data processing apparatus, or other device such that the instructions, which execute on the computer, other programmable apparatus, or other device, perform the functions / acts specified in the flowchart and / or block diagram blocks, thereby causing a series of operable steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process.

[0039] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, comprising one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions shown in the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or in the reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowchart diagrams, and combinations of blocks included in the block diagrams and / or flowchart diagrams, may be implemented by a special-purpose hardware-based system that performs the specified function(s) or operation(s), or executes a combination of special-purpose hardware and computer instructions.

[0040] Although specific embodiments of the present invention have been described, it will be understood by those skilled in the art that there are other embodiments that are equivalent to the described embodiments. It is therefore to be understood that the present invention is not limited to the specific example embodiments illustrated, but is limited only by the scope of the appended claims. One embodiment of the present invention is as follows. [Section 1] 1. A computer-implemented method implemented in a computer having a processor, a memory accessible by the processor, and computer program instructions stored in the memory and executable by the processor, the method comprising: creating a namespace in an operating system kernel space in said memory of said computer; creating an address space for the namespace that maps only the kernel objects, including generating a namespace page table containing mappings of the kernel space for kernel objects owned by the namespace; constructing a kernel space page table accessible to the user process or task executing within the namespace, the kernel space page table including user space address mappings from kernel page tables within the kernel space that are established for the user process or task and form PTI pairs with user space page tables within the namespace, and kernel space mappings for the kernel objects owned by the namespace from the namespace page tables; using the constructed kernel space page table to provide only the user process or task with access to the kernel objects owned by the namespace; The computer-implemented method includes: [Section 2] Item 1. The computer-implemented method of Item 1, wherein the operating system is a LINUX operating system. [Section 3] 3. The computer-implemented method of claim 2, wherein the namespace is a namespace type selected from a mount namespace, a process identity namespace, a network namespace, an interprocess communication namespace, a UTS namespace, a user identity namespace, and a control group namespace. [Section 4] 2. The computer-implemented method of claim 1, further comprising destroying the namespace by destroying the kernel space page table, the namespace page table, and the kernel objects owned by the namespace. [Section 5] 1. A system comprising a processor, a memory accessible by said processor, and computer program instructions stored in said memory and executable by said processor, creating a namespace in an operating system kernel space in said memory of said computer; creating an address space for the namespace that maps only the kernel objects, including generating a namespace page table containing mappings of the kernel space for kernel objects owned by the namespace; creating an address space for the namespace that maps only kernel objects owned by the namespace, including generating a namespace page table containing mappings of the kernel space for kernel objects owned by the namespace; constructing a kernel space page table accessible to the user process or task executing within the namespace, the kernel space page table including user space address mappings from kernel page tables within the kernel space that are established for the user process or task and form PTI pairs with user space page tables within the namespace, and kernel space mappings for the kernel objects owned by the namespace from the namespace page tables; using the constructed kernel space page table to provide only the user process or task with access to the kernel objects owned by the namespace; The system executes the above. [Section 6] Item 6. The system of item 5, wherein the operating system is a Linux operating system. [Section 7] Item 7. The system of item 6, wherein the namespace is a namespace type selected from a mount namespace, a process ID namespace, a network namespace, an interprocess communication namespace, a UTS namespace, a user ID namespace, and a control group namespace. [Section 8] 6. The system of claim 5, further comprising destroying the namespace, including destroying the kernel space page table, the namespace page table, and the kernel objects owned by the namespace. [Section 9] A computer program, the computer program being configured to: creating a namespace in an operating system kernel space in the memory of said computer; creating an address space for the namespace that maps only the kernel objects, including generating a namespace page table containing mappings of the kernel space for kernel objects owned by the namespace; constructing a kernel space page table accessible to the user process or task executing within the namespace, the kernel space page table including user space address mappings from kernel page tables within the kernel space that are established for the user process or task and form PTI pairs with user space page tables within the namespace, and kernel space mappings for the kernel objects owned by the namespace from the namespace page tables; using the constructed kernel space page table to provide only the user process or task with access to the kernel objects owned by the namespace; causing the computer program to execute. [Section 10] Item 10. The computer program of item 9, wherein the operating system is a Linux operating system. [Section 11] 11. The computer program of claim 10, wherein the namespace is a namespace type selected from a mount namespace, a process ID namespace, a network namespace, an interprocess communication namespace, a UTS namespace, a user ID namespace, and a control group namespace. [Section 12] 10. The computer program product of claim 9, further comprising destroying the namespace, including destroying the kernel space page table, the namespace page table, and the kernel objects owned by the namespace.

Claims

1. 1. A computer-implemented method implemented in a computer having a processor, a memory accessible by said processor, and computer program instructions stored in said memory and executable by said processor, said method comprising: creating a namespace in an operating system kernel space in the memory of the computer; creating an address space for the namespace that maps only the kernel objects, including generating a namespace page table containing mappings of the kernel space for kernel objects owned by the namespace; constructing a kernel space page table accessible to a user process or task executing within the namespace, the kernel space page table including user space address mappings from kernel page tables within the kernel space that are established for the user process or task and form PTI pairs with user space page tables within the namespace, and kernel space address mappings for the kernel objects owned by the namespace from the namespace page tables; using the constructed kernel space page table to provide access to the kernel objects owned by the namespace only to the user process or task; The computer-implemented method includes:

2. 2. The computer-implemented method of claim 1, wherein the operating system is a Linux operating system.

3. 3. The computer-implemented method of claim 2, wherein the namespace is a namespace type selected from a mount namespace, a process identity namespace, a network namespace, an inter-process communication namespace, a UTS namespace, a user identity namespace, and a control group namespace.

4. 2. The computer-implemented method of claim 1, further comprising destroying the namespace by destroying the kernel space page tables, the namespace page tables, and the kernel objects owned by the namespace.

5. 1. A system comprising a processor, a memory accessible by said processor, and computer program instructions stored in said memory and executable by said processor, creating a namespace in an operating system kernel space in the memory of the computer; creating an address space for the namespace that maps only the kernel objects, including generating a namespace page table containing mappings of the kernel space for kernel objects owned by the namespace; constructing a kernel space page table accessible to a user process or task executing within the namespace, the kernel space page table including user space address mappings from kernel page tables within the kernel space that are established for the user process or task and form PTI pairs with user space page tables within the namespace, and kernel space address mappings for the kernel objects owned by the namespace from the namespace page tables; using the constructed kernel space page table to provide access to the kernel objects owned by the namespace only to the user process or task; The system executes the above.

6. 6. The system of claim 5, wherein the operating system is a Linux operating system.

7. 7. The system of claim 6, wherein the namespace is a namespace type selected from a mount namespace, a process ID namespace, a network namespace, an interprocess communication namespace, a UTS namespace, a user ID namespace, and a control group namespace.

8. 6. The system of claim 5, further comprising destroying the namespace, comprising destroying the kernel space page tables, the namespace page tables, and the kernel objects owned by the namespace.

9. A computer program, the computer program being configured to: creating a namespace in an operating system kernel space in the memory of the computer; creating an address space for the namespace that maps only the kernel objects, including generating a namespace page table containing mappings of the kernel space for kernel objects owned by the namespace; constructing a kernel space page table accessible to a user process or task executing within the namespace, the kernel space page table including user space address mappings from kernel page tables within the kernel space that are established for the user process or task and form PTI pairs with user space page tables within the namespace, and kernel space address mappings for the kernel objects owned by the namespace from the namespace page tables; using the constructed kernel space page table to provide access to the kernel objects owned by the namespace only to the user process or task; The computer program causing the computer to execute the above.

10. 10. The computer program product of claim 9, wherein the operating system is a Linux operating system.

11. 11. The computer program product of claim 10, wherein the namespace is a namespace type selected from a mount namespace, a process ID namespace, a network namespace, an interprocess communication namespace, a UTS namespace, a user ID namespace, and a control group namespace.

12. 10. The computer program product of claim 9, further comprising destroying the namespace, comprising destroying the kernel space page tables, the namespace page tables, and the kernel objects owned by the namespace.

Images