share/doc/papers/jail/future.ms

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