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) Finally
  ~~~~~~~~~~~~
  
  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().