1.7.1 init386()

init386() 定义在 sys/i386/i386/machdep.c 中，它针对 Intel 386芯片进行低级初始化。loader已将CPU切换至保护模式。 loader已经建立了最早的任务。

• 初始化内核的可调整参数，这些参数由引导程序传来

• 准备GDT(全局描述符表)

• 准备IDT(中断描述符表)

• 初始化系统控制台

• 初始化DDB(内核的点调试器)，如果它被编译进内核的话

• 初始化TSS(任务状态段)

• 准备LDT(局部描述符表)

• 建立proc0(0号进程，即内核的进程)的pcb(进程控制块)

init386()首先初始化内核的可调整参数， 这些参数由引导程序传来。先设置环境指针(environment pointer, envp) 调用，再调用init_param1()。envp指针已由loader 存放在结构bootinfo中:

sys/i386/i386/machdep.c:
        kern_envp = (caddr_t)bootinfo.bi_envp + KERNBASE;

    /* Init basic tunables, hz etc, 初始化基本可调整项,如hz等 */
    init_param1();

init_param1() 定义在 sys/kern/subr_param.c之中。这个文件 里有一些sysctl项，还有两个函数， init_param1() 和 init_param2()。这两个函数从 init386()中调用:

sys/kern/subr_param.c
    hz = HZ;
    TUNABLE_INT_FETCH("kern.hz", &hz);

TUNABLE_<typename>_FETCH 用来获取环境变量的值:

/usr/src/sys/sys/kernel.h
#define TUNABLE_INT_FETCH(path, var)    getenv_int((path), (var))

Sysctl kern.hz 是系统时钟频率。 同时，这些sysctl项被init_param1()设定: kern.maxswzone, kern.maxbcache, kern.maxtsiz, kern.dfldsiz, kern.dflssiz, kern.maxssiz, kern.sgrowsiz。

然后 init386() 准备全局描述符表(Global Descriptors Table, GDT)。在x86上每个任务都运行在自己的虚拟地址 空间里，这个空间由"段址:偏移量"的数对指定。举个例子， 当前将要由处理器执行的指令在 CS:EIP，那么这条指令的线性虚拟地址 就是“代码段虚拟段地址CS” + EIP。为了简便，段起始于 虚拟地址0，终止于界限4G字节。所以，在这个例子中，指令的线性虚拟地址 正是EIP的值。段寄存器，如CS、DS等是选择符，即全局描述符表中的索引 (更精确的说，索引并非选择符的全部， 而是选择符中的INDEX部分)。

sys/i386/i386/machdep.c:
union descriptor gdt[NGDT * MAXCPU];    /* global descriptor table */

sys/i386/include/segments.h:
/*
 * Entries in the Global Descriptor Table (GDT)
 */
#define GNULL_SEL   0   /* Null Descriptor, 空描述符 */
#define GCODE_SEL   1   /* Kernel Code Descriptor, 内核代码描述符 */
#define GDATA_SEL   2   /* Kernel Data Descriptor, 内核数据描述符 */
#define GPRIV_SEL   3   /* SMP Per-Processor Private Data, 对称多处理每处理器专有数据 */
#define GPROC0_SEL  4   /* Task state process slot zero and up, 任务状态进程 */
#define GLDT_SEL    5   /* LDT - eventually one per process, 每个进程的局部描述符表 */
#define GUSERLDT_SEL    6   /* User LDT, 用户自定义的局部描述符表 */
#define GTGATE_SEL  7   /* Process task switch gate, 进程任务切换关口 */
#define GBIOSLOWMEM_SEL 8   /* BIOS low memory access (must be entry 8), BIOS低端内存访问(入口值必须是8) */
#define GPANIC_SEL  9   /* Task state to consider panic from, 会导致全系统异常中止工作的任务状态 */
#define GBIOSCODE32_SEL 10  /* BIOS interface (32bit Code), BIOS接口(32位代码) */
#define GBIOSCODE16_SEL 11  /* BIOS interface (16bit Code), BIOS接口(16位代码) */
#define GBIOSDATA_SEL   12  /* BIOS interface (Data), BIOS接口(数据) */
#define GBIOSUTIL_SEL   13  /* BIOS interface (Utility), BIOS接口(工具) */
#define GBIOSARGS_SEL   14  /* BIOS interface (Arguments), BIOS接口(自变量，参数) */

请注意，这些 #defines 并非选择符本身，而只是选择符中的 INDEX域，因此它们正是全局描述符表中的索引。 例如，内核代码的选择符(GCODE_SEL)的值为0x08。

下一步是初始化中断描述符表(Interrupt Descriptor Table, IDT)。这张表在发生软件或硬件中断时会被处理器引用。 例如，执行系统调用时，用户应用程序提交INT 0x80 指令。这是一个软件中断，处理器用索引值0x80在 中断描述符表中查找记录。这个记录指向处理这个中断的例程。 在这个特定情形中，这是内核的系统调用关口。

sys/i386/i386/machdep.c:
static struct gate_descriptor idt0[NIDT];
struct gate_descriptor *idt = &idt0[0]; /* interrupt descriptor table, 中断描述符表 */

每个中断都被设置一个合适的中断处理程序。系统调用关口INT 0x80也是如此:

sys/i386/i386/machdep.c:
    setidt(0x80, &IDTVEC(int0x80_syscall),
            SDT_SYS386TGT, SEL_UPL, GSEL(GCODE_SEL, SEL_KPL));

所以当一个用户应用程序提交INT 0x80指令时，全系统的控制权会传递给函数_Xint0x80_syscall， 这个函数在内核代码段中，将被以管理员权限执行。

然后，控制台和DDB(调试器)被初始化:

