summaryrefslogtreecommitdiff
path: root/Documentation/unshare.txt
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/unshare.txt')
-rw-r--r--Documentation/unshare.txt295
1 files changed, 0 insertions, 295 deletions
diff --git a/Documentation/unshare.txt b/Documentation/unshare.txt
deleted file mode 100644
index a8643513a5f6..000000000000
--- a/Documentation/unshare.txt
+++ /dev/null
@@ -1,295 +0,0 @@
-
-unshare system call:
---------------------
-This document describes the new system call, unshare. The document
-provides an overview of the feature, why it is needed, how it can
-be used, its interface specification, design, implementation and
-how it can be tested.
-
-Change Log:
------------
-version 0.1 Initial document, Janak Desai (janak@us.ibm.com), Jan 11, 2006
-
-Contents:
----------
- 1) Overview
- 2) Benefits
- 3) Cost
- 4) Requirements
- 5) Functional Specification
- 6) High Level Design
- 7) Low Level Design
- 8) Test Specification
- 9) Future Work
-
-1) Overview
------------
-Most legacy operating system kernels support an abstraction of threads
-as multiple execution contexts within a process. These kernels provide
-special resources and mechanisms to maintain these "threads". The Linux
-kernel, in a clever and simple manner, does not make distinction
-between processes and "threads". The kernel allows processes to share
-resources and thus they can achieve legacy "threads" behavior without
-requiring additional data structures and mechanisms in the kernel. The
-power of implementing threads in this manner comes not only from
-its simplicity but also from allowing application programmers to work
-outside the confinement of all-or-nothing shared resources of legacy
-threads. On Linux, at the time of thread creation using the clone system
-call, applications can selectively choose which resources to share
-between threads.
-
-unshare system call adds a primitive to the Linux thread model that
-allows threads to selectively 'unshare' any resources that were being
-shared at the time of their creation. unshare was conceptualized by
-Al Viro in the August of 2000, on the Linux-Kernel mailing list, as part
-of the discussion on POSIX threads on Linux. unshare augments the
-usefulness of Linux threads for applications that would like to control
-shared resources without creating a new process. unshare is a natural
-addition to the set of available primitives on Linux that implement
-the concept of process/thread as a virtual machine.
-
-2) Benefits
------------
-unshare would be useful to large application frameworks such as PAM
-where creating a new process to control sharing/unsharing of process
-resources is not possible. Since namespaces are shared by default
-when creating a new process using fork or clone, unshare can benefit
-even non-threaded applications if they have a need to disassociate
-from default shared namespace. The following lists two use-cases
-where unshare can be used.
-
-2.1 Per-security context namespaces
------------------------------------
-unshare can be used to implement polyinstantiated directories using
-the kernel's per-process namespace mechanism. Polyinstantiated directories,
-such as per-user and/or per-security context instance of /tmp, /var/tmp or
-per-security context instance of a user's home directory, isolate user
-processes when working with these directories. Using unshare, a PAM
-module can easily setup a private namespace for a user at login.
-Polyinstantiated directories are required for Common Criteria certification
-with Labeled System Protection Profile, however, with the availability
-of shared-tree feature in the Linux kernel, even regular Linux systems
-can benefit from setting up private namespaces at login and
-polyinstantiating /tmp, /var/tmp and other directories deemed
-appropriate by system administrators.
-
-2.2 unsharing of virtual memory and/or open files
--------------------------------------------------
-Consider a client/server application where the server is processing
-client requests by creating processes that share resources such as
-virtual memory and open files. Without unshare, the server has to
-decide what needs to be shared at the time of creating the process
-which services the request. unshare allows the server an ability to
-disassociate parts of the context during the servicing of the
-request. For large and complex middleware application frameworks, this
-ability to unshare after the process was created can be very
-useful.
-
-3) Cost
--------
-In order to not duplicate code and to handle the fact that unshare
-works on an active task (as opposed to clone/fork working on a newly
-allocated inactive task) unshare had to make minor reorganizational
-changes to copy_* functions utilized by clone/fork system call.
-There is a cost associated with altering existing, well tested and
-stable code to implement a new feature that may not get exercised
-extensively in the beginning. However, with proper design and code
-review of the changes and creation of an unshare test for the LTP
-the benefits of this new feature can exceed its cost.
-
-4) Requirements
----------------
-unshare reverses sharing that was done using clone(2) system call,
-so unshare should have a similar interface as clone(2). That is,
-since flags in clone(int flags, void *stack) specifies what should
-be shared, similar flags in unshare(int flags) should specify
-what should be unshared. Unfortunately, this may appear to invert
-the meaning of the flags from the way they are used in clone(2).
-However, there was no easy solution that was less confusing and that
-allowed incremental context unsharing in future without an ABI change.
-
-unshare interface should accommodate possible future addition of
-new context flags without requiring a rebuild of old applications.
-If and when new context flags are added, unshare design should allow
-incremental unsharing of those resources on an as needed basis.
-
-5) Functional Specification
----------------------------
-NAME
- unshare - disassociate parts of the process execution context
-
-SYNOPSIS
- #include <sched.h>
-
- int unshare(int flags);
-
-DESCRIPTION
- unshare allows a process to disassociate parts of its execution
- context that are currently being shared with other processes. Part
- of execution context, such as the namespace, is shared by default
- when a new process is created using fork(2), while other parts,
- such as the virtual memory, open file descriptors, etc, may be
- shared by explicit request to share them when creating a process
- using clone(2).
-
- The main use of unshare is to allow a process to control its
- shared execution context without creating a new process.
-
- The flags argument specifies one or bitwise-or'ed of several of
- the following constants.
-
- CLONE_FS
- If CLONE_FS is set, file system information of the caller
- is disassociated from the shared file system information.
-
- CLONE_FILES
- If CLONE_FILES is set, the file descriptor table of the
- caller is disassociated from the shared file descriptor
- table.
-
- CLONE_NEWNS
- If CLONE_NEWNS is set, the namespace of the caller is
- disassociated from the shared namespace.
-
- CLONE_VM
- If CLONE_VM is set, the virtual memory of the caller is
- disassociated from the shared virtual memory.
-
-RETURN VALUE
- On success, zero returned. On failure, -1 is returned and errno is
-
-ERRORS
- EPERM CLONE_NEWNS was specified by a non-root process (process
- without CAP_SYS_ADMIN).
-
- ENOMEM Cannot allocate sufficient memory to copy parts of caller's
- context that need to be unshared.
-
- EINVAL Invalid flag was specified as an argument.
-
-CONFORMING TO
- The unshare() call is Linux-specific and should not be used
- in programs intended to be portable.
-
-SEE ALSO
- clone(2), fork(2)
-
-6) High Level Design
---------------------
-Depending on the flags argument, the unshare system call allocates
-appropriate process context structures, populates it with values from
-the current shared version, associates newly duplicated structures
-with the current task structure and releases corresponding shared
-versions. Helper functions of clone (copy_*) could not be used
-directly by unshare because of the following two reasons.
- 1) clone operates on a newly allocated not-yet-active task
- structure, where as unshare operates on the current active
- task. Therefore unshare has to take appropriate task_lock()
- before associating newly duplicated context structures
- 2) unshare has to allocate and duplicate all context structures
- that are being unshared, before associating them with the
- current task and releasing older shared structures. Failure
- do so will create race conditions and/or oops when trying
- to backout due to an error. Consider the case of unsharing
- both virtual memory and namespace. After successfully unsharing
- vm, if the system call encounters an error while allocating
- new namespace structure, the error return code will have to
- reverse the unsharing of vm. As part of the reversal the
- system call will have to go back to older, shared, vm
- structure, which may not exist anymore.
-
-Therefore code from copy_* functions that allocated and duplicated
-current context structure was moved into new dup_* functions. Now,
-copy_* functions call dup_* functions to allocate and duplicate
-appropriate context structures and then associate them with the
-task structure that is being constructed. unshare system call on
-the other hand performs the following:
- 1) Check flags to force missing, but implied, flags
- 2) For each context structure, call the corresponding unshare
- helper function to allocate and duplicate a new context
- structure, if the appropriate bit is set in the flags argument.
- 3) If there is no error in allocation and duplication and there
- are new context structures then lock the current task structure,
- associate new context structures with the current task structure,
- and release the lock on the current task structure.
- 4) Appropriately release older, shared, context structures.
-
-7) Low Level Design
--------------------
-Implementation of unshare can be grouped in the following 4 different
-items:
- a) Reorganization of existing copy_* functions
- b) unshare system call service function
- c) unshare helper functions for each different process context
- d) Registration of system call number for different architectures
-
- 7.1) Reorganization of copy_* functions
- Each copy function such as copy_mm, copy_namespace, copy_files,
- etc, had roughly two components. The first component allocated
- and duplicated the appropriate structure and the second component
- linked it to the task structure passed in as an argument to the copy
- function. The first component was split into its own function.
- These dup_* functions allocated and duplicated the appropriate
- context structure. The reorganized copy_* functions invoked
- their corresponding dup_* functions and then linked the newly
- duplicated structures to the task structure with which the
- copy function was called.
-
- 7.2) unshare system call service function
- * Check flags
- Force implied flags. If CLONE_THREAD is set force CLONE_VM.
- If CLONE_VM is set, force CLONE_SIGHAND. If CLONE_SIGHAND is
- set and signals are also being shared, force CLONE_THREAD. If
- CLONE_NEWNS is set, force CLONE_FS.
- * For each context flag, invoke the corresponding unshare_*
- helper routine with flags passed into the system call and a
- reference to pointer pointing the new unshared structure
- * If any new structures are created by unshare_* helper
- functions, take the task_lock() on the current task,
- modify appropriate context pointers, and release the
- task lock.
- * For all newly unshared structures, release the corresponding
- older, shared, structures.
-
- 7.3) unshare_* helper functions
- For unshare_* helpers corresponding to CLONE_SYSVSEM, CLONE_SIGHAND,
- and CLONE_THREAD, return -EINVAL since they are not implemented yet.
- For others, check the flag value to see if the unsharing is
- required for that structure. If it is, invoke the corresponding
- dup_* function to allocate and duplicate the structure and return
- a pointer to it.
-
- 7.4) Appropriately modify architecture specific code to register the
- new system call.
-
-8) Test Specification
----------------------
-The test for unshare should test the following:
- 1) Valid flags: Test to check that clone flags for signal and
- signal handlers, for which unsharing is not implemented
- yet, return -EINVAL.
- 2) Missing/implied flags: Test to make sure that if unsharing
- namespace without specifying unsharing of filesystem, correctly
- unshares both namespace and filesystem information.
- 3) For each of the four (namespace, filesystem, files and vm)
- supported unsharing, verify that the system call correctly
- unshares the appropriate structure. Verify that unsharing
- them individually as well as in combination with each
- other works as expected.
- 4) Concurrent execution: Use shared memory segments and futex on
- an address in the shm segment to synchronize execution of
- about 10 threads. Have a couple of threads execute execve,
- a couple _exit and the rest unshare with different combination
- of flags. Verify that unsharing is performed as expected and
- that there are no oops or hangs.
-
-9) Future Work
---------------
-The current implementation of unshare does not allow unsharing of
-signals and signal handlers. Signals are complex to begin with and
-to unshare signals and/or signal handlers of a currently running
-process is even more complex. If in the future there is a specific
-need to allow unsharing of signals and/or signal handlers, it can
-be incrementally added to unshare without affecting legacy
-applications using unshare.
-