share/doc/papers/jail/future.ms

   1 .\"
   2 .\" $FreeBSD: src/share/doc/papers/jail/future.ms,v 1.1.2.1 2000/08/20 13:16:44 mpp Exp $
   3 .\" $DragonFly: src/share/doc/papers/jail/future.ms,v 1.2 2003/06/17 04:36:56 dillon Exp $
   4 .\"
   5 .NH
   6 Future Directions
   7 .PP
   8 The jail facility has already been deployed in numerous capacities and
   9 a few opportunities for improvement have manifested themselves.
  10 .NH 2
  11 Improved Virtualisation
  12 .PP
  13 As it stands, the jail code provides a strict subset of system resources
  14 to the jail environment, based on access to processes, files, network
  15 resources, and privileged services.
  16 Virtualisation, or making the jail environments appear to be fully
  17 functional FreeBSD systems, allows maximum application support and the
  18 ability to offer a wide range of services within a jail environment.
  19 However, there are a number of limitations on the degree of virtualisation
  20 in the current code, and removing these limitations will enhance the
  21 ability to offer services in a jail environment.
  22 Two areas that deserve greater attention are the virtualisation of
  23 network resources, and management of scheduling resources.
  24 .PP
  25 Currently, a single IP address may be allocated to each jail, and all
  26 communication from the jail is limited to that IP address.
  27 In particular, these addresses are IPv4 addresses.
  28 There has been substantial interest in improving interface virtualisation,
  29 allowing one or more addresses to be assigned to an interface, and
  30 removing the requirement that the address be an IPv4 address, allowing
  31 the use of IPv6.
  32 Also, access to raw sockets is currently prohibited, as the current
  33 implementation of raw sockets allows access to raw IP packets associated
  34 with all interfaces.
  35 Limiting the scope of the raw socket would allow its safe use within
  36 a jail, re-enabling support for ping, and other network debugging and
  37 evaluation tools.
  38 .PP
  39 Another area of great interest to the current consumers of the jail code
  40 is the ability to limit the impact of one jail on the CPU resources
  41 available for other jails.
  42 Specifically, this would require that the jail of a process play a rule in
  43 its scheduling parameters.
  44 Prior work in the area of lottery scheduling, currently available as
  45 patches on FreeBSD 2.2.x, might be leveraged to allow some degree of
  46 partitioning between jail environments \s-2[LOTTERY1] [LOTTERY2]\s+2.
  47 However, as the current scheduling mechanism is targeted at time
  48 sharing, and FreeBSD does not currently support real time preemption
  49 of processes in kernel, complete partitioning is not possible within the
  50 current framework.
  51 .NH 2
  52 Improved Management
  53 .PP
  54 Management of jail environments is currently somewhat ad hoc--creating
  55 and starting jails is a well-documented procedure, but day-to-day
  56 management of jails, as well as special case procedures such as shutdown,
  57 are not well analysed and documented.
  58 The current kernel process management infrastructure does not have the
  59 ability to manage pools of processes in a jail-centric way.
  60 For example, it is possible to, within a jail, deliver a signal to all
  61 processes in a jail, but it is not possibly to atomically target all
  62 processes within a jail from outside of the jail.
  63 If the jail code is to effectively limit the behaviour of a jail, the
  64 ability to shut it down cleanly is paramount.
  65 Similarly, shutting down a jail cleanly from within is also not well
  66 defined, the traditional shutdown utilities having been written with
  67 a host environment in mind.
  68 This suggests a number of improvements, both in the kernel and in the
  69 user-land utility set.
  70 .PP
  71 First, the ability to address kernel-centric management mechanisms at
  72 jails is important.
  73 One way in which this might be done is to assign a unique jail id, not
  74 unlike a process id or process group id, at jail creation time.
  75 A new jailkill() syscall would permit the direction of signals to
  76 specific jailids, allowing for the effective termination of all processes
  77 in the jail.
  78 A unique jailid could also supplant the hostname as the unique
  79 identifier for a jail, allowing the hostname to be changed by the
  80 processes in the jail without interfering with jail management.
  81 .PP
  82 More carefully defining the user-land semantics of a jail during startup
  83 and shutdown is also important.
  84 The traditional FreeBSD environment makes use of an init process to
  85 bring the system up during the boot process, and to assist in shutdown.
  86 A similar technique might be used for jail, in effect a jailinit,
  87 formulated to handle the clean startup and shutdown, including calling
  88 out to jail-local /etc/rc.shutdown, and other useful shutdown functions.
  89 A jailinit would also present a central location for delivering
  90 management requests to within a jail from the host environment, allowing
  91 the host environment to request the shutdown of the jail cleanly, before
  92 resorting to terminating processes, in the same style as the host
  93 environment shutting down before killing all processes and halting the
  94 kernel.
  95 .PP
  96 Improvements in the host environment would also assist in improving
  97 jail management, possibly including automated runtime jail management tools,
  98 tools to more easily construct the per-jail file system area, and
  99 include jail shutdown as part of normal system shutdown.
 100 .PP
 101 These improvements in the jail framework would improve both raw
 102 functionality and usability from a management perspective.
 103 The jail code has raised significant interest in the FreeBSD community,
 104 and it is hoped that this type of improved functionality will be
 105 available in upcoming releases of FreeBSD.