sys/i386/i386/machdep.c:
    cninit();
/* skipped */
#ifdef DDB
    kdb_init();
    if (boothowto & RB_KDB)
        Debugger("Boot flags requested debugger");
#endif

任务状态段(TSS)是另一个x86保护模式中的数据结构。当发生任务切换时， 任务状态段用来让硬件存储任务现场信息。

局部描述符表(LDT)用来指向用户代码和数据。系统定义了几个选择符， 指向局部描述符表，它们是系统调用关口和用户代码、用户数据选择符:

/usr/include/machine/segments.h
#define LSYS5CALLS_SEL  0   /* forced by intel BCS, Intel BCS强制要求的 */
#define LSYS5SIGR_SEL   1
#define L43BSDCALLS_SEL 2   /* notyet, 尚无 */
#define LUCODE_SEL  3
#define LSOL26CALLS_SEL 4   /* Solaris >= 2.6 system call gate, Solaris >=2.6版系统调用关口 */
#define LUDATA_SEL  5
/* separate stack, es,fs,gs sels ? 分别的栈、es、fs、gs选择符？ */
/* #define  LPOSIXCALLS_SEL 5*/ /* notyet, 尚无 */
#define LBSDICALLS_SEL  16  /* BSDI system call gate, BSDI系统调用关口 */
#define NLDT        (LBSDICALLS_SEL + 1)

然后，proc0(0号进程，即内核所处的进程)的进程控制块(Process Control Block) (struct pcb) 结构被初始化。proc0是一个struct proc 结构， 描述了一个内核进程。内核运行时，该进程总是存在，所以这个结构在内核中被定义为全局变量:

sys/kern/kern_init.c:
    struct  proc proc0;

结构struct pcb是proc结构的一部分，它定义在 /usr/include/machine/pcb.h之中，内含针对i386硬件 结构专有的信息，如寄存器的值。

1.7.2 mi_startup()

这个函数用冒泡排序算法，将所有系统初始化对象，然后逐个调用每个对象的入口:

sys/kern/init_main.c:
    for (sipp = sysinit; *sipp; sipp++) {

        /* ... skipped ... */

        /* Call function */
        (*((*sipp)->func))((*sipp)->udata);
        /* ... skipped ... */
    }

尽管sysinit框架已经在《FreeBSD开发者手册》中有所描述，我还是在这里讨论一下其 内部原理。

每个系统初始化对象(sysinit对象)通过调用宏建立。让我们以 announce sysinit对象为例。这个对象打印版权信息:

sys/kern/init_main.c:
static void
print_caddr_t(void *data __unused)
{
    printf("%s", (char *)data);
}
SYSINIT(announce, SI_SUB_COPYRIGHT, SI_ORDER_FIRST, print_caddr_t, copyright)

这个对象的子系统标识是SI_SUB_COPYRIGHT (0x0800001)，数值刚好排在SI_SUB_CONSOLE(0x0800000)后面。 所以，版权信息将在控制台初始化之后就被很早的打印出来。

让我们看一看宏SYSINIT()到底做了些什么。 它展开成宏C_SYSINIT()。宏C_SYSINIT() 然后展开成一个静态结构struct sysinit。结构里申明里调用了 另一个宏DATA_SET:

/usr/include/sys/kernel.h:
      #define C_SYSINIT(uniquifier, subsystem, order, func, ident) \
      static struct sysinit uniquifier ## _sys_init = { \ subsystem, \
      order, \ func, \ ident \ }; \ DATA_SET(sysinit_set,uniquifier ##
      _sys_init);

#define SYSINIT(uniquifier, subsystem, order, func, ident)  \
    C_SYSINIT(uniquifier, subsystem, order,         \
    (sysinit_cfunc_t)(sysinit_nfunc_t)func, (void *)ident)

宏DATA_SET()展开成MAKE_SET()， 宏MAKE_SET()指向所有隐含的sysinit幻数:

/usr/include/linker_set.h
#define MAKE_SET(set, sym)                      \
    static void const * const __set_##set##_sym_##sym = &sym;   \
    __asm(".section .set." #set ",\"aw\"");             \
    __asm(".long " #sym);                       \
    __asm(".previous")
#endif
#define TEXT_SET(set, sym) MAKE_SET(set, sym)
#define DATA_SET(set, sym) MAKE_SET(set, sym)

回到我们的例子中，经过宏的展开过程，将会产生如下声明:

static struct sysinit announce_sys_init = {
    SI_SUB_COPYRIGHT,
    SI_ORDER_FIRST,
    (sysinit_cfunc_t)(sysinit_nfunc_t)  print_caddr_t,
    (void *) copyright
};

static void const *const __set_sysinit_set_sym_announce_sys_init =
    &announce_sys_init;
__asm(".section .set.sysinit_set" ",\"aw\"");
__asm(".long " "announce_sys_init");
__asm(".previous");

第一个__asm指令在内核可执行文件中建立一个ELF节(section)。 这发生在内核链接的时候。这一节将被命令为.set.sysinit_set。 这一节的内容是一个32位值——announce_sys_init结构的地址，这个结构正是第二个__asm 指令所定义的。第三个__asm指令标记节的结束。 如果前面有名字相同的节定义语句，节的内容(那个32位值)将被填加到 已存在的节里，这样就构造出了一个32位指针数组。

用objdump察看一个内核二进制文件， 也许你会注意到里面有这么几个小的节:

% objdump -h /kernel
  7 .set.cons_set 00000014  c03164c0  c03164c0  002154c0  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  8 .set.kbddriver_set 00000010  c03164d4  c03164d4  002154d4  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  9 .set.scrndr_set 00000024  c03164e4  c03164e4  002154e4  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 10 .set.scterm_set 0000000c  c0316508  c0316508  00215508  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 11 .set.sysctl_set 0000097c  c0316514  c0316514  00215514  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 12 .set.sysinit_set 00000664  c0316e90  c0316e90  00215e90  2**2
                  CONTENTS, ALLOC, LOAD, DATA

这一屏信息显示表明节.set.sysinit_set有0x664字节的大小， 所以0x664/sizeof(void *)个sysinit对象被编译进了内核。 其它节，如.set.sysctl_set表示其它链接器集合。

通过定义一个类型为struct linker_set的变量， 节.set.sysinit_set将被“收集” 到那个变量里:

sys/kern/init_main.c:
      extern struct linker_set sysinit_set; /* XXX */

struct linker_set定义如下:

/usr/include/linker_set.h:
  struct linker_set {
    int ls_length;
    void    *ls_items[1];       /* really ls_length of them, trailing NULL； */
                    /* ls_length个项的数组, 以NULL结尾 */
};

回到对mi_startup()的讨论，我们清楚了sysinit对象是 如何被组织起来的。函数mi_startup()将它们排序，并调用 每一个对象。最后一个对象是系统调度器:

/usr/include/sys/kernel.h:
enum sysinit_sub_id {
    SI_SUB_DUMMY        = 0x0000000,    /* not executed; for linker 不被执行，仅供链接器使用 */
    SI_SUB_DONE     = 0x0000001,    /* processed, 已被处理*/
    SI_SUB_CONSOLE      = 0x0800000,    /* console, 控制台*/
    SI_SUB_COPYRIGHT    = 0x0800001,    /* first use of console, 最早使用控制台的对象 */
...
    SI_SUB_RUN_SCHEDULER    = 0xfffffff /* scheduler: no return, 调度器:不返回 */
};

系统调度器sysinit对象定义在文件 sys/vm/vm_glue.c中，这个对象的入口点是 scheduler()。这个函数实际上是个无限循环， 它表示那个进程标识(PID)为0的进程——swapper进程。前面提到的 proc0结构正是用来描述这个进程。

第一个用户进程是init，由sysinit 对象init建立:

sys/kern/init_main.c:
static void
create_init(const void *udata __unused)
{
    int error;
    int s;

    s = splhigh();
    error = fork1(&proc0, RFFDG | RFPROC, &initproc);
    if (error)
        panic("cannot fork init: %d\n", error);
    initproc->p_flag |= P_INMEM | P_SYSTEM;
    cpu_set_fork_handler(initproc, start_init, NULL);
    remrunqueue(initproc);
    splx(s);
}
SYSINIT(init,SI_SUB_CREATE_INIT, SI_ORDER_FIRST, create_init, NULL)

create_init()通过调用 fork1()分配一个新的进程，但并不将其标记为可运行。 当这个新进程被调度器调度执行时，start_init()将会被调用。 那个函数定义在init_main.c中。它尝试装载并执行二进制代码init， 先尝试/sbin/init，然后是 /sbin/oinit， /sbin/init.bak，最后是 /stand/sysinstall:

sys/kern/init_main.c:
static char init_path[MAXPATHLEN] =
#ifdef  INIT_PATH
    __XSTRING(INIT_PATH);
#else
    "/sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall";
#endif

3.3.1 结构

struct kobj_method

3.3.2 函数

void kobj_class_compile(kobj_class_t cls);
void kobj_class_compile_static(kobj_class_t cls, kobj_ops_t ops);
void kobj_class_free(kobj_class_t cls);
kobj_t kobj_create(kobj_class_t cls, struct malloc_type *mtype, int mflags);
void kobj_init(kobj_t obj, kobj_class_t cls);
void kobj_delete(kobj_t obj, struct malloc_type *mtype);

3.3.3 宏

KOBJ_CLASS_FIELDS
KOBJ_FIELDS
DEFINE_CLASS(name, methods, size)
KOBJMETHOD(NAME, FUNC)

3.3.4 头文件

<sys/param.h>
<sys/kobj.h>

3.3.5 建立一个接口的模板

使用Kobj的第一步是建立一个接口。建立接口包括建立模板的工作。 建立模板可用脚本src/sys/kern/makeobjops.pl完成， 它会产生申明方法的头文件和代码，脚本还会生成方法查找函数。

在这个模板中如下关键词会被使用: #include, INTERFACE, CODE, METHOD, STATICMETHOD, 和 DEFAULT.

#include 语句的整行内容将被一字不差的 复制到被生成的代码文件的头部。

例如:

#include <sys/foo.h>

关键词 INTERFACE 用来定义接口名。 这个名字将与每个方法名接合在一起，形成 [interface name]_[method name]。 语法是： INTERFACE [接口名];

例如:

INTERFACE foo;

关键词 CODE 会将它的参数一字不差的复制到 代码文件中。语法是 CODE { [任何代码] };

例如:

CODE {
    struct foo * foo_alloc_null(struct bar *)
    {
        return NULL;
}
};

关键词 METHOD 用来描述一个方法。语法是: METHOD [返回值类型] [方法名] { [对象; [ 参数;][...]] };

例如:

METHOD int bar {
    struct object *;
    struct foo *;
    struct bar;
};

关键词 DEFAULT 跟在关键词 METHOD 之后，是对关键词METHOD 的补充。它给这个方法补充上缺省函数。 语法是： METHOD [返回值类型] [方法名] { [对象; [参数;][...]] }DEFAULT [缺省函数];

例如:

METHOD int bar {
    struct object *;
    struct foo *;
    int bar;
} DEFAULT foo_hack;

关键词 STATICMETHOD 类似关键词 METHOD。对于每个Kobj对象，一般其头部都有 一些Kobj专有的数据。METHOD定义的方法 就假设这些专有数据位于对象头部；假如对象头部没有这些专有数据， 这些方法对这个对象的访问就可能出错。而STATICMETHOD 定义的对象可以不受这个限制：这样描述出的方法，其操作的数据不由 这个类的某个对象实例给出，而是全都由调用这个方法时的操作数(译者注: 即参数)给出。 这也对于在某个类的方法表之外调用这个方法有用。

其它完整的例子:

src/sys/kern/bus_if.m
src/sys/kern/device_if.m

3.3.6 建立一个类

使用Kobj的第二步是建立一个类。一个类的组有名字、方法表；假如 使用了Kobj的“对象管理工具”(Object Handling Facilities)， 类中还包含对象的大小。建立类时 使用宏DEFINE_CLASS()。建立方法表时，须建立 一个kobj_method_t数组，用NULL项结尾。每个非NULL项可用宏 KOBJMETHOD()建立。

例如:

DEFINE_CLASS(fooclass, foomethods, sizeof(struct foodata));

kobj_method_t foomethods[] = {
    KOBJMETHOD(bar_doo, foo_doo),
    KOBJMETHOD(bar_foo, foo_foo),
    { NULL, NULL}
};

类须被“编译”。根据该类被初始化时系统的状态， 将要用到一个静态分配的缓存和“操作数表”(ops table，译者注：即“参数表”)。 这些操作可通过声明一个结构体 struct kobj_ops并使用 kobj_class_compile_static()，或是只使用 kobj_class_compile()来完成。

3.3.7 建立一个对象

使用Kobj的第三步是定义对象。Kobj对象建立程序假定Kobj专有数据在一个 对象的头部。如果不是如此，应当先自行分配对象，再使用 kobj_init() 初始化对象中的Kobj专有数据； 其实可以使用kobj_create() 分配对象， 并自动初始化对象中的Kobj专有内容。 kobj_init()也可以用来改变一个对象所使用的类。

将Kobj的数据集成到对象中要使用宏KOBJ_FIELDS。

例如

struct foo_data {
    KOBJ_FIELDS;
    foo_foo;
    foo_bar;
};

3.3.8 调用方法

使用Kobj的最后一部就是通过生成的函数调用对象类中的方法。 调用时，接口名与方法名用'_'接合，而且全部使用大写字母。

例如，接口名为foo，方法为bar，调用就是:

[返回值 = ] FOO_BAR(对象 [, 其它参数]);

3.3.9 善后处理

当一个用kobj_create()不再需要被使用时， 可对这个对象调用kobj_delete()。当一个类 不再需要被使用时，可对这个类调用kobj_class_free()。

4.1.1 用户界面代码

用户界面jail的源代码在 /usr/src/usr.sbin/jail， 由一个文件jail.c组成。这个程序有这些参数： jail的路径，主机名，IP地址，还有需要执行的命令。

/usr/include/sys/jail.h: 

struct jail {
        u_int32_t       version;
        char            *path;
        char            *hostname;
        u_int32_t       ip_number;
};

/usr/src/usr.sbin/jail.c
j.version = 0; 
j.path = argv[1];
j.hostname = argv[2];

/usr/src/usr.sbin/jail/jail.c:
struct in.addr in; 
... 
i = inet_aton(argv[3], &in); 
... 
j.ip_number = ntohl(in.s_addr);

/usr/src/sys/usr.sbin/jail/jail.c
i = jail(&j); 
... 
i = execv(argv[4], argv + 4);

4.1.2 相关的内核源代码

现在我们来看文件 /usr/src/sys/kern/kern_jail.c。在这里定义了 jail的系统调用、相关的sysctl，还有网络函数。

/usr/src/sys/kern/kern_jail.c:

int     jail_set_hostname_allowed = 1;
SYSCTL_INT(_jail, OID_AUTO, set_hostname_allowed, CTLFLAG_RW,
    &jail_set_hostname_allowed, 0,
    "Processes in jail can set their hostnames");
    /* Jail中的进程可设定自身的主机名 */

int     jail_socket_unixiproute_only = 1;
SYSCTL_INT(_jail, OID_AUTO, socket_unixiproute_only, CTLFLAG_RW,
    &jail_socket_unixiproute_only, 0,
    "Processes in jail are limited to creating UNIX/IPv4/route sockets only
");
    /* Jail中的进程被限制只能建立UNIX套接字、IPv4套接字、路由套接字 */

int     jail_sysvipc_allowed = 0;
SYSCTL_INT(_jail, OID_AUTO, sysvipc_allowed, CTLFLAG_RW,
    &jail_sysvipc_allowed, 0,
    "Processes in jail can use System V IPC primitives");
    /* Jail中的进程可以使用System V进程间通讯原语 */

/usr/src/sys/kern/kern_jail.c:
int
jail(p, uap)
        struct proc *p;
        struct jail_args /* {
                syscallarg(struct jail *) jail;
        } */ *uap;

/usr/src/sys/kern/kern_jail.c: 
error = copyin(uap->jail, &j, sizeof j);

/usr/include/sys/jail.h:
struct prison {
        int             pr_ref;
        char            pr_host[MAXHOSTNAMELEN];
        u_int32_t       pr_ip;
        void            *pr_linux;
};

/usr/src/sys/kern/kern_jail.c:
 MALLOC(pr, struct prison *, sizeof *pr , M_PRISON, M_WAITOK);
 bzero((caddr_t)pr, sizeof *pr);
 error = copyinstr(j.hostname, &pr->pr_host, sizeof pr->pr_host, 0);
 if (error) 
         goto bail;

/usr/src/sys/kern/kern_jail.c:
ca.path = j.path; 
error = chroot(p, &ca);

/usr/include/sys/proc.h: 
struct proc { 
...
struct prison *p_prison; 
...
};

/usr/src/sys/kern/kern_jail.c
p->p.prison = pr; 
p->p.flag |= P.JAILED;

/usr/src/sys/kern/kern_fork.c:
if (p2->p_prison) {
        p2->p_prison->pr_ref++;
    p2->p_flag |= P_JAILED;
}

4.2.1 SysV 进程间通信(IPC)

System V进程间通信(IPC)是通过消息实现的。每个进程都可以向其它进程发送消息，告诉对方该做什么。处理消息的函数是：msgsys, msgctl, msgget, msgsend 和 msgrcv。 前面我提到一些sysctl开关可以影响Jail的行为，其中有一个是 jail_sysvipc_allowed。在大多数系统上，这个 sysctl被设成0。如此它被设为1，它将使Jail完成失效：在Jail中 有权限的进程就可以影响Jail环境外的进程了。消息与信号的区别是： 消息仅由一个信号编号组成。

/usr/src/sys/kern/sysv_msg.c:

• msgget(3): msgget 返回 (也可能创建) 一个消息描述符，以指派一个在其它系统调用中使用的消息队列。

• msgctl(3): 通过这个函数，一个进程可以 查询一个消息描述符的状态。

• msgsnd(3): msgsnd 向一个进程发送一条消息。

• msgrcv(3): 进程用这个函数接收消息。

在这些系统调用的代码中，都有这样一个条件判断：

/usr/src/sys/kern/sysv msg.c:
if (!jail.sysvipc.allowed && p->p_prison != NULL)
        return (ENOSYS);

信号量系统调用使得进程可以通过一系列操作实现同步。 信号量为进程锁定资源提供了又一种途径。然而，进程将为正在被使用的 信号量进入等待状态，一直休眠到资源被释放。在Jail中如下的信号量 系统调用将会失效: semsys, semget, semctl and semop.

/usr/src/sys/kern/sysv_sem.c:

• semctl(2)(id, num, cmd, arg): Semctl 对在信号量队列中用id标识的信号量执行cmd指定的命令。

• semget(2)(key, nsems, flag): Semget 建立一个对应于key的信号量数组

  参数Key和flag与msgget()的意义相同。

• semop(2)(id, ops, num): Semop 在结构体数组ops中对id标识的信号量完成一系列操作。

System V IPC 使用进程间可以共享内存。进程之间可以通过它们虚拟地址空间 的共享部分以及相关数据读写操作直接通讯。这些系统调用在Jail环境中 将会失效: shmdt, shmat, oshmctl, shmctl, shmget, 和 shmsys.

/usr/src/sys/kern/sysv shm.c:

• shmctl(2)(id, cmd, buf): shmctl 对id标识的共享内存区域做各种各样的控制。

• shmget(2)(key, size, flag): shmget 建立/打开size字节的共享内存区域。

• shmat(2)(id, addr, flag): shmat 将id标识的共享内存区域指派到进程的地址空间里。

• shmdt(2)(addr): shmdt 取消共享内存区域的地址指派。

4.2.2 套接字

Jail以一种特殊的方式处理 socket(2) 系统调用和相关的低级套接字函数。 为了决定一个套接字是否允许被创建，它先检查sysctl jail.socket.unixiproute.only是否被设置为1。 如果被设为1，套接字建立时将只能指定这些协议族： PF_LOCAL, PF_INET, PF_ROUTE。否则， socket(2) 将会返回出错。

/usr/src/sys/kern/uipc_socket.c:
int socreate(dom, aso, type, proto, p) 
... 
register struct protosw *prp; 
... 
{
        if (p->p_prison && jail_socket_unixiproute_only &&
            prp->pr_domain->dom_family != PR_LOCAL && prp->pr_domain->dom_family != PF_INET 
            && prp->pr_domain->dom_family != PF_ROUTE)
                return (EPROTONOSUPPORT); 
...
}

4.2.3 Berkeley包过滤器

Berkeley包过滤器提供了一下与协议无关的，直接通向数据链路层的低级接口。 函数 bpfopen() 打开一个以太网设备。代码中有一个条件判断 禁止所有被囚禁的进程打开Berkeley包过滤器设备。

/usr/src/sys/net/bpf.c: 
static int bpfopen(dev, flags, fmt, p) 
... 
{
        if (p->p_prison) 
                return (EPERM);
...
}

4.2.4 网络协议

网络协议TCP, UDP, IP 和 ICMP很觉。IP 和 ICMP 处于同一协议层次： 第二层，网络层。当参数nam被设置时，有一些限制措施会防止被囚禁的程序 绑定到一些网络接口上。nam是一个指向sockaddr结构体的指针， 描述可以绑定服务的地址。一个更确切的定义：sockaddr“是一个模板， 包含了地址的标识符和地址的长度”[2]。在函数中， pcbbind, sin里有一个指向sockaddr 的指针。结构体包含了套接字可以绑定的端口、地址、长度、协议族。 这就禁止了在Jail中的进程指定协议族。

/usr/src/sys/kern/netinet/in_pcb.c: 
int in.pcbbind(int, nam, p) 
...
        struct sockaddr *nam; 
        struct proc *p; 
{
        ... 
        struct sockaddr.in *sin; 
        ... 
        if (nam) {
                sin = (struct sockaddr.in *)nam; 
                ... 
                if (sin->sin_addr.s_addr != INADDR_ANY) 
                       if (prison.ip(p, 0, &sin->sin.addr.s_addr)) 
                              return (EINVAL); 
                ....
        }
...
}

你也许想知道函数prison_ip()做什么。prison.ip有三个参数， 当前进程(用p表示)，一些标志(flag)和一个IP地址。 当这个IP地址属于一个Jail时，返回1；否则返回0。正如你从代码中看见的， 如果，那个IP地址真的属于一个Jail，就不再允许向一个网络接口绑定协议。

/usr/src/sys/kern/kern_jail.c:
int prison_ip(struct proc *p, int flag, u_int32_t *ip) {
        u_int32_t tmp;

       if (!p->p_prison) 
              return (0); 
       if (flag) 
              tmp = *ip; 
       else tmp = ntohl (*ip); 

       if (tmp == INADDR_ANY) {
              if (flag) 
                     *ip = p->p_prison->pr_ip; 
              else *ip = htonl(p->p_prison->pr_ip); 
              return (0); 
       }

       if (p->p_prison->pr_ip != tmp) 
              return (1); 
       return (0); 
}

被囚禁的用户不能对一个不属于这个Jail的IP地址绑定服务。这个限制在 函数in_pcbbind中也有所体现:

/usr/src/sys/net inet/in_pcb.c
        if (nam) {
               ... 
               lport = sin->sin.port; 
               ... if (lport) { 
                          ... 
                         if (p && p->p_prison)
                                prison = 1; 
                         if (prison &&
                             prison_ip(p, 0, &sin->sin_addr.s_addr))
                        return (EADDRNOTAVAIL);

4.2.5 文件系统

如此完全级大于0，即便是root，也不允许在Jail中设置文件标志，如“不可修改”、“添加”、“不可删除”标志。

/usr/src/sys/ufs/ufs/ufs_vnops.c:
int ufs.setattr(ap) 
        ... 
{
        if ((cred->cr.uid == 0) && (p->prison == NULL)) {
            if ((ip->i_flags 
                     & (SF_NOUNLINK | SF_IMMUTABLE | SF_APPEND)) && 
                     securelevel > 0)
               return (EPERM);
}

5.3.1 接口

<sys/kernel.h>

SYSINIT(uniquifier, subsystem, order, func, ident)
SYSUNINIT(uniquifier, subsystem, order, func, ident)

5.3.2 启动

宏SYSINIT()在SYSINIT数据集合中建立一个SYSINIT数据项，以便SYSINIT在系统启动或模块加载时排序并执行其中的函数。SYSINIT()有一个参数uniquifier，SYSINIT用它来标识数据项，随后是子系统顺序号、子系统元素顺序号、待调用函数、传递给函数的数据。所有的函数必须有一个恒量指针参数。

#include <sys/kernel.h>

void foo_null(void *unused)
{
        foo_doo();
}
SYSINIT(foo, SI_SUB_FOO, SI_ORDER_FOO, foo_null, NULL);

struct foo foo_voodoo = {
        FOO_VOODOO;
}

void foo_arg(void *vdata)
{
        struct foo *foo = (struct foo *)vdata;
        foo_data(foo);
}
SYSINIT(bar, SI_SUB_FOO, SI_ORDER_FOO, foo_arg, &foo_voodoo);
   

注意，SI_SUB_FOO和SI_ORDER_FOO应当分别在上面提到的枚举sysinit_sub_id和sysinit_elem_order之中。既可以使用已有的枚举项，也可以将自己的枚举项添加到这两个枚举的定义之中。你可以使用数学表达式微调SYSINIT的执行顺序。以下的例子示例了一个需要刚好要在内核参数调整的SYSINIT之前执行的SYSINIT。

static void
mptable_register(void *dummy __unused)
{

    apic_register_enumerator(&mptable_enumerator);
}

SYSINIT(mptable_register, SI_SUB_TUNABLES - 1, SI_ORDER_FIRST,
    mptable_register, NULL);

5.3.3 析构

宏SYSUNINIT()的行为与SYSINIT()的相当，只是它将数据项填加至SYSINIT的析构数据集合。

#include <sys/kernel.h>

void foo_cleanup(void *unused)
{
        foo_kill();
}
SYSUNINIT(foobar, SI_SUB_FOO, SI_ORDER_FOO, foo_cleanup, NULL);

struct foo_stack foo_stack = {
        FOO_STACK_VOODOO;
}

void foo_flush(void *vdata)
{
}
SYSUNINIT(barfoo, SI_SUB_FOO, SI_ORDER_FOO, foo_flush, &foo_stack);
   

6.5.1 Kernel Elements

The MAC Framework contains a number of kernel elements:

• Framework management interfaces

• Concurrency and synchronization primitives.

• Policy registration

• Extensible security label for kernel objects

• Policy entry point composition operators

• Label management primitives

• Entry point API invoked by kernel services

• Entry point API to policy modules

• Entry points implementations (policy life cycle, object life cycle/label management, access control checks).

• Policy-agnostic label-management system calls

• mac_syscall() multiplex system call

• Various security policies implemented as MAC policy modules

6.5.2 Framework Management Interfaces

The TrustedBSD MAC Framework may be directly managed using sysctl's, loader tunables, and system calls.

In most cases, sysctl's and loader tunables of the same name modify the same parameters, and control behavior such as enforcement of protections relating to various kernel subsystems. In addition, if MAC debugging support is compiled into the kernel, several counters will be maintained tracking label allocation. It is generally advisable that per-subsystem enforcement controls not be used to control policy behavior in production environments, as they broadly impact the operation of all active policies. Instead, per-policy controls should be preferred, as they provide greater granularity and greater operational consistency for policy modules.

Loading and unloading of policy modules is performed using the system module management system calls and other system interfaces, including boot loader variables; policy modules will have the opportunity to influence load and unload events, including preventing undesired unloading of the policy.

6.5.3 Policy List Concurrency and Synchronization

As the set of active policies may change at run-time, and the invocation of entry points is non-atomic, synchronization is required to prevent loading or unloading of policies while an entry point invocation is in progress, freezing the set of active policies for the duration. This is accomplished by means of a framework busy count: whenever an entry point is entered, the busy count is incremented; whenever it is exited, the busy count is decremented. While the busy count is elevated, policy list changes are not permitted, and threads attempting to modify the policy list will sleep until the list is not busy. The busy count is protected by a mutex, and a condition variable is used to wake up sleepers waiting on policy list modifications. One side effect of this synchronization model is that recursion into the MAC Framework from within a policy module is permitted, although not generally used.

Various optimizations are used to reduce the overhead of the busy count, including avoiding the full cost of incrementing and decrementing if the list is empty or contains only static entries (policies that are loaded before the system starts, and cannot be unloaded). A compile-time option is also provided which prevents any change in the set of loaded policies at run-time, which eliminates the mutex locking costs associated with supporting dynamically loaded and unloaded policies as synchronization is no longer required.

As the MAC Framework is not permitted to block in some entry points, a normal sleep lock cannot be used; as a result, it is possible for the load or unload attempt to block for a substantial period of time waiting for the framework to become idle.

6.5.4 Label Synchronization

As kernel objects of interest may generally be accessed from more than one thread at a time, and simultaneous entry of more than one thread into the MAC Framework is permitted, security attribute storage maintained by the MAC Framework is carefully synchronized. In general, existing kernel synchronization on kernel object data is used to protect MAC Framework security labels on the object: for example, MAC labels on sockets are protected using the existing socket mutex. Likewise, semantics for concurrent access are generally identical to those of the container objects: for credentials, copy-on-write semantics are maintained for label contents as with the remainder of the credential structure. The MAC Framework asserts necessary locks on objects when invoked with an object reference. Policy authors must be aware of these synchronization semantics, as they will sometimes limit the types of accesses permitted on labels: for example, when a read-only reference to a credential is passed to a policy via an entry point, only read operations are permitted on the label state attached to the credential.

6.5.5 Policy Synchronization and Concurrency

Policy modules must be written to assume that many kernel threads may simultaneously enter one more policy entry points due to the parallel and preemptive nature of the FreeBSD kernel. If the policy module makes use of mutable state, this may require the use of synchronization primitives within the policy to prevent inconsistent views on that state resulting in incorrect operation of the policy. Policies will generally be able to make use of existing FreeBSD synchronization primitives for this purpose, including mutexes, sleep locks, condition variables, and counting semaphores. However, policies should be written to employ these primitives carefully, respecting existing kernel lock orders, and recognizing that some entry points are not permitted to sleep, limiting the use of primitives in those entry points to mutexes and wakeup operations.

When policy modules call out to other kernel subsytems, they will generally need to release any in-policy locks in order to avoid violating the kernel lock order or risking lock recursion. This will maintain policy locks as leaf locks in the global lock order, helping to avoid deadlock.

6.5.6 Policy Registration

The MAC Framework maintains two lists of active policies: a static list, and a dynamic list. The lists differ only with regards to their locking semantics: an elevated reference count is not required to make use of the static list. When kernel modules containing MAC Framework policies are loaded, the policy module will use SYSINIT to invoke a registration function; when a policy module is unloaded, SYSINIT will likewise invoke a de-registration function. Registration may fail if a policy module is loaded more than once, if insufficient resources are available for the registration (for example, the policy might require labeling and insufficient labeling state might be available), or other policy prerequisites might not be met (some policies may only be loaded prior to boot). Likewise, de-registration may fail if a policy is flagged as not unloadable.

6.5.7 Entry Points

Kernel services interact with the MAC Framework in two ways: they invoke a series of APIs to notify the framework of relevant events, and they provide a policy-agnostic label structure pointer in security-relevant objects. The label pointer is maintained by the MAC Framework via label management entry points, and permits the Framework to offer a labeling service to policy modules through relatively non-invasive changes to the kernel subsystem maintaining the object. For example, label pointers have been added to processes, process credentials, sockets, pipes, vnodes, Mbufs, network interfaces, IP reassembly queues, and a variety of other security-relevant structures. Kernel services also invoke the MAC Framework when they perform important security decisions, permitting policy modules to augment those decisions based on their own criteria (possibly including data stored in security labels). Most of these security critical decisions will be explicit access control checks; however, some affect more general decision functions such as packet matching for sockets and label transition at program execution.

6.5.8 Policy Composition

When more than one policy module is loaded into the kernel at a time, the results of the policy modules will be composed by the framework using a composition operator. This operator is currently hard-coded, and requires that all active policies must approve a request for it to return success. As policies may return a variety of error conditions (success, access denied, object doesn't exist, ...), a precedence operator selects the resulting error from the set of errors returned by policies. In general, errors indicating that an object does not exist will be preferred to errors indicating that access to an object is denied. While it is not guaranteed that the resulting composition will be useful or secure, we've found that it is for many useful selections of policies. For example, traditional trusted systems often ship with two or more policies using a similar composition.

6.5.9 Labeling Support

As many interesting access control extensions rely on security labels on objects, the MAC Framework provides a set of policy-agnostic label management system calls covering a variety of user-exposed objects. Common label types include partition identifiers, sensitivity labels, integrity labels, compartments, domains, roles, and types. By policy agnostic, we mean that policy modules are able to completely define the semantics of meta-data associated with an object. Policy modules participate in the internalization and externalization of string-based labels provides by user applications, and can expose multiple label elements to applications if desired.

In-memory labels are stored in slab-allocated struct label, which consists of a fixed-length array of unions, each holding a void * pointer and a long. Policies registering for label storage will be assigned a "slot" identifier, which may be used to dereference the label storage. The semantics of the storage are left entirely up to the policy module: modules are provided with a variety of entry points associated with the kernel object life cycle, including initialization, association/creation, and destruction. Using these interfaces, it is possible to implement reference counting and other storage models. Direct access to the object structure is generally not required by policy modules to retrieve a label, as the MAC Framework generally passes both a pointer to the object and a direct pointer to the object's label into entry points. The primary exception to this rule is the process credential, which must be manually dereferenced to access the credential label. This may change in future revisions of the MAC Framework.

Initialization entry points frequently include a sleeping disposition flag indicating whether or not an initialization is permitted to sleep; if sleeping is not permitted, a failure may be returned to cancel allocation of the label (and hence object). This may occur, for example, in the network stack during interrupt handling, where sleeping is not permitted, or while the caller holds a mutex. Due to the performance cost of maintaining labels on in-flight network packets (Mbufs), policies must specifically declare a requirement that Mbuf labels be allocated. Dynamically loaded policies making use of labels must be able to handle the case where their init function has not been called on an object, as objects may already exist when the policy is loaded. The MAC Framework guarantees that uninitialized label slots will hold a 0 or NULL value, which policies may use to detect uninitialized values. However, as allocation of Mbuf labels is conditional, policies must also be able to handle a NULL label pointer for Mbufs if they have been loaded dynamically.

In the case of file system labels, special support is provided for the persistent storage of security labels in extended attributes. Where available, extended attribute transactions are used to permit consistent compound updates of security labels on vnodes--currently this support is present only in the UFS2 file system. Policy authors may choose to implement multilabel file system object labels using one (or more) extended attributes. For efficiency reasons, the vnode label (v_label) is a cache of any on-disk label; policies are able to load values into the cache when the vnode is instantiated, and update the cache as needed. As a result, the extended attribute need not be directly accessed with every access control check.

6.5.10 System Calls

The MAC Framework implements a number of system calls: most of these calls support the policy-agnostic label retrieval and manipulation APIs exposed to user applications.

The label management calls accept a label description structure, struct mac, which contains a series of MAC label elements. Each element contains a character string name, and character string value. Each policy will be given the chance to claim a particular element name, permitting policies to expose multiple independent elements if desired. Policy modules perform the internalization and externalization between kernel labels and user-provided labels via entry points, permitting a variety of semantics. Label management system calls are generally wrapped by user library functions to perform memory allocation and error handling, simplifying user applications that must manage labels.

The following MAC-related system calls are present in the FreeBSD kernel:

• mac_get_proc() may be used to retrieve the label of the current process.

• mac_set_proc() may be used to request a change in the label of the current process.

• mac_get_fd() may be used to retrieve the label of an object (file, socket, pipe, ...) referenced by a file descriptor.

• mac_get_file() may be used to retrieve the label of an object referenced by a file system path.

• mac_set_fd() may be used to request a change in the label of an object (file, socket, pipe, ...) referenced by a file descriptor.

• mac_set_file() may be used to request a change in the label of an object referenced by a file system path.

• mac_syscall() permits policy modules to create new system calls without modifying the system call table; it accepts a target policy name, operation number, and opaque argument for use by the policy.

• mac_get_pid() may be used to request the label of another process by process id.

• mac_get_link() is identical to mac_get_file(), only it will not follow a symbolic link if it is the final entry in the path, so may be used to retrieve the label on a symlink.

• mac_set_link() is identical to mac_set_file(), only it will not follow a symbolic link if it is the final entry in a path, so may be used to manipulate the label on a symlink.

• mac_execve() is identical to the execve() system call, only it also accepts a requested label to set the process label to when beginning execution of a new program. This change in label on execution is referred to as a "transition".

• mac_get_peer(), actually implemented via a socket option, retrieves the label of a remote peer on a socket, if available.

In addition to these system calls, the SIOCSIGMAC and SIOCSIFMAC network interface ioctls permit the labels on network interfaces to be retrieved and set.

6.6.1 Policy Declaration

Modules may be declared using the MAC_POLICY_SET() macro, which names the policy, provides a reference to the MAC entry point vector, provides load-time flags determining how the policy framework should handle the policy, and optionally requests the allocation of label state by the framework.

static struct mac_policy_ops mac_policy_ops =
{                                   
        .mpo_destroy = mac_policy_destroy,
        .mpo_init = mac_policy_init,
        .mpo_init_bpfdesc_label = mac_policy_init_bpfdesc_label,  
        .mpo_init_cred_label = mac_policy_init_label,
/* ... */
        .mpo_check_vnode_setutimes = mac_policy_check_vnode_setutimes,
        .mpo_check_vnode_stat = mac_policy_check_vnode_stat,
        .mpo_check_vnode_write = mac_policy_check_vnode_write,
};

The MAC policy entry point vector, mac_policy_ops in this example, associates functions defined in the module with specific entry points. A complete listing of available entry points and their prototypes may be found in the MAC entry point reference section. Of specific interest during module registration are the .mpo_destroy and .mpo_init entry points. .mpo_init will be invoked once a policy is successfully registered with the module framework but prior to any other entry points becoming active. This permits the policy to perform any policy-specific allocation and initialization, such as initialization of any data or locks. .mpo_destroy will be invoked when a policy module is unloaded to permit releasing of any allocated memory and destruction of locks. Currently, these two entry points are invoked with the MAC policy list mutex held to prevent any other entry points from being invoked: this will be changed, but in the mean time, policies should be careful about what kernel primitives they invoke so as to avoid lock ordering or sleeping problems.

The policy declaration's module name field exists so that the module may be uniquely identified for the purposes of module dependencies. An appropriate string should be selected. The full string name of the policy